Wer länger mit Home Assistant arbeitet, kennt das Muster: Eine Automation kann etwas auslösen, aber nicht etwas entscheiden. Sobald eine Nachricht formuliert, eine Bedingung interpretiert oder ein Foto ausgewertet werden soll, hört YAML auf zu helfen. Genau hier setzt das AI-Task-Framework an, das seit Home Assistant 2025.7 verfügbar ist und mit den Releases seither stabilisiert wurde. In meiner Installation läuft die Entität ai_task.openai_ai_task_2 produktiv – und das verändert, was eine Automation überhaupt sein kann.
Das Problem: Logik in Templates ist Selbstmord auf Raten
Frühere Versuche, LLM-Antworten in Home Assistant zu nutzen, liefen über conversation.process plus notify. Das funktioniert, aber das Ergebnis ist ein Fliesstext, den die Automation nicht zuverlässig weiterverarbeiten kann. Wer aus dieser Antwort einen booleschen Wert extrahieren wollte – «Soll der Roborock heute Abend fahren oder nicht?» – kämpfte mit Regex-Templates, Whitespace und gelegentlichen Halluzinationen.
ai_task.generate_data löst genau dieses Problem. Die Aktion akzeptiert ein Schema-Argument und zwingt das Modell, eine strukturierte Antwort gemäss diesem Schema zu liefern. Aus dem Fliesstext-Generator wird ein deterministischer Datenlieferant.
Schritt 1: Die Entität als Standard hinterlegen
In entitaeten.md taucht die Entität als ai_task.openai_ai_task_2 auf, daneben die alte conversation.openai_conversation. Beide kommen aus der OpenAI-Integration, erfüllen aber unterschiedliche Rollen. Unter Einstellungen → Sprachassistenten → AI Tasks lässt sich pro Aufgabentyp (Text, Bild) eine bevorzugte Entität festlegen. Wer das tut, kann die Entitäts-ID in jedem action-Aufruf weglassen.
Schritt 2: Eine Automation mit strukturiertem Output
Ein konkretes Beispiel aus meiner Installation: Eine Morgenroutine fasst um 06:30 Uhr Wetter, Heizungsstatus und anstehende Kalendereinträge zu einer einzigen Ansage zusammen. Die Ansage wird über assist_satellite.announce auf den home_assistant_voice_0a204b_assist_satellit gespielt.
alias: "Morgen-Briefing"
triggers:
- trigger: time
at: "06:30:00"
actions:
- action: ai_task.generate_data
data:
task_name: "morgen_briefing"
instructions: >
Fasse die folgenden Daten in einem freundlichen,
kurzen Schweizer-Hochdeutsch-Text zusammen (max. 60 Wörter).
Erwähne Heiz-COP nur, wenn unter 3.5. Erwähne Regen nur,
wenn Wahrscheinlichkeit > 50 %.
structure:
ansage:
description: "Der vorlesefertige Text"
required: true
selector:
text:
ist_kritisch:
description: "true, wenn ein Sensor Warnung liefert"
required: true
selector:
boolean:
attachments:
- "{{ states('weather.home') }}"
- "{{ states('sensor.cta_cop_aktuell') }}"
- "{{ state_attr('calendar.familie', 'message') }}"
response_variable: result
- action: assist_satellite.announce
target:
entity_id: assist_satellite.home_assistant_voice_0a204b_assist_satellit
data:
message: "{{ result.data.ansage }}"
Der entscheidende Block ist structure. Er definiert ein Mini-Schema mit zwei Feldern: einer fertigen Ansage und einem booleschen Kritisch-Flag. Der response_variable-Mechanismus gibt das Ergebnis als result.data.ansage und result.data.ist_kritisch weiter – kein Parsen, kein Fluchen.
Schritt 3: Bilder analysieren – mit attachments
Die zweite Stärke von AI Task ist die Bild-Analyse. Die Aktion akzeptiert über das attachments-Feld Media-Source-IDs, etwa von einer Kamera oder vom Roborock-Snapshot. Damit lässt sich eine Frage wie «Steht das Garagentor offen?» oder «Liegt ein Paket vor der Haustüre?» direkt aus der Automation heraus beantworten, ohne den Umweg über separate Vision-Services.
- action: ai_task.generate_data
data:
task_name: "paket_check"
instructions: "Ist auf dem Bild ein Paket sichtbar? Antworte strikt boolean."
structure:
paket_gesichtet:
required: true
selector:
boolean:
attachments:
- media_content_id: "media-source://camera/camera.haustur_snapshot"
media_content_type: "image/jpeg"
response_variable: paket
Worauf zu achten ist
Drei Punkte aus drei Monaten Produktivbetrieb. Erstens: Kostenkontrolle. Jeder Aufruf erzeugt einen API-Call – wer AI Task in jeder Minuten-Automation aufruft, sieht das auf der Rechnung. Zweitens: Datenschutz. OpenAI ist der naheliegende Backend, aber wer sensible Kameradaten verarbeitet, sollte den Wechsel auf einen lokalen Backend wie Ollama oder LM Studio prüfen; das AI-Task-Interface ist Backend-agnostisch. Drittens: Schema diszipliniert die Antworten – aber nicht die Qualität. Wer schlechte Instruktionen schreibt, bekommt deterministisch schlechte Daten zurück.
Wer den Voice-Assistant-Teil dieses Setups bereits eingerichtet hat, kennt das Zusammenspiel von assist_satellite und Pipeline. Eine zweite, sehr lohnende Ergänzung auf der Sensor-Seite ist der mmWave-Sensor, über den ich kürzlich im Detail geschrieben habe. Zusammen entsteht ein Haus, das sieht, zuhört, einschätzt – und das alles in lokal kontrollierbaren YAML-Aktionen statt fremder Cloud-Magie.
Quellen: AI Task – Home Assistant Docs, AI Task Entity – Developer Docs, Building the AI-powered local smart home, Kiril Peyanski: Unlock the Power of AI Task.