Das selbst heilende Smart Home: Wie KI mein Haus am Laufen hält – damit ich es nicht muss

Das, was Dir niemand verrät, der dir Smart Home Geräte verkaufen will: ein Smart Home zerfällt langsam. Nicht dramatisch. Leise. Eine Batterie im Türsensor stirbt. Ein Zigbee-Gerät fällt aus dem Mesh. Eine Integration bricht nach einem Update, dessen Notes du nicht gelesen hast. Ein Token läuft ab. Und du merkst es nicht – bis die Automation, auf die du dich verlässt, einfach nicht auslöst. Meistens im ungünstigsten Moment.

Jahrelang war meine „Wartungsstrategie“ dieselbe wie bei allen: bemerken, dass etwas kaputt ist, seufzen, es reparieren. Je mehr Automationen ich baute, desto mehr Angriffsfläche gab es, und desto mehr Zeit steckte ich ins Löschen von Bränden statt ins Bauen. Irgendwann macht das keinen Spaß mehr.

Also habe ich das Modell umgedreht. Statt dass ich das Haus überwache, überwacht das Haus sich selbst – und zunehmend repariert es sich selbst. Genau dieses Setup habe ich mit Lukas von Hobbyblogging in der neuesten Podcast Folge durchgesprochen.

Komponenten-Status reicht nicht

Das meiste „Monitoring“, das man online findet, prüft Komponenten: Ist der Sensor online, ist die Integration geladen, ist die Platte voll. Nützlich, aber es verfehlt das, worauf es ankommt – den Use Case.

Ein Workflow kann „erfolgreich“ durchlaufen und seinen Job trotzdem nicht erledigen, weil das Eine, das er auslösen sollte, nicht gefeuert hat oder ins Leere lief. Überall grüne Haken, und das Ergebnis ist trotzdem ausgeblieben. Deshalb überwache ich auf zwei Ebenen: die Komponenten-Ebene und die Use-Case-Ebene – ist das, wofür das System existiert, tatsächlich passiert?

Die Architektur

Das Ganze ist ein Trichter. Vorne gehen viele laute Signale rein; hinten kommen wenige konkrete, priorisierte Aktionen raus.

1. Alles wird gelesen, jeden Tag. Ein automatisierter Lauf durchforstet die Logs, die ich manuell nie lesen würde – Home Assistant Core, Supervisor, das HA OS, dazu n8n, ESPHome und mein UniFi-Netzwerk. Separat läuft ein Security-Pass über jede Maschine (Tools wie Lynis und rkhunter), damit auch die Sicherheit des Systems gewürdigt wird. Update-Monitoring rundet es ab, denn ein vergessenes Update kann ebenso sicherheitskritisch oder Auslöser eines Ausfalls sein.

2. Ein Vorfilter trennt Signal von Rauschen. Nicht jede Warnung verdient deine Aufmerksamkeit. Ein erster Durchgang – teils feste Regeln, teils LLM – sortiert Fehler, die Handlung brauchen, von der Info-Geräuschkulisse, die es nicht tut. Nur das Relevante bekommt einen Platz in der Warteschlange.

3. Es läuft in einer fokussierten Session zusammen. Die gefilterten Findings landen in einer KI-Coding-Session mit vollem Kontext auf meiner eigenen Hardware – meine Regeln, meine Skills, mein Memory, Zugriff auf meine Systeme. Sie ist schlau genug, um wirklich zu diagnostizieren und, wo es sicher ist, zu reparieren. Aber ich will diese schwere Session nicht für jede Kleinigkeit hochfahren – genau deshalb ist der Filter so wichtig.

4. Findings werden zu Tasks – damit nichts verloren geht. Diesen Teil würde ich doppelt unterstreichen. Jedes Finding wird in ein Task-Management geschrieben, bevor irgendetwas anderes passiert. Sessions können abstürzen, Kontext verschwinden, ein Lauf mittendrin sterben. Egal: die Arbeit ist längst ein dauerhafter Task mit Priorität. Erledigte Tasks bleiben erledigt; offene warten. Nichts löst sich in Luft auf, nur weil eine Session weg ist.

5. Ein Dashboard überwacht die Use Cases selbst. Jede Fähigkeit, die ich baue, registriert sich selbst in einem Health-Dashboard – inzwischen ein paar hundert Use Cases, gruppiert nach Kategorie (die großen sind Automation und Content, daneben Security, Family, Health und Operations), jeweils markiert als grün, gelb, rot oder ruhend. „Ruhend“ ist übrigens kein Bug – manche Use Cases hatten schlicht noch keinen Grund zu laufen. Wird einer rot, wird er automatisch zum Task. Und weil sich jedes neue Feature selbst registriert, wächst das Monitoring mit dem System, statt hinterherzuhinken – jeder Use Case ist sogar direkt mit dem Workflow verdrahtet, der dahintersteckt.

Wo „Self-Healing“ aufhört und ich anfange

Natürlich kann das aber nicht 100 % autonom funktionieren, und das will ich auch nicht. Viele Probleme können automatisiert gelöst werden – eine kaputte Bedingung, eine fehlgezündete Automation, eine Config, die verrutscht ist. Aber eine leere Batterie, ein Gerät, das neu authentifiziert werden muss, eine Steckdose, die physisch stromlos gemacht werden muss? Das kann noch keine KI lösen – vielleicht irgendwann mal, wenn wir smarte Haushaltsroboter haben.

Also werden das meine Tasks. Ich bekomme einen kurzen Telegram-Anstupser: To-do + Kontext Infos dazu, zudem landet das Todo natürlich in der Todo-Liste. Ich hake es ab oder verschiebe es. Und jetzt der elegante Teil – die KI weiß, dass sie blockiert ist. Sie hämmert nicht weiter auf einem Use Case herum, der auf mich wartet; sie parkt ihn und macht weiter, und nimmt ihn genau in dem Moment wieder auf, in dem ich den Blocker auflöse.

Der Payoff

Das Ergebnis: mein Smart Home läuft deutlich zuverlässiger als vorher, als ich der einzige Überwachungspunkt war. Es gehen immer noch Dinge kaputt – je mehr Automationen, desto höher die Wahrscheinlichkeit – aber jetzt wird es schnell bemerkt und behoben, statt still zu failen bis ich es (meist zu spät) merke.

Das ist für mich das eigentliche Versprechen von KI im Smart Home. Kein Chatbot in deiner Küche. Ein System, das leise die undankbare Wartungsarbeit erledigt, die du sowieso nie durchgehalten hättest – damit deine Automationen ihre Versprechen halten und du zurück ans Bauen kommst.

Ich bin tief in dieses Setup eingestiegen – inklusive eines echt schmerzhaften Rollladen-Fails um Mitternacht – mit Lukas von Hobbyblogging in Folge #29 des Podcasts. Ganze Folge auf Spotify anhören »