Home Assistant per Prompt: Automationen aus dem Dialog

Manchmal kommen mir Einfälle, während ich gerade durch meine Wohnung laufe. Die gebe ich dann per Speech-to-Text über Telegram an OpenCode. Das ist der Weg, über den bei mir die meisten Automationen entstehen.

Ich nutze dafür auch mal Claude Code am Rechner, das kommt in der Praxis aber wesentlich seltener vor. Beim Smart Home ist es genau umgekehrt als bei n8n-Workflows, wo ich fast immer am PC sitze, weil dort Credentials einzurichten sind.

Für das Ergebnis macht das weniger Unterschied als man denkt, denn beide Wege hängen am selben MCP-Server. Entscheidend ist nicht der Client, sondern die Verbindung zur Instanz. Warum ich beide Werkzeuge parallel betreibe, steht auf einer eigenen Seite.

Zur Einordnung, bevor das größer klingt als es ist: Bei mir laufen 119 Automationen. Im Dialog mit der KI entstanden sind davon vielleicht 15, also auch hier kein großer Anteil. Mein Smart Home ist deutlich älter als diese Arbeitsweise, genauso wie mein Bestand an n8n-Workflows.

Die KI greift über HA-MCP auf alles zu, was in Home Assistant liegt. Darüber werden Automationen auch angelegt und bearbeitet. Es gibt also kein YAML, das ich irgendwo hineinkopiere, die KI arbeitet direkt in der Instanz.

Das Projekt bezeichnet sich selbst als inoffiziellen Home-Assistant-MCP-Server, ist in Python mit FastMCP gebaut und bringt nach eigenen Angaben rund 87 Werkzeuge mit. Betreiben lässt es sich als HACS-Komponente in Home Assistant selbst, als Add-on, per Docker beziehungsweise PyPI oder lokal über stdio. Konfiguriert wird der Zugriff über HOMEASSISTANT_URL und einen HOMEASSISTANT_TOKEN.

Neben dem Anlegen von Automationen, Skripten und Szenen kann er auch Automation-Traces lesen. Das ist der Teil, der im Alltag mehr bringt als das Schreiben: Die KI sieht nicht nur, was sie gebaut hat, sondern auch, was beim Auslösen tatsächlich passiert ist.

Das Beispiel, an dem sich das am besten zeigt, ist eine Beschattung. Im Sommer sollen bei starkem Sonneneinfall die Rollläden an den Dachfenstern geschlossen werden, damit sich die Wohnung nicht zu stark aufheizt.

Der Einfall kam unterwegs, eingesprochen über Telegram. Und sie hat von Beginn an funktioniert, sie war nur nicht optimal ausgerichtet und deutlich zu unterkomplex.

Ich zeige hier bewusst eine Automation statt einer Liste. Es geht auf dieser Seite nicht darum, welche Automationen sich lohnen, sondern darum, wie sie entstehen.

Weil „im Dialog entstanden" abstrakt bleibt, hier ein Austausch im Wortlaut. Ausgangslage: Meine VELUX-Steuerung verliert ohne erkennbares Muster die Verbindung, und solange das so ist, lassen sich die Rollläden nicht ansteuern. Gemerkt habe ich es bis dahin immer erst, wenn ich es brauchte.

Mein Prompt, unterwegs über Telegram eingesprochen:

Schau dir bitte mal in meinem Home Assistant folgendes an: VELUX_KLF hat
aktuell den Connection State "Aus". Immer wenn das passiert, können die
Rollläden nicht angesteuert werden und ich muss manuell eingreifen. Es
passiert aber ohne Muster. Können wir eine kleine Automation bauen, die mir
eine Push zuschickt (über unser Benachrichtigungsskript), wenn die Verbindung
verloren geht? Dann erlebe ich keine bösen Überraschungen. schau dir das doch
bitte mal an und sage mir dann, wie du die Automation aufbauen würdest bevor
du das dann tust. Danke!

Wichtig daran ist der vorletzte Satz. Ich habe ausdrücklich verlangt, den Aufbau zu erklären, bevor gebaut wird. Genau das ist auch der Grund, warum ich beim Programmieren den Plan Mode bei größeren Änderungen einschalte, hier habe ich denselben Effekt von Hand erzwungen.

Was zurückkam

Die Antwort war kein YAML, sondern ein Vorschlag in sechs Punkten. Verkürzt:

• Trigger auf sensor.connection_state, Wechsel auf off, mit for: 2 Minuten als Entprellung, damit kurze Aussetzer keine Meldung auslösen.
• Keine Templates, sondern eine native State-Automation, weil der Sensor bereits eindeutig on/off liefert.
• Aktion über mein vorhandenes script.benachrichtigung, mit konkreten Werten für dessen Felder: Push an, Sprachassistent aus, LaMetric aus, Priorität hoch.
• mode: single, damit nicht mehrere identische Meldungen gleichzeitig aufschlagen.

Dazu kam ein Vorab-Befund, den ich nicht angefragt hatte: welcher Sensor der relevante ist und dass er tatsächlich auf off steht. Dazu, auf die Minute genau aus dem Verlauf, seit wann. Das ist der Teil, den der MCP-Server möglich macht: Die KI hat nicht geraten, sie hat nachgesehen.

Am Ende stand eine Rückfrage statt einer Ausführung: ob zusätzlich eine Meldung bei wiederhergestellter Verbindung gewünscht sei, mit dem Hinweis, das nur auf Wunsch einzubauen. Und der Satz, ob sie die Automation jetzt anlegen soll.

Das ist für mich der Unterschied zwischen einem Assistenten und einem Ausführenden. Ich habe nach dem Aufbau gefragt und den Aufbau bekommen, inklusive der Entscheidungen, die ich sonst selbst hätte treffen müssen: Entprellung, Priorität, Modus.

Bis ein Stand erreicht war, mit dem ich zufrieden bin, hat es mehrere Wochen gebraucht. Ich habe immer wieder Details angepasst, quasi immer ein Stückchen besser. Wie viele Durchläufe es insgesamt waren, kann ich nicht mehr sagen.

Der Bremsklotz war dabei nicht der Dialog mit der KI, sondern das Warten darauf, dass die Bedingungen überhaupt erfüllt sind. Das Wetter war schuld.

Genau darin unterscheidet sich das Smart Home von Software. Einen n8n-Workflow prüfe ich in Sekunden: ausführen, Ergebnis ansehen, nachschärfen. Eine Beschattung kann ich nur an einem Tag beurteilen, an dem die Sonne entsprechend steht. Der Takt der Iteration hängt nicht an meiner Geschwindigkeit, sondern an der physischen Welt.

Wer „per Prompt" liest und an einen Nachmittag denkt, unterschätzt das. Die erste Fassung steht schnell. Der Stand, mit dem ich zufrieden war, brauchte Wochen, nicht wegen der KI, sondern wegen der Gelegenheiten zum Prüfen.

Man würde vermuten, dass ich die KI von den heiklen Dingen fernhalte: Türschloss, Heizung, Alarm. Das ist bei mir nicht der Punkt. Skeptisch bin ich an sich nur bei Dashboards.

Dort geht es nämlich nicht nur um Daten und Abläufe, sondern auch um Benutzererfahrung. Und da bin ich mir nicht wirklich sicher, ob die KI das in vollem Umfang so erfasst, wie ich es gerne hätte.

Ich würde dabei nicht von stark oder schwach sprechen. Ich sehe sie für mich in dem einen Bereich einfach stärker als in dem anderen.

Zwei Dinge nehme ich aus dieser Arbeitsweise mit. Erstens ist der Client zweitrangig, ob Telegram, OpenCode oder Claude Code entscheidet über die Bequemlichkeit, nicht über das Ergebnis. Was zählt, ist der MCP-Server dazwischen.

Zweitens verschiebt sich der Aufwand. Das Schreiben einer Automation kostet kaum noch Zeit. Das Beurteilen kostet genauso viel wie vorher, und beim Smart Home lässt es sich nicht beschleunigen.

Diese Seite beschreibt die Arbeitsweise, nicht die Einrichtung. Wer den kompletten Aufbau nachbauen will, findet das bei mir als kostenpflichtige PDF-Guides auf hobbyblogging.de. Das ist mein eigenes Angebot, deshalb sage ich es offen statt es als Leseempfehlung zu tarnen.

Der AI + Home Assistant Deep Dive behandelt auf 34 Seiten genau die Themen, die hier nur angerissen sind: OpenCode, MCP-Architektur und Sicherheit, ausgelegt auf Setups ab etwa 500 Entitäten. Er kostet 12,99 Euro. Für den Einstieg gibt es „Home Assistant mit Claude" für 9,99 Euro. Einmal zahlen, PDF herunterladen, kein Abo.

Alles, was auf dieser Seite und im übrigen Cluster steht, bleibt kostenlos und vollständig lesbar.