Ich habe letzte Woche Claude Cowork einen Long-Life-Token meiner Home-Assistant-Instanz gegeben und ihn gebeten, sich zwei Automationen anzuschauen, die nicht mehr korrekt getriggert haben. Das hat keine zehn Minuten gedauert. Claude hat den Fehler im YAML gefunden, den Fix erklärt und mir die korrigierte Konfiguration geliefert, inklusive kurzem Kommentar, warum das ursprüngliche Template-Statement unter der aktuellen HA-Version nicht mehr so reagiert wie erwartet. Ich hätte das selbst auch herausbekommen. Aber es hätte einen halben Abend gekostet, nicht acht Minuten.
KI und Home Assistant wachsen gerade zusammen. Nicht als Marketing-Versprechen, sondern als funktionierendes Werkzeug in der Hand von Leuten, die tatsächlich beides betreiben. Wer Home Assistant schon eine Weile nutzt, kennt das Grundproblem: die Plattform kann unglaublich viel, aber sie verlangt einem auch einiges ab. YAML, Blueprints, Jinja2-Templates, der gelegentliche Blick in die Logs, weil irgendetwas sich nach einem Update anders verhält. Genau da kommt KI als praktischer Assistent ins Spiel, nicht als Ersatz für das eigene Verständnis, sondern als Abkürzung zu den Ergebnissen.
„Der eigentliche Hebel ist nicht, dass KI das Haus steuert, sondern dass sie dem Betreiber die Arbeit abnimmt, die aufhält: Fehlerlesen, YAML-Schreiben, Dokumentation wälzen“
Dieser Artikel zeigt, wie das konkret funktioniert, welche Ansätze ich selbst produktiv einsetze und wo die Grenzen noch liegen.
Was ist Home Assistant, und warum passt KI dazu?
Home Assistant ist eine Open-Source-Plattform für die Hausautomatisierung. Lokal installiert, keine Cloud-Pflicht, über 3.000 Integrationen für Geräte aller Hersteller. Wer ein echtes Smart Home will, kommt früher oder später hierher, weil keine kommerzielle Lösung diese Flexibilität bietet.
Das Problem: Home Assistant ist mächtig, aber keine Low-Code-Lösung für Einsteiger. Automationen werden in YAML geschrieben, komplexere Bedingungen in Jinja2-Templates. Dashboards in Lovelace konfiguriert. Integrationen wollen verstanden sein. Das ist keine Kritik, das ist die andere Seite der Freiheit.
Genau hier ist KI keine Spielerei, sondern ein echter Produktivitätsfaktor. Und das gilt in der aktuellen HA-Generation 2026.x mehr denn je, weil die Plattform in den letzten Versionen deutlich an Komplexität gewonnen hat, während KI-Modelle gleichzeitig deutlich besser im Umgang mit technischer Konfiguration geworden sind. Die Entwicklung beider Welten läuft gerade parallel aufeinander zu.
Szenario 1: Claude Cowork als Hausassistent-Administrator
Das habe ich selbst gebaut und es läuft. Der Ablauf ist überschaubar.
In Home Assistant einen Long-Life-Token erstellen: Profil aufrufen, Sicherheit, dort unter „Langlebige Zugriffstoken“ einen neuen Token anlegen. Diesen Token zusammen mit der URL deiner HA-Instanz (intern oder über Cloudflare Tunnel von außen erreichbar) in den Systemkontext für Claude Cowork geben.
Was du dann hast: eine KI-Session, die direkt auf deine Home-Assistant-REST-API zugreifen kann. Sie kann den Status von Entities abfragen, Automationen lesen, Logs einsehen, und nach Freigabe auch Änderungen schreiben. Ich nutze das hauptsächlich für drei Dinge:
Fehlerbehebung ohne Dokuwälzen. Wenn eine Automation nach einem Update nicht mehr greift, zeige ich Claude den Log-Eintrag und die betreffende YAML-Konfiguration. Er erkennt die meisten Fehler sofort: veraltete Template-Syntax, geänderte Entity-IDs, Trigger die in HA 2025.x oder 2026.x anders geschrieben werden müssen. Das ist nicht Magie, das ist ein LLM mit dem gesamten Home-Assistant-Changelog im Training. Besser als jeder Forum-Post.
YAML-Generierung für neue Automationen. Ich beschreibe, was die Automation machen soll, auf Deutsch und in normaler Sprache. Claude gibt mir das fertige YAML zurück, mit Kommentaren, mit Fallback-Bedingungen, manchmal mit dem Hinweis: „Das geht in HA 2026.x einfacher mit einem Blueprint.“ Das war früher 20 Minuten Tipparbeit, jetzt sind es zwei Minuten Beschreiben.
Systemcheck auf Nachfrage. Ich frage: „Welche meiner Automationen haben in den letzten 7 Tagen keinen einzigen Trigger erzeugt?“ Claude ruft die Automation-History-API auf und gibt mir die Liste. Nicht weil ich das nicht selbst herausfinden könnte, sondern weil ich es ohne diesen Schritt schlicht vergessen hätte zu prüfen.
Ein Hinweis zu Security, den ich proaktiv anspreche: Der Long-Life-Token hat dieselben Rechte wie dein Benutzerkonto. Wenn du Claude Cowork damit ausstattest, hast du eine externe Session mit vollen Schreibrechten auf dein Heimnetzwerk. Ich nutze dafür eine separate HA-Benutzerrolle mit eingeschränkten Rechten, kein Admin-Account. Das ist nicht paranoid, das ist normales Sicherheitsdenken.
Szenario 2: KI als YAML-Flüsterer
Auch ohne Live-Verbindung zur HA-Instanz ist KI hilfreich, und dieser Ansatz eignet sich für Einsteiger noch besser.
Das Prinzip: Man beschreibt eine gewünschte Automation in natürlicher Sprache, fügt wenn vorhanden den bestehenden YAML-Block ein, und lässt sich von Claude oder Gemini den fertigen Code generieren. Dann kopieren, testen, fertig.
Konkrete Beispiele aus meiner eigenen Nutzung:
„Erstelle eine Home-Assistant-Automation, die um 23 Uhr alle Lichter im Erdgeschoss ausschaltet, außer wenn der Bewegungssensor im Wohnzimmer in den letzten 15 Minuten aktiv war.“
Das klingt simpel. In YAML mit korrekter Bedingungslogik und sauberem Trigger-Setup ist das aber mehr als zehn Zeilen. Ohne KI ist das eine Übung in Dokumentation lesen. Mit KI: 30 Sekunden.
Was ich oft mache: nach dem generierten Code gezielt nachfragen. „Warum hast du for: "00:15:00" in den Trigger statt in die Bedingung geschrieben?“ Die Antworten sind erhellend, weil sie tatsächlich erklären, wie HA-Trigger intern funktionieren. Das ist ein Lerneffekt, den man mit Copy-Paste alleine nicht bekommt.
Szenario 3: n8n als Brücke zwischen KI und Home Assistant
Das ist meine persönliche Lieblingskonfiguration, weil sie Skalierung erlaubt. n8n läuft auf meinem Hetzner-Server via Coolify, und ich baue dort Workflows, die KI und Home Assistant miteinander verbinden.
Ein Beispiel, das ich produktiv nutze: Ein n8n-Workflow fragt täglich um 7 Uhr den Energieverbrauch der letzten 24 Stunden via Home-Assistant-REST-API ab. Die Rohdaten gehen in einen KI-Node (Claude oder Gemini). Der KI-Node bekommt als Systemanweisung: „Du bist ein Energieanalyst. Wenn der Verbrauch mehr als 20% über dem Durchschnitt der letzten sieben Tage liegt, erstelle eine kurze, verständliche Erklärung möglicher Ursachen und eine Empfehlung.“ Das Ergebnis kommt als WhatsApp-Nachricht aufs iPhone.
Kein Dashboard anschauen müssen. Kein manuelles Auswerten. Die KI übernimmt die Interpretation, Home Assistant liefert die Daten, n8n orchestriert.
Ein weiteres Setup: Home Assistant löst bei einem Sensor-Event einen Webhook aus, n8n fängt diesen auf und lässt eine KI-Instanz entscheiden, ob eine Benachrichtigung sinnvoll ist oder nicht. Damit reduziere ich Alert-Noise erheblich. Der Sensor, der dreimal täglich anschlägt weil jemand auf der Terrasse sitzt, braucht keine Push-Notification. Der Sensor, der um 3 Uhr nachts anschlägt, schon.
Szenario 4: Lokale LLMs direkt in Home Assistant
Das ist noch kein vollständig runder Use Case, aber er entwickelt sich schnell, und ich teste ihn aktiv. In meinem Setup-Artikel zu den laufenden Projekten habe ich das bereits erwähnt: Ollama auf dem Raspberry Pi, lokale Sprachmodelle, ohne Cloud-Abhängigkeit.
Home Assistant bringt seit Version 2024.6 eine native Voice Assistant Pipeline mit Ollama-Support mit, und in der aktuellen 2026.x-Generation ist die Integration deutlich gereifter. Über das Open-AI-kompatible API-Interface kann man Ollama direkt anbinden. Das bedeutet: du kannst ein LLM lokal auf deiner Hardware laufen lassen und es direkt aus HA ansprechen.
Praktische Anwendung: „Conversational Agent“ in Home Assistant. Statt Siri oder Alexa zu fragen, sprichst du mit einem lokalen LLM, das Zugriff auf deine Entities hat. „Ist das Küchenfenster offen?“ Das Modell fragt intern die HA-API ab und antwortet. Keine Cloud. Keine Abhängigkeit von Amazon, Google oder Apple. Dass Siri, Alexa und Co. bei echter Intelligenz noch immer Grenzen haben, ist kein Geheimnis, und genau das macht den lokalen Ansatz attraktiv.
Die Realität: Ein Raspberry Pi 4 ist für aktuelle LLMs keine Rennmaschine. Gemma 3 (4B) oder Llama 3.3 (8B) in 4-Bit-Quantisierung laufen auf einem Pi gerade noch akzeptabel, für einfache Entity-Abfragen reicht das. Sobald die Anfragen komplexer werden, merkt man die Hardware-Grenze. Wer einen NUC, einen Intel N100 Mini-PC oder einen älteren Mac mini als HA-Server betreibt, hat deutlich mehr Spielraum und spürbar bessere Antwortzeiten.
Was mich trotzdem überzeugt: das Prinzip. Wenn die Hardware schneller wird, und sie wird das, ist dieser Ansatz das lokale Smart-Home-Brain, das vollständig unter eigener Kontrolle bleibt.
Szenario 5: KI für Dashboard-Design und Lovelace-Konfiguration
Ein unterschätzter Use Case, den ich regelmäßig nutze. Lovelace, das Dashboard-System von Home Assistant, ist mächtig und bei komplexeren Setups auch entsprechend aufwendig in der YAML-Konfiguration.
Ich beschreibe, was ich sehen will. „Erstelle eine Lovelace-Karte, die den Energieverbrauch der letzten sieben Tage als Balkendiagramm zeigt, mit einem Schwellenwert-Marker bei 8 kWh pro Tag.“ Claude gibt mir das fertige YAML zurück, einschließlich der benötigten Custom Cards (in diesem Fall ApexCharts), der Datenbindungen an die richtigen History-Entities und dem Farbschema.
Das hat mir mehr als einmal Stunden gespart. Das Strom-Dashboard, das ich mit Claude Code und der API von Salzburg Netz gebaut habe, ist ein gutes Beispiel dafür, wie aus einem API-Key und einer KI-Session ein funktionierendes Monitoring-Tool entsteht.
Ein Tipp aus der Praxis: Screenshot des aktuellen Dashboards machen und mitschicken. „Das sieht so aus, ich will es so umbauen: …“ Die visuelle Referenz hilft dem Modell, den Kontext zu verstehen und keinen Style zu generieren, der mit dem Rest nicht harmoniert.
Szenario 6: Automations-Dokumentation automatisch erstellen lassen
Das ist eine der Anwendungen, auf die ich bis vor kurzem gar nicht gekommen wäre, die aber in der Praxis Gold wert ist.
Wer Home Assistant eine Weile betreibt, hat irgendwann 30, 50, 80 Automationen. Und irgendwann fragt man sich: Warum macht das Haus das gerade? Welche Automation hat diese Lampe eingeschaltet? Was triggert um Mitternacht?
Ich exportiere regelmäßig meine Automations-Konfiguration und lasse mir von Claude eine Zusammenfassung in natürlicher Sprache erstellen. „Erkläre mir jede dieser Automationen in einem Satz, gruppiert nach Thema (Licht, Energie, Sicherheit, Benachrichtigungen).“ Das Ergebnis ist eine lesbare Dokumentation, die ich in Obsidian ablege. Aktuell. Verständlich. Kein Ratespiel mehr.
Das funktioniert auch andersherum: Ich zeige Claude die Dokumentation und frage: „Welche Automationen haben wahrscheinlich redundante Trigger, die sich gegenseitig stören könnten?“ Das ist ein Sanity-Check, den kein Mensch für sein eigenes Setup durchführt, weil man betriebsblind wird. Die KI nicht.
Szenario 7: Intelligente Benachrichtigungen statt Alert-Spam
Home Assistant kann Benachrichtigungen für fast alles versenden. Das ist anfangs toll. Nach drei Monaten bekommt man 40 Push-Notifications täglich und fängt an, alle zu ignorieren. Das ist Konditionierung in die falsche Richtung.
Der KI-Layer als Filter ist der Ansatz, den ich empfehle und selbst nutze. Nicht jedes Event braucht eine Benachrichtigung. Was es braucht, ist eine Entscheidung, ob das Event im aktuellen Kontext relevant ist.
Das konkrete Setup: HA löst einen Webhook aus, wenn ein definiertes Event eintritt. n8n empfängt diesen Webhook und sendet ihn zusammen mit Kontextinformationen (Uhrzeit, wer ist zuhause, was war in den letzten 24 Stunden los) an Claude über die API. Claude entscheidet: Benachrichtigung ja oder nein, und wenn ja, mit welcher Priorität und welchem Text. Dann erst geht eine Nachricht raus.
Das reduziert den Notification-Lärm um geschätzt 70 Prozent. Was bleibt, ist relevant. Und weil relevante Benachrichtigungen gelesen werden, hat das Setup einen echten Sicherheitswert.
Wo KI bei Home Assistant noch Grenzen hat
Ich schreibe das, weil ich keine Lust auf reine Werbe-Artikel habe.
Echtzeit-Reaktionen: KI-Modelle brauchen Zeit für API-Calls. Für Automationen, die in Millisekunden reagieren müssen (Bewegungsmelder, Alarmauslöser), ist KI in der Schleife zu langsam. Die native HA-Automationslogik ist für zeitkritische Trigger schneller und zuverlässiger.
Aktualität bei HA-Updates: HA 2026.x bringt regelmäßig neue Syntax und geänderte Entities. Trainings-Cutoffs der Modelle bedeuten, dass sehr aktuelle Änderungen noch nicht im Modell sind. Immer in der aktuellen HA-Dokumentation gegenchecken, besonders bei Breaking Changes in den Release Notes.
Kosten und Datenschutz: Cloud-LLMs schicken deine Abfragen an externe Server. Wer Sensor-Daten aus dem Schlafzimmer nicht bei Anthropic oder Google hochladen will, muss lokale Modelle nutzen oder sorgfältig cutten, was in den Prompt geht.
Halluzinationen bei Custom Components: Bei wenig bekannten Custom Integrations und HACS-Komponenten kann das Modell falsche Entity-Namen oder Parameter erfinden. Immer verifizieren, bevor man den Code einspielt.
FAQ: KI und Home Assistant
Home Assistant war schon vor der KI-Welle das mächtigste Smart-Home-System, das du lokal betreiben kannst. Was sich bis Mitte 2026 geändert hat: die Hürde, dieses System wirklich zu beherrschen, ist niedriger geworden. Nicht wegen besserer Dokumentation oder einfacherer GUIs, sondern weil du jetzt einen Gesprächspartner hast, der den gesamten HA-Kontext kennt und deine Probleme in normaler Sprache beantwortet.
Der Raspberry Pi im Bücherregal läuft. Das YAML-Tippen ist weniger. Die Automationen funktionieren besser. Die Frage ist nicht mehr ob KI und Home Assistant zusammenpassen. Die Frage ist, welches Szenario du als nächstes umsetzt.
