Was nicht geklappt hat, und wie es sich mit einem KI-Assistenten baut

Am 20.09. kurz vor neun bekam unsere Matter-Brücke ein neues Gerät: einen Kontaktsensor namens „Küche Entfeuchter Bedarf“, Endpunkt 48. Fünfundzwanzig Minuten später war er wieder draußen.

Der Luftentfeuchter in der Küche hing an einer Tapo P110, und die konnte Home Assistant nicht schalten. Es gab keine TP-Link-Integration, das mitgelieferte python-kasa 0.10.2 beherrscht KLAP, AES und XOR, aber nicht das TPAP der P110, und die P110 hat, anders als die P110M, kein Matter. Alexa dagegen kannte die Steckdose. Also sollte der Bedarfsmelder über die Brücke zu Alexa, und zwei Routinen sollten die Tapo schalten:

Bedarfsmelder -> Matter-Brücke -> Alexa -> Tapo-Cloud -> Steckdose

Das wären zwei Clouds für eine Steckdose im selben Raum gewesen. Home Assistant hätte nicht einmal lesen können, ob sie geschaltet hat, und Durchsetzen, also alle 30 Minuten nachsehen und korrigieren, wäre unmöglich gewesen. Wir haben stattdessen Zigbee-Steckdosen bestellt. Seit dem 22.09. hängt der Entfeuchter an einer SONOFF S60ZBTPF, die Home Assistant örtlich schaltet und abliest (mehr dazu in Teil 6). Der Abschnitt über den Umweg steht weiter in der Doku, markiert als „Zurückgenommen am selben Tag“.

Dieser letzte Teil sammelt solche Geschichten und erzählt, wie die Arbeit mit einem KI-Assistenten lief.

Umwege, die wir wieder abgebaut haben

Die Spülmaschine. Ein Bosch-Gerät, also Home Connect, und die Integration ist in Home Assistant eingebaut. Sie läuft aber über die Hersteller-Cloud (iot_class: cloud_push) und verlangt ein eigenes Entwicklerkonto, eine dort registrierte Anwendung und eine OAuth-Anmeldung. Als die Anleitung vor uns lag, war unsere Antwort: zu umfangreich. Stattdessen soll eine weitere S60ZBTPF vor die Maschine. Aus ihrer Leistungskurve lässt sich ablesen, wann ein Programm fertig ist, ohne Konto und ohne Cloud. Gebaut ist das noch nicht.

Hue über die alte Bridge. Der erste Plan sah vor, die Hue-Lampen übergangsweise über die vorhandene Bridge 1.0 einzubinden und später ins eigene Zigbee-Netz umzuziehen. Wir haben gefragt, warum nicht gleich direkt. Der Einwand hielt: Beim Umzug hätten sich alle Entitäten geändert, und jede Automation auf light.hue_wohnzimmer wäre gebrochen.

Der Staubsauger-Schalter. Mit dem Matter-Typ RoboticVacuumCleaner kann Alexa wenig anfangen. Auf „starte den Staubsauger“ kam „unterstützt das nicht“. Claude baute einen Vorlagenschalter (ein: vacuum.start, aus: vacuum.return_to_base). Sieben Minuten später war er auf unseren Wunsch wieder draußen, weil wir erst die Alexa-App durchsehen wollten. Dort ließen sich die Betriebsarten zwar einstellen, aber nicht in Routinen verwenden. 47 Minuten später kam der Schalter zurück, laut Commit „diesmal aus belegtem Grund“. Dazwischen fiel auch die eigene Staubsaugerbrücke auf Port 5541 durch, denn Alexa koppelt laut Änderungsprotokoll der Brücke nur auf 5540 zuverlässig.

Worauf wir bewusst verzichten

Die Türklingel. Sie ist nicht angebunden, weil dafür das Cloud-Passwort des Herstellers auf dem Server hätte liegen müssen. Das wollten wir nicht, also gibt es die Klingel in Home Assistant nicht.

Die Govee-Cloud. Für die TV-Hintergrundbeleuchtung gab es zunächst nur eine HACS-Integration, die die Govee-Kontodaten auf dem Server braucht. Gebaut haben wir sie nicht. Wie die Leiste trotzdem lokal wurde, steht weiter unten.

Boost am AVM-Ventil. Zum schnellen Aufheizen läge der AVM-Modus Boost nahe. Er öffnet voll, meldet dabei aber keinen Sollwert, temperature wird leer. Die Handgriff-Erkennung über den Merker und die Anbindung an Alexa über Matter kämen damit nicht zurecht. Das Ventil bekommt stattdessen 28 °C, seinen Höchstwert (Teil 2).

Was Erfolg meldet und nichts tut

Die Fenster-offen-Erkennung der AVM-Ventile. In unserer Bestandsaufnahme vom 29.08. stand noch: nicht nachbauen, die Thermostate regeln selbst herunter. Am 25.09. zeigte der Verlauf im Schlafzimmer drei Morgen mit rund einer Stunde Lüften. Am 23.09. fiel der Taupunkt dabei von 15,3 auf 6,7 °C und der Raum auf 16,8 °C. binary_sensor.heizung_schlafzimmer_offenes_fenster_erkannt blieb an allen drei Tagen aus. Der Kopf des Ventils sitzt am Heizkörper und kühlte zu langsam ab, also stand das Ventil offen und heizte nach draußen.

Gruppenbindungen nach dem Firmwaresprung. In der Küche meldete Zigbee2MQTT sauber Successfully bound cluster 'genOnOff' an die Gruppe der beiden Deckenlampen. Das Licht blieb trotzdem dunkel. Die Gruppe selbst war intakt, denn direkt geschaltet gingen beide Lampen an. Geholfen hat nur, jede Lampe einzeln an den Melder zu binden (Teil 5).

Das Kennzeichen dry des Pflanzensensors. Es stand bei 11 % Bodenfeuchte auf None, obwohl der geräteeigene Warnwert bei 20 % liegt. Das Gerät sendet es offenbar nur bei Änderung. Die Gießmeldung baut deshalb auf dem Zahlenwert soil_moisture auf.

Die Heizung im Sommerbetrieb. Ein smartes Ventil kann nur öffnen, ob Wärme kommt, entscheidet die Therme. Am 27.09. stand das Schlafzimmerventil auf 28 °C, also ganz offen. Trotzdem kühlte sein Kopf am Heizkörper ab, während es draußen wärmer wurde:

Das passt zur Sommer/Winter-Umschaltung der Therme nach Außentemperatur. Lesen können wir die Therme nicht, deshalb heißt es in der Doku „sehr wahrscheinlich“. Schon am 31.08. hatte die neue Regelung die Ventile im Essbereich auf Komfort 23 °C gestellt, obwohl der Kessel im Sommerbetrieb lief. Ein Ventil, das auf ein unerreichbares Ziel regelt, steht offen und fährt dauernd nach. Uns fiel auf, dass das Wintergartenventil „regelmäßig in minimalen Bewegungen“ justierte. Seitdem gibt es den Schalter input_boolean.heizperiode.

Wie es sich mit Claude baut

Claude (Claude Code) hat auf dem Server gearbeitet: Konfiguration, Automationen, Messungen, Doku und Commits. Wir haben entschieden, bestätigt und oft widersprochen. In einem Monat kamen 138 Commits zusammen, 24 davon beginnen mit „fix“, zwei mit „revert“.

Die Regeln, die getragen haben

Erst ein Vorschlag mit Begründung, dann ein „ja“, dann die Umsetzung. Am 25.09. kamen drei Vorschläge fürs Schlafzimmer, mit dem Satz „ich baue nichts ohne dein ‚ja‘“. Zwei haben wir genommen, die eigene Fenster-Erkennung über den Taupunkt haben wir zurückgestellt. Beim Windfang haben wir „Wärme bei Anwesenheit“ gewählt und „Mindesttemperatur halten“ verworfen.

Für die FRITZ!Box galt ausdrücklich: nichts ohne Bestätigung. Trotzdem steht hier der teuerste Fehler des Monats. Am 02.09. hatten wir dem Box-Benutzer vorübergehend mehr Rechte gegeben und darum gebeten, vorher zu fragen. Claude legte Vorschläge vor, und wir sagten ja. Die Einstellseite eines Heizkörperreglers ist aber ein HTML-Formular und keine Schnittstelle. Speichern heißt dort, alles zurückzusenden. Claude las alle 54 Felder, änderte zwei und schickte alles zurück:

Absenktemp  17 -> 16                   angekommen
Heiztemp    22 -> 23                   angekommen
Versatz, Name, Fenstertimer            erhalten
Wochenplan                             GELOESCHT

Das Risiko war vorher benannt worden. Claude brach nach dem ersten Gerät ab, und die drei anderen blieben unberührt. Wenige Minuten später stand der Fehler als eigener Commit in der Doku. Daraus haben wir gelernt: Ein „ja“ deckt die Entscheidung, aber nicht das technische Risiko. Seitdem laufen Sollwerte über die AHA-Schnittstelle, alles andere erledigen wir von Hand in der Oberfläche.

Messen vor dem Ändern. Bevor Claude am 27.09. den Schaltabstand des Gästezimmerventils anfasste, stand im Verlauf, dass es um 11:43:08 genau bei 21,0 °C öffnete, bei einem Ziel von 22. Erst danach ging der Wert von −1,0 auf −0,4 (Teil 3).

Jede Formel vor dem Einbau über die Vorlagen-Schnittstelle prüfen. Die Vorlagen wurden genau so geprüft, wie sie in der Konfiguration stehen, mit einem Testfall für jeden Zweig: Aufheizen, Landen im letzten halben Grad, Absenkung, ausgefallener Fühler. Für die Änderung vom 25.09. stehen fünfzehn solcher Fälle in der Doku. Schon der erste Test der Fernseh-Automation am 29.08. fand einen eigenen Fehler: Sie dimmte die Couchlampe von 10 auf 30 % hoch.

Jede Änderung mit Datum und Begründung dokumentieren und committen. Das gilt auch für Rücknahmen. Ein Abschnitt heißt deshalb „Korrektur: Nachregeln konnte nicht mehr herunter“.

Nach dem Setzen zurücklesen, bei Geräten direkt vom Gerät. Home Assistant verwirft Werte außerhalb von min/max ohne Meldung (Teil 7). Den neuen Schaltabstand hat Claude deshalb beim Ventil selbst abgefragt, mit zigbee2mqtt/Heizung Gästezimmer/get. Zurück kam −0,4.

Wo wir korrigieren mussten, und einmal umgekehrt

„Der hat keinen Display.“ Claude riet, den neuen Wohnzimmerfühler so aufzuhängen, dass man die Anzeige lesen kann. Der SNZB-02B hat aber keine Anzeige. Claude hatte ihn mit dem SNZB-02D verwechselt.

Die Govee-Leiste kann doch Matter. Am 29.08. schien nach einer Websuche klar zu sein, dass es keinen lokalen Weg gibt. Tags darauf fanden wir auf dem Gerät einen Matter-Kopplungscode. In der Doku steht seitdem: „meine Recherche … war falsch“. Gekoppelt wurde über Bluetooth, ganz ohne Govee-Konto.

„Komforttemperatur auf 8 Grad.“ So stand es am 24.09. in unserer Nachricht. Claude setzte nichts, sondern fragte zurück: 8 oder 18? Bei 8 wäre das Zimmer in seiner Komfortzeit kälter gewesen als nachts. Gemeint waren 23 °C Komfort und 18 °C Absenkung. Keine der beiden Lesarten hätte gestimmt, nur die Rückfrage war richtig.

Die Höhe beim Wetterdienst. In Home Assistant stand als Höhe 0, und Claude fragte nach der Höhe des Hauses. Unser Einwand war: Wenn der Dienst die nächstgelegene Station nimmt, steckt deren Höhe doch schon drin. Claude hat nicht einfach zugestimmt, sondern nachgesehen und gemessen. Met.no ist ein gerechnetes Gittermodell, und die mitgeschickte Höhe sagt ihm, auf welche Höhe er umrechnen soll. Mit 0 m lag die Temperatur gut fünf Grad höher als mit der Höhe des Hauses, am selben Ort in derselben Minute (Teil 6). Unser Einwand klang vernünftig und war falsch. Messen diszipliniert beide Seiten.

Fehler, die auf Claudes Konto gehen

Der State-API-Fall ist der lehrreichste. Die MQTT-Entität vergleicht eine neue Meldung mit ihrer eigenen letzten Meldung, nicht mit dem angezeigten Zustand. Der Fühler meldete zweimal 19,9, und Home Assistant zeigte weiter den Testwert 16,2.

Was gut funktioniert hat

Fehlersuche mit Verlaufsdaten. Befunde stehen mit Messreihe in der Doku, Vermutungen sind als solche markiert. Wie das an einem kalten Büro aussieht, zeigt Teil 2.

Merkzettel für wiederkehrende Fallen. Claude führt inzwischen 19 Merkzettel, die meisten zu Fallen wie denen oben. Ganz ehrlich: pkill und der still verworfene input_number-Wert haben trotzdem je zweimal zugeschlagen, und erst danach stand die Falle auf einem Zettel. Seitdem prüfen die Testskripte nach jedem Setzen, ob der Wert angekommen ist.

Lückenlose Doku. Rund 37 000 Wörter in docs/, jeder Abschnitt mit Datum. Bei Korrekturen bleibt der alte Stand meist daneben stehen. Aus dieser Doku speist sich diese Serie.

Unterm Strich

Claude hat in einem Monat viel umgesetzt, viel gemessen und gründlich aufgeschrieben. Es hat auch Fehler gemacht, ein paar vermeidbare und einen mit begrenztem, aber echtem Schaden. Die Entscheidungen blieben bei uns, und einige der wichtigsten Hinweise kamen von uns: der Einwand gegen die Hue-Bridge, der Matter-Code auf der Govee-Leiste, das fehlende Display, das zuckende Wintergartenventil. Was ein Assistent nicht aus Dateien lesen kann, ist das Haus selbst. Dass der Bewegungsmelder drinnen im Windfang hängt, mussten wir bestätigen. „Das war nicht aus den Namen abzuleiten“, steht in der Doku.

Was wir mitnehmen

• Kann Home Assistant den Zustand eines Geräts nicht lesen, kann es ihn auch nicht durchsetzen. Dann lieber das Gerät tauschen, als eine Kette über zwei Clouds zu bauen.
• „Erfolgreich“ im Protokoll heißt nicht, dass etwas wirkt. Die Gruppenbindung meldete Erfolg, check_config meldete valid, die Fenster-Erkennung meldete nichts, und in allen drei Fällen passierte nichts. Nur ein Funktionstest zeigt die Wirkung.
• Ein „ja“ deckt die Entscheidung, nicht das technische Risiko. Bei Formularen und unklaren Schnittstellen erst an einem Gerät versuchen, dann anhalten und prüfen.
• Einwände messen statt ausdiskutieren. Das gilt für den Assistenten und für uns.
• Nach jedem Test mit überschriebenen Werten den echten Zustand zurücksetzen und vom Gerät zurücklesen.
• Irrwege nicht löschen, sondern als zurückgenommen markiert stehen lassen. Man braucht sie wieder.

Ein Monat, von Ende August bis Ende September: Aus einer alten Hue-Bridge, ein paar FRITZ!DECT-Ventilen und vielen Alexa-Geräten ist ein Home Assistant geworden, der lokal läuft, sechs Heizkörperventile nach Raumfühlern regelt und Entscheidungen auf Messwerte stützt. Vieles davon hat beim ersten Versuch nicht geklappt. Dass es heute trägt, liegt an den Messungen, an den Rückfragen in beide Richtungen und daran, dass jeder Irrweg aufgeschrieben ist.