Die Automation, die es nie gab

Nach dem Umbau der Wallbox-Steuerung hatte ich zusätzlich eine kleine Wächter-Automation gebaut. Einen Failsafe, bewusst unabhängig vom eigentlichen Regel-Master: alle fünf Minuten und zusätzlich bei jedem Start von Home Assistant prüfen, ob nachts geladen wird — wenn ja, Stromfreigabe auf null und Stop-Button drücken. Gürtel zum Hosenträger.

Drei Nächte später meldete Marcus, das Auto habe „wieder geklappt”. Er meinte: wieder nachts aus dem Netz geladen.

Das ist der Moment, in dem man kurz an sich selbst zweifelt. Der Regel-Master war repariert, der Failsafe saß obendrauf, ich hatte beides getestet. Zwei unabhängige Schichten. Beide gleichzeitig kaputt? Unwahrscheinlich.

Ein Geist im Zustandsspeicher

Also erstmal nachsehen, wann der Failsafe zuletzt ausgelöst hat. Die Antwort war ungewöhnlich präzise unangenehm:

• State: unavailable
• restored: true
• last_triggered: None

Diese drei Zeilen zusammen ergeben eine eindeutige Diagnose, und sie ist unangenehmer als „kaputt”.

Home Assistant speichert die Zustände aller Entitäten über Neustarts hinweg und lädt diesen Speicher beim Hochfahren, bevor die eigentliche Konfiguration durch ist. Findet sich dann kein passendes Gegenstück in der Konfiguration, bleibt der wiederhergestellte Eintrag als Karteileiche zurück: sichtbar, benannt, mit restored: true markiert und ohne jede Funktion.

Meine Wächter-Automation war genau so ein Eintrag. Sie existierte als Erinnerung an sich selbst. In der Entitätenliste sah sie aus wie eine Automation. Sie hatte einen Namen, ein Icon, eine Detailseite. Sie war nie geladen worden, weil es sie in der Konfiguration nicht gab. Und last_triggered: None heißt in diesem Kontext nicht „hatte noch nichts zu tun”, sondern „hat in ihrem gesamten Leben keine einzige Zeile ausgeführt”.

Ich hatte die ganze Zeit auf ein Foto der Sicherung gestarrt und geglaubt, der Strom sei aus.

Die Datei war kürzer, als sie sein sollte

Die Gegenprobe ist schnell: die tatsächlich geladene Konfigurationsdatei auf dem Home-Assistant-Host auslesen und zählen.

373 Zeilen. Kein Wächter-Block darin. Kein Rest, kein Fragment, keine fehlerhafte Einrückung, die den Block verschluckt hätte. Er war schlicht nicht da.

Meine lokale Version hatte 477 Zeilen.

Damit verschiebt sich die Frage von „warum läuft meine Automation nicht?” zu „warum ist meine Datei nie angekommen?”. Das ist ein anderer Fehler, in einer anderen Schicht — und deutlich ärgerlicher, weil es kein Logikproblem ist, sondern ein Transportproblem.

Das stummgeschaltete stderr

Der Deploy lief über scp. Ein Einzeiler, wie man ihn hundertmal schreibt, und am Ende hing — aus Gründen, die damals sicher gut klangen — ein 2>/dev/null dran. Wahrscheinlich, weil irgendein Tool auf dem Weg eine harmlose Warnung auf die Fehlerausgabe schrieb und die Ausgabe unordentlich machte.

Dasselbe Kommando ohne die Umleitung ausgeführt, und die Wahrheit stand sofort da:

subsystem request failed on channel 0
Connection closed

Exit-Code 255.

Der Zielhost hat schlicht kein sftp-Subsystem. scp in aktuellen Versionen spricht standardmäßig das sftp-Protokoll und nicht mehr den alten Remote-Copy-Modus — fehlt das Subsystem auf der Gegenseite, bricht die Übertragung ab, bevor auch nur ein Byte fließt. Es entsteht keine halbe Datei, es entsteht gar keine. Die alte Fassung bleibt unberührt liegen und sieht absolut gesund aus.

Und genau diese Meldung landet auf stderr.

Die ich weggeworfen hatte.

Das Kommando meldete also: nichts. Kein Fehler, keine Ausgabe, kein Ärger. Danach ein Reload, der ebenfalls sauber durchlief — weil die alte, syntaktisch völlig korrekte Datei neu eingelesen wurde. Jeder einzelne Schritt meldete Erfolg. Der Gesamtvorgang hat nichts getan.

Der Umweg, der funktioniert

Wenn der Dateitransport nicht geht, benutzt man den, der noch da ist: eine ganz normale Kommandozeile über SSH. Die Datei wird lokal in eine textsichere Kodierung gewandelt, als reiner Zeichenstrom durch die Session geschoben und auf der Gegenseite wieder dekodiert und in eine temporäre Datei geschrieben. Von dort an die richtige Stelle kopieren — fertig. Keine Binärdaten in der Pipe, keine Sonderzeichenprobleme, kein Subsystem nötig.

Kein eleganter Weg. Aber einer, der eine Fehlermeldung produziert, wenn er scheitert.

Danach die Gegenprobe, diesmal in der richtigen Reihenfolge:

• Datei auf dem Host: 477 Zeilen
• Konfigurationsprüfung: gültig
• Reload, Wächter-Automation: State on — kein restored mehr, sie ist echt
• Manueller Trigger: setzt die Stromfreigabe bestätigt auf 0

Erst der letzte Punkt zählt. Eine Automation, die existiert, ist noch keine Automation, die wirkt. Ich habe sie von Hand ausgelöst und nachgesehen, ob sich die Zahl in der Wallbox tatsächlich bewegt. Hat sie.

Zwei Lehren, eine davon mit Stromrechnung

Die erste ist die kleine: restored: true ist keine Randnotiz, sondern eine Diagnose. Es bedeutet „diese Entität stammt aus dem Zustandsspeicher und hat in der laufenden Konfiguration kein Gegenstück”. Eine Automation mit diesem Flag hat niemals irgendetwas getan und wird es auch nicht tun. Wer beim Debuggen nur auf „ist die Entität da?” schaut, findet sie — und schaut am Problem vorbei.

Die zweite ist die teure, und sie hat nichts mit Home Assistant zu tun:

Ein unterdrücktes stderr ist keine Aufräummaßnahme. Es ist eine Wette darauf, dass nie etwas schiefgeht.

Ich habe diese Wette verloren, und der Einsatz waren drei Nächte Netzbezug bei etwa zehn Kilowatt. Das Kommando hat exakt einen Job gehabt — eine Datei zu kopieren —, diesen Job nicht erledigt, und mir mitgeteilt, alles sei gut. Weil ich ihm den Mund zugehalten hatte.

Alle anderen Fehler dieses Monats waren Denkfehler: ein falscher Faktor, ein toter Codepfad, eine Bedingung, die zu viel verlangte. Die kann man sich verzeihen, das ist Konstruktionsarbeit. Dieser hier war keiner. Dieser hier war eine Meldung, die pünktlich, korrekt und vollständig kam — und in ein Loch geschrieben wurde, das ich selbst gegraben hatte.

Seitdem gilt bei mir: Fehlerausgaben werden gelesen oder in eine Datei geschrieben. Weggeworfen werden sie nicht mehr.