Wie ich Home Assistant beigebracht habe, seine eigenen Fehler zu lösen

Viele Fehler in unseren Home Assistant Protokollen bleiben tagelang unbemerkt. Wer schaut schon täglich in die Logs, um alles im Blick zu behalten?

Aus Gründen der Bequemlichkeit (es muss einfach laufen), verstehe ich das absolut. Ich selbst mache es nicht anders. Doch wir haben dabei immer ein Problem: Was ist, wenn wirklich mal was schiefläuft? Hier besteht zumindest das Risiko, dass sich Fehler unbemerkt aufstauen. Denn Fehler gibt es nicht grundlos.

Dabei müssen wir natürlich auch beachten, dass es unterschiedliche Einträge in den Protokollen gibt. Wir unterscheiden Warnings von Errors, genauso wie Debug-Einträge. Je nachdem, wie das System eingestellt ist und wie viel Einblick es uns gewährt. Das ist genau das übliche Vorgehen, nach dem sich auch Entwickler richten. Und in der Regel ist es immer so, dass Errors natürlich eine höhere Priorität haben als Warnings. Das liegt in der Natur der Sache.

Werfen wir also einen Blick darauf, wie ein Self-Healing-System für Home Assistant in der Praxis aussehen könnte. Und wie man es möglicherweise ideal aufbaut.

Denn aktuell sieht es bei mir so aus: Ein Fehler wird festgestellt, ein Issue dazu eröffnet, ich schaue drüber und die KI repariert dann den Fehler. Fast komplett von allein!

Die Idee hinter dem Self-Healing-System

Schon vor einiger Zeit habe ich damit begonnen, mein OpenCode auf die Fehler im Home Assistant loszulassen. Wenn dir das noch nicht bekannt ist, schau dir gerne mal meinen Guide für AI im Smart Home an. Mit dieser Software konnte ich innerhalb kürzester Zeit Fehler analysieren und eine Lösung erarbeiten.

Eine Weile später habe ich dann mit Daniel (aka The Smart Home Maker) in einer Podcast-Folge über unsere Anwendungsfälle von KI im Smart Home gesprochen. Daniel erzählte mir darin von seiner Idee, wie er die KI für die Lösung von Probleme einsetzt.

Und schon damals sagte ich: Ich werde wohl eine lange Nacht haben.

Mein System sieht vor, dass Fehler und Warnings aus dem Protokoll von Home Assistant extrahiert und eingeordnet werden. Eine wichtige Basis bilden hierbei die verschiedenen Log-Level: Error und Warning. Ebenso spielt ein eigens generierter Fingerprint eine Rolle, der Duplikate aus den Logs zusammenfasst.

Je nach Fehler wird dann entweder der Eintrag verworfen oder er wird zur Analyse an die KI gegeben. Der Fehler mitsamt der Analyse wandert dann (im aktuellen Stadium) als Issue auf GitHub (in ein privates Repository). Von dort kann ich ihn entweder zum Bugfix freigeben oder mich selbst um den Fehler kümmern.

Wichtig war mir in meinem Setup, dass es eine zweistufige Lösung gibt. Denn einerseits soll erst eine Analyse gemacht werden und andererseits will ich als Mensch auch noch eingreifen können. Denn manche Fehler will ich gar nicht von der KI bearbeiten lassen und andere kann sie auch nicht bearbeiten. Zum Beispiel wenn an einem Sensor die Batterie leer ist, dann kann die KI im heutigen Zustand noch keinen Austausch vornehmen. Es muss also auch keine KI versuchen, das in einer Session zu lösen. Stattdessen hilft mir hier die Analyse schon weiter, wodurch ich mir eine Menge Zeit sparen kann.

So sieht die Architektur aus

Um dieses Vorhaben so umsetzen zu können, brauche ich einen Orchestrator. Einfach umgesetzt handelt es sich hierbei um eine Software, welche die Koordination des Ablaufs übernimmt und für die komplette Steuerung zuständig ist. In meinem Fall übernimmt das für mich n8n.

n8n bietet mir den Vorteil, dass ich bequem auf Home Assistant, aber auch auf GitHub und OpenCode zugreifen kann. Zudem kann ich mehrere Auslöser hinterlegen und bei Bedarf den Workflow auch abschalten.

Zu einer von mir vorgegebenen Zeit holt sich n8n über eine SSH-Verbindung die Protokolle aus meinem Home Assistant. Die SSH-Verbindung deshalb, weil die API für das Auslesen von Fehlern einfach nicht mehr existiert. GitHub wiederum setze ich dazu ein, dass ich in einem privaten Repository nicht nur meine HA-Skripte haben kann, sondern auch gleich die Issues sehe. So habe ich eine visuelle Umgebung zur Verfügung, die ich auch noch spielend leicht bedienen kann. Deduplizierung stellt sicher, dass es einen Fehler nicht mehrfach auf GitHub geben wird.

Zudem bietet mir GitHub die Möglichkeit, Issues in verschieden Stadien zu packen. Das können „Neu“, „WIP“ und „Done“ sein, aber auch zusätzliche oder andere Labels. Hierdurch erhalte ich aber innerhalb von kurzer Zeit einen guten Einblick, ohne mich zu sehr mit n8n beschäftigen zu müssen. Denn auch hier gilt wieder für mich, dass es im Alltag einfach laufen soll. Möglichst im Hintergrund und mit möglichst wenig Eingriffen durch mich selbst.

Wichtig in diesem ganzen Prozess ist dabei OpenCode. Denn hier steckt dann die eigentliche Intelligenz drin, die auf Wunsch abgerufen werden kann. Wiederum per SSH kann ich dann eine Session starten, welche mit dem MCP für Home Assistant den Fehler untersucht, mir Kontext sammelt und einen geeigneten Lösungsweg vorschlägt. Hierzu habe ich im Prompt explizit erwähnt, dass die KI ausschließlich eine Analyse betreiben soll und noch keinen Fix vornimmt.

Kurzum: n8n stößt den Prozess an und holt alle Fehler aus Home Assistant. Diese werden geordnet, dedupliziert und aufbereitet. Dann läuft OpenCode drüber und das Ergebnis wird an GitHub in ein Issue gegeben. Von dort aus liegt die Entscheidungsgewalt dann wieder bei mir.

Aus Logzeilen werden Issues

Damit wir nun nicht wild einfach jeden Fehler aus dem Log als Issue anlegen und die KI sinnlos belasten, gibt es ein paar Vorarbeiten, die der Workflow für mich leisten muss. Hierbei habe ich mich an dem Vorgehen orientiert, welches ich auch als Entwickler an den Tag lege.

Zuerst werden die Logzeilen aus Home Assistant mit einem Fingerprint versehen. Dieser dient einfach nur dazu, dass es in ein standardisiertes Format gelangt, wo individuelle Angaben gestrichen sind. So gesehen handelt es sich dabei auch nicht wirklich um einen Fingerprint, aber ich habe das damals in Zusammenarbeit mit ChatGPT so getauft.

Da wir nun einen recht standardisierten Fehler haben, kann man diese dann auch entsprechend gruppieren und einordnen. Hierzu werden die Vorkommnisse gezählt und es wird nur noch der Fehler mitsamt der Anzahl weitergegeben. So wird die Liste schon mal deutlich kleiner. Dieser Schritt wurde von mir Deduplizierung getauft.

Hier als Beispiel ein Fehler im Rohformat:

33m2026-07-04 18:00:36.993 WARNING (MainThread) [custom_components.philips_airpurifier_coap.coordinator] No updates from 192.168.176.99 for 755407 seconds, reconnecting

Und hier als Deduplizierung:

WARNING (MainThread) [custom_components.philips_airpurifier_coap.coordinator] No updates from 192.168.176.99 for <NUMBER> seconds, reconnecting

Jetzt ist es noch an der Zeit, dass wir ignorierte Fehler herausfiltern und ein Treshold einbauen. Dieser Schritt ist im Grunde sehr simpel. Denn zuerst wollen wir die Fehler weg haben, die sporadisch sind, die wir nicht beheben wollen oder andere. Übrig bleibt eine kürzere Liste, welche dann auch noch mit einem Treshold versehen wird. Hierbei werden dann anhand der Klassifizierung (Error, Warning) Vorgaben umgesetzt, wonach ein Fehler erst ab einer bestimmten Anzahl an Vorkommnissen weitergegeben wird.

In meinem Workflow wird entschieden, dass ein Warning mindestens 3x auftreten muss, ein Error aber sofort beim ersten Auftritt weitergereicht wird. Denn wie wir wissen, ist ein Error schwerwiegender als ein Warning. Hinzu kommt auch, dass Warnings oftmals gar nicht kritisch sind, sondern dich nur auf etwas hinweisen. Beispielsweise wenn die Netzwerkverbindung mal zu langsam für eine Antwort war. Und da kann die KI sowieso erstmal nur sehr wenig tun.

Die Wichtigkeit von Deduplizierung

Warum mir der Punkt der Deduplizierung so wichtig ist, kann man eigentlich sehr simpel erklären. Aber er ist wirklich entscheidend für meinen gesamten Workflow.

Am obigen Beispiel hast du gesehen, dass die Fehlermeldung im Grunde immer gleich aufgebaut ist. Eine Variable ist jedoch immer die Angabe der Sekunden. Das können mal 755407 aber auch mal 75406 Sekunden sein. Und schön hätten wir ein Duplikat, da der Text nicht mehr derselbe ist. Gleichzeitig haben wir aber auch keine ID auf die wir uns stützen können und so muss eine andere Lösung her.

Indem wir Variablen ersetzen und so ein einheitliches Format erschaffen, können wir wiederum zählen, wie oft ein Fehler auftritt. Und wir können durch n8n auf GitHub vergleichen lassen, ob es ein solches Issue schon gibt. Andernfalls würde jeder Fehler als eigenes Issue angelegt werden und wir hätten im Grunde nur das Log woanders platziert. Genau das will ich eben nicht.

Ich will keine Sammlung von Problemen. Ich will einen guten Umgang mit ihnen und eine intelligente Verarbeitung. Dadurch müssen wir irgendwie in die Situation kommen, dass wir Fehler zusammenfassen und sie vereinheitlichen. In der Praxis würde das ein Softwareentwickler anhand von Protokollen nicht anders machen. Er schaut sich genauso an, ob es irgendwo ein Muster von Problemen gibt und bearbeitet dann das Muster anstatt jeden Fehler individuell.

GitHub wird zur Schaltzentrale

Um keinen Kontext zu verlieren, brauchen wir irgendwo eine Art Akte, wo wir den Fehler festhalten können. Darüber hinaus muss auch irgendwie erkenntlich sein, welchen Fehler wir schon in der Bearbeitung haben oder ob dieser überhaupt schon erfasst wurde.

Hier kommt bei mir GitHub ins Spiel. Pro Fehler wird (sofern er überhaupt bis zu diesem Schritt kommt) ein Issue erstellt. In diesem Issue behalten wir die grundsätzliche Beschreibung des Fehlers, die Analyse der KI und ein paar Meta-Informationen zur Session in OpenCode. Genau diese wird im späteren Verlauf nochmal wichtig werden. Warum das so ist, zeige ich dir gleich.

Der große Vorteil für mich an GitHub ist, dass ich täglich damit arbeite. Ich kenne mich dort aus, fühle mich digital daheim und kann mit Leichtigkeit auch mal vom Smartphone aus agieren. Zudem wandern alle Informationen in ein Issue pro Fehler und ich kann meinen eigenen Kontext hinzugeben. Wenn also die Analyse gut war, ich aber trotzdem noch Ergänzungen habe, dann füge ich die einfach als Kommentar hinzu.

Nach dem Durchlauf der KI soll dann außerdem noch etwas zur Lösung festgehalten werden. So kann ich gleichzeitig auf ein gutes Wissen zurückgreifen und ich kann in einem späteren Schritt vielleicht noch hinzufügen, dass die KI sich an altem Wissen orientiert. Doch das ist noch Zukunftsmusik und muss noch etwas warten.

Mit der Lösung loslegen wird die KI übrigens nur dann, wenn ich auf GitHub das korrekte Label setze. Ohne dieses Label für ein Issue erfolgt keine Reparatur.

KI versucht die Reparatur

In einem zweiten Workflow in n8n werden alle offenen Issues mit dem Label ai:ready abgerufen. Nur wenn ein Issue dieses Label trägt, darf der Workflow seine Arbeit daran fortsetzen.

Hierzu ruft er im ersten Schritt die Meta-Informationen aus dem Issue ab, wie zum Beispiel die Session ID in OpenCode. Existiert diese noch, dann wird der Dialog darin fortgesetzt. Meine Idee ist dabei recht simpel, denn ich möchte ungern zu viele Sessions parallel haben und stattdessen in der fortfahren, wo die KI schon einige Informationen gesammelt hat.

Wichtig ist aber auch gleichzeitig, dass neue Kommentare meinerseits eingebunden sind. Daher wird bei einer noch bestehenden Session die Anweisung gegeben, dass die KI bitte die folgenden Kommentare berücksichtigen soll und mit dem Fix loslegen kann. Existiert die Session hingegen nicht mehr, geben wir den Fehler mitsamt der Analyse nochmal rein, ebenfalls mit meinen Kommentaren versehen.

In jedem Fall greift die KI dann auf den MCP zurück, mit dem sie Zugriff auf Home Assistant hat. So kann sie nicht nur Protokolle abrufen und den Fehler bestätigen, sondern auch weitreichende Dinge im System selbst verändern.

Dieses Stadium wird mir dann auf GitHub über das Label ai:working widergespiegelt.

Nach erfolgter Umsetzung sehe ich dann das Label ai:done und erhalte als neuen Kommentar zum Issue eine Zusammenfassung der Session, so dass ich alles nochmal nachvollziehen kann. Der Vorteil besteht dann für mich darin, dass ich auch nachträglich eine gute Einsicht in die Arbeitsweise gewonnen habe. Und sollten Fehler auftreten, dann kann ich sehen, was gemacht wurde. Auf diese Weise schaffe ich mir ein wenig mehr Transparenz, um die Kontrolle über mein System zu behalten.

Der Workflow für dieses Self-Healing wird dabei mehrfach am Tag angestoßen. Ich könnte demnach auch manuell einen Fehler erfassen, den die KI dann bei ihrem nächsten Durchlauf bearbeitet. Das System ist explizit darauf ausgerichtet, dass ich als Mensch jederzeit eingreifen kann.

Beispielhafter Workflow-Durchlauf

Machen wir die Theorie etwas deutlicher. Wir nehmen an, dass es in meinem System einen fiktiven Fehler gibt, der durch meinen Ablauf korrigiert werden soll.

Schritt 1) Shelly liefert in Home Assistant einen Timeout.

Schritt 2) Home Assistant schreibt diesen Fehler in sein Protokoll.

Schritt 3) n8n Workflow lädt sich im nächsten Durchgang alle Fehler, mitunter auch diesen.

Schritt 4) Es wird Deduplizierung angewandt und ein Fingerprint vom Fehler wird erzeugt.

Schritt 5) n8n bestimmt, dass dieser Fehler durch die KI analysiert werden soll.

Schritt 6) Zuerst wird dafür nachgesehen, ob es diesen Fehler schon auf GitHub gibt. Existiert er, wird er verworfen. In diesem Fall existiert er noch nicht und der Workflow arbeitet weiter.

Schritt 7) Die KI analysiert über den Home Assistant MCP die Lage in meinem Smart Home und erstellt einen Bericht, wie der Fehler ausgebessert werden kann.

Schritt 8) Der Fehler wird auf GitHub mitsamt der Analyse als Issue aufgenommen. Ich werde zudem benachrichtigt.

Schritt 9) Ich gebe den Fehler für die KI frei und ergänze (wenn notwendig) noch meine eigenen Informationen.

Schritt 10) Es werden die Kommentare aus dem Issue geladen. Diese wandern entweder in die noch bestehende Session bei OpenCode oder es wird eine neue Session mit dem gesamten Kontext gestartet. Die KI beginnt daraufhin mit dem Fix.

Schritt 11) Die Zusammenfassung der KI wird an das Issue geheftet und das Issue wird entsprechend mit ai:done markiert. Nun weiß ich, dass der Fix drin ist und sehe auch, was die KI gemacht hat.

Noch keine Vollautomatisierung

Mein kompletter Workflow ist bislang noch keine Vollautomatisierung. Das liegt vor allem daran, dass ich zum jetzigen Zeitpunkt noch viel zu wenig Erfahrung habe, wie sich das in der Praxis bemerkbar machen wird. Ich möchte zumindest vorläufig noch die Entscheidung darüber behalten, welche Fehler die KI ausbessert und von welchen sie sich fernhält.

Genau dafür eignet sich das Nutzen von Labels bei mir sehr gut. Ich kann so direkt beschränken, was die KI tut und wo ich doch noch selbst Hand anlegen will.

Zu einem späteren Zeitpunkt kann ich mir aber gut vorstellen, dass ich noch stärker in Richtung Vollautomatisierung gehen will. Was ich jedoch nicht beschränken will, ist die Zusammenfassung.

Wenn du selbst in der IT arbeitest, dann verstehst du diesen Punkt wahrscheinlich ziemlich gut. Gibt es irgendwann mal einen Fehler, dann musst du nachvollziehen können, wodurch dieser entstanden sein könnte. Hierzu hilft mir dann hoffentlich das Protokoll im Issue weiter, welches ich dann auf mögliche Fallstricke untersuchen kann. Im besten Fall finde ich den Fehler so ziemlich schnell und kann ihn auch beheben. Im Zweifel muss ich trotzdem weitersuchen oder habe mein Smart Home in den Sand gesetzt.

Daher auch an dieser Stelle nochmal der ausdrückliche Hinweis, dass du bei sowas unbedingt mit Backups arbeiten musst. Ohne ein sauberes Backup kannst du dir sonst wirklich Probleme schaffen, die du eigentlich gar nicht haben willst.

Was als nächstes geplant ist

Bevor ich dieses Kapitel nun für mich schließe und mir selbst einen Highfive gebe (nein, tue ich natürlich nicht), gibt es aber noch ein paar Optimierungen, die ich gerne einfließen lassen will.

Zuerst jedoch brauche ich ein wenig Praxiserfahrung. Das System, wie es jetzt aufgebaut ist, muss sich noch etwas beweisen. Aus den entstandenen Issues kann ich dann ableiten, wie oft die KI wirklich ran musste und welche Fehler doch eher von mir bearbeitet werden müssen. Das Verhältnis wird hierbei sehr interessant.

Was ich jedoch schon mit Sicherheit sagen kann ist, dass ich meinen Workflow noch etwas besser justieren will. Denn zum aktuellen Zeitpunkt unterscheidet er nicht zwischen Aufgaben für die KI und Aufgaben für mich. Das ist für mich noch der größte Punkt, den es zu lösen gilt.

Ich möchte in einer späteren Ausbaustufe anhand von den Labels sehen und filtern können, welche Aufgaben explizit von mir durchgeführt werden müssen. Denn wie schon das Batterie-Beispiel gezeigt hat, kann die KI einfach nicht alles umsetzen. Wenn ich hier eine bessere Übersicht habe und das System stabil funktioniert, dann könnte sogar weiter gehen.

Denn genau dann könnte man überlegen, ob die KI-Aufgaben wirklich komplett autonom bearbeitet werden. Die anderen habe ich zuvor ja schon rausgefiltert.

Außerdem muss ich natürlich noch sehen, ob die KI so sauber arbeitet, wie ich mir das auch vorstelle. Denn andernfalls muss ich möglicherweise in der Filterung oder Kategorisierung noch etwas nachbessern. Hier steht und fällt es einfach damit, was ich dem Modell an Input gebe. Gebe ich nur wenig hilfreichen Input, dann kann daraus auch nichts werden. Und eventuell muss vielleicht zuvor noch eine kurze Klassifizierung rein, ob es überhaupt ein Fall für die KI ist. Auch das soll sie dann möglichst selbst entscheiden.

Fazit

Wenn wir über den Einsatz von KI sprechen, dann müssen wir natürlich auch immer die Anwendungsfälle bedenken. Nicht überall wo wir KI reingeben, kommt automatisch etwas wunderbares raus. Aus meiner Sicht besteht die Herausforderung definitiv im Kontext und den präzisen Anweisungen. Das macht dieses Projekt so spannend.

Außerdem bin ich Daniel wirklich sehr für diese Inspiration dankbar. Denn alleine das Checken der Logs und möglicher Verbesserungen kann schon sehr zeitintensiv sein. Je nachdem, wie ausgelastet wir schon durch unseren Job oder die Familie sind, leidet so möglicherweise das Smart Home darunter. Was aber auch wiederum keine so gute Idee ist. Vor allem dann nicht, wenn sich alle so sehr daran gewöhnt haben, dass es eben rund laufen muss.

Hier sind wir also möglicherweise auf einen Anwendungsfall gestoßen (oder hingewiesen worden), der wirklich eine starke Ergänzung sein kann. Nicht weil die KI immer alles perfekt macht. Sondern weil sie uns gezielt im Alltag unterstützt und wir dadurch mehr Freiraum haben.

Was ich auf jeden Fall jedem da draußen raten würde ist, dass man den Prozess so transparent wie möglich gestaltet. Denn alleine schon durch diese Analyse und Zusammenfassung auf GitHub habe ich einen guten Einblick, wo die KI möglicherweise falsch gehandelt hat. Und ich kann der Sache ziemlich schnell entgegenwirken.

Wie stehst du zu einem selbst heilenden Smart Home? Und wie würde dein Aufbau aussehen?

Lass uns dieses Thema unten in den Kommentaren vertiefen.

Passend zum Thema

Passend zum Thema empfehle ich dir die Unterhaltung zwischen Daniel (aka The Smart Home Maker) und mir auf YouTube. Dort sprechen wir nicht nur über den Einsatz von KI als Tool für Automationen, sondern auch über das Self-Healing. Eine wirklich spannende Unterhaltung, die du dir bequem in einer ruhigen Phase anhören kannst.