Ein Umlaut hat meine Frostwarnung getötet

Die Wohnung in Meran steht im Winter leer. Der wichtigste Alarm dort ist die Kältewarnung: Wenn die Räume zu stark auskühlen, muss ich das erfahren, bevor etwas einfriert.

Diese Warnung war seit ihrem Bau im August tot. Zweieinhalb Monate lang.

Der Grund ist ein Umlaut.

Was passiert ist

Beim Durchgehen der Entitäten nach einem Update fiel auf, dass ein Sensor fehlte. Die Vorlage rendert einwandfrei, alle anderen Entitäten des Pakets sind da.

Im Register stand er aber so:

sensor.kalteste_raumtemperatur     unique_id: kaelteste_raumtemperatur

Home Assistant streicht Umlaute beim Bilden der entity_id. Es transkribiert sie nicht.

"Kälteste Raumtemperatur"           -> sensor.kalteste_raumtemperatur
"Kältewarnung Schwelle Entwarnung"  -> sensor.kaltewarnung_schwelle_entwarnung

Aus ä wird a, nicht ae. In meinem Paket stand überall die ae-Form. Die Auslöser zeigten damit auf Entitäten, die es nie gab.

Und es stand jedes Mal im Protokoll

Das ist der Teil, der wehtut. Home Assistant hat bei jedem einzelnen Start geschrieben:

Error initializing 'Kältewarnung: Wohnung kühlt zu stark aus' trigger:
   In 'numeric_state' condition: unknown entity sensor.kaelteste_raumtemperatur

Seit August. Bei jedem Neustart. Niemand hat es gelesen.

Ein Fehler im Startprotokoll, den niemand liest, ist genauso stumm wie gar kein Fehler. Und eine Schutzfunktion, die beim Start scheitert, verhält sich im Betrieb exakt wie eine, die nie auslöst, weil nichts passiert.

Das ist der Unterschied zwischen „es funktioniert“ und „es hat noch nie etwas gemeldet“. Bei einem Alarm sehen beide Zustände monatelang identisch aus.

Die Korrektur war eine Zeile. Nach dem Ausrollen und einem Neustart steht der Sensor auf 20,5 °C, die Entwarnungsschwelle bei 13,0, und beide Automatisierungen sind aktiv.

Die Stolperstelle steht jetzt als Kommentar im Paket. Und ein Detail dazu: Die unique_id darf die ae-Form behalten — sie bestimmt die entity_id nicht.

Zweiter Fund: eine vergessene Kopie

Dasselbe Paket, das jeder Geschwindigkeitsmessung ihr Wetter mitgibt, hat eine eigene Kopie der Wetterstationsabfrage. Bewusst so gebaut, damit das Wetterpaket unangetastet bleibt.

Beim Umzug auf eine neue Datenquelle wurde diese Kopie übersehen. Sie erzeugte seither alle fünf Minuten einen Fehler.

Das ist die Kehrseite einer sauberen Trennung: Zwei Kopien bedeuten zwei Stellen zum Ändern, und die zweite vergisst man.

Beim Umstellen kamen zwei Eigenheiten der neuen Quelle dazu, beide unscheinbar und beide fehlerträchtig:

• Der Zeitstempel hat ein Leerzeichen statt des Trennzeichens und eine Zeitzone ohne Doppelpunkt. Beides lehnt die Zeitstempel-Prüfung ab.
• Die Antwort enthält mehrere Datensätze je Messgröße, darunter uralte von 2021 und 2022. Man muss sortieren und den letzten nehmen — wer den ersten nimmt, bekommt ein Wetter von vor fünf Jahren.

Nebenbei beantwortet der neue Sensor eine Frage, die ich vorher nicht gestellt hatte: Die Stationsdaten laufen rund zwei Stunden nach. Das ist wichtig, wenn man Wetter neben eine Messung schreibt — man schreibt dann nicht das Wetter von jetzt daneben.

Dritter Fund: ein Befehl ohne Shell

Ein frisch ausgerolltes Paket scheiterte sofort. Derselbe Befehl lief im Terminal des Geräts fehlerfrei durch — es lag also weder an Rechten noch an Pfaden.

Steckt in einem Befehl eine Vorlage, startet Home Assistant ihn ohne Shell.

Verknüpfungen und Umleitungen landen dann als wörtliche Zeichenketten beim ersten Programm. Ein > ist dann kein Umleiten mehr, sondern ein Argument.

Die Lösung ist, die Shell ausdrücklich aufzurufen und den veränderlichen Teil so zu übergeben, dass er nie in die Zerlegung der Befehlszeile gerät.

Dabei fiel ein zweiter Mangel auf, der schlimmer gewesen wäre: Die Kopfzeile der Datei kannte zwei neue Fühler nicht. Das Gerät hätte also ein anderes Spaltenschema geschrieben als das Auswertungsskript — und die beiden Reihen wären später nicht zusammenführbar gewesen.

Ein Fehler, der erst beim Zusammenführen aufgefallen wäre, also Wochen später und mit einem Datenverlust, den man nicht mehr reparieren kann.

Und zwei Befunde, die ich zurücknehmen musste

Das gehört zum selben Abend, und es gehört hierher.

„Doppelte YAML-Schlüssel überschreiben sich still.“ Das stand so in meiner Doku über eine bestimmte Datei. Zu alarmistisch. Die Datei benutzt einen regulären Mechanismus, um gezielt zwei Felder zu überschreiben — das ist Standard und greift sauber. Live nachgeprüft: alle Abfragen liefern ihre eigenen Parameter, die Zahlen stimmen. Die Warnung im Protokoll ist Kosmetik, kein Defekt.

„Die letzte Sicherung ist sechs Tage alt.“ Auch falsch. Ich hatte das letzte Element einer unsortierten Liste erwischt. Es gibt eine automatische Sicherung vom Vortag.

Beide Rücknahmen sind mir wichtiger als die drei Funde. Ein Befund, der sich nicht halten lässt, muss genauso sichtbar zurückgenommen werden, wie er aufgeschrieben wurde — sonst steht er in einem halben Jahr als Tatsache da und jemand handelt danach.

Was ich dir rate

1. Lies dein Startprotokoll. Einmal nach jedem Ausrollen. Ein Fehler beim Initialisieren einer Automatisierung ist unsichtbar, solange niemand hinsieht.
2. Prüf, wie dein System Umlaute behandelt. Nicht raten. Eine Entität anlegen, nachsehen, wie sie wirklich heißt.
3. Teste Alarme, indem du sie auslöst. Ein Alarm, der nie gemeldet hat, ist nicht dasselbe wie ein Alarm, der funktioniert. Bei einer Kältewarnung heißt das: Schwelle hochsetzen, warten, zurücksetzen.
4. Zähl deine Kopien. Bewusst duplizierte Konfiguration ist in Ordnung — aber schreib an beide Stellen, dass es die andere gibt.
5. Nimm zurück, was sich nicht hält. Und zwar dort, wo es stand.

Und was heißt das?

Drei Fehler, die alle drei still waren. Keiner hat eine Meldung erzeugt, die jemanden erreicht hätte. Zwei hätten nur Daten gekostet — der dritte hätte im Januar eine eingefrorene Leitung bedeutet.

Das Muster dahinter ist immer dasselbe: Das System hat es gesagt, nur nicht laut genug. Der Umlaut stand im Protokoll, der tote Endpunkt stand im Protokoll, der Befehl ohne Shell hat einen Rückgabewert geliefert.

Eine Anlage, die ihre eigenen Fehler nur ins Protokoll schreibt, ist eine Anlage, die schweigt.