Beide kamen heim — die Automatisierung schwieg

An der Wohnungstür in Meran hängt ein Tedee-Schloss, eingebunden über seine lokale Bridge. Daran hängt eine Automatisierung: Wer aufsperrt, löst ein Kamerabild aus, und die Meldung geht hinaus.

Sie hat funktioniert. Das erste Bild entstand am 9. August um 15:49:33, 65 Kilobyte.

Am 13. August kamen beide Bewohner heim, um 18:12 und um 18:18. Kein Bild, keine Meldung. Die Automatisierung hatte in ihrer ganzen Laufzeit null Aufzeichnungen — der letzte Eintrag stammte vom Handtest des Vortags.

Zuerst war der Ablageort falsch

Das war der harmlose Teil, und er ist trotzdem wichtig. Die Bilder lagen zunächst im Ordner für statische Dateien:

Ablageort	abrufbar?
/config/www/… → /local/…	HTTP 404 — gemessen
/media/schnappschuesse/…	sofort im Medien-Browser sichtbar

Der Ordner wird beim Start registriert. Dateien, die später dazukommen, liefert Home Assistant nicht aus — deshalb der 404.

Und selbst nach einem Neustart bliebe ein zweites Problem:

/local ist unauthentifiziert. Jeder, der die Instanz erreicht, könnte Türbilder ohne Anmeldung abrufen.

Ein Bild von der eigenen Haustür ist kein Dekomaterial. Geändert wurde eine einzige Zeile — der Zielpfad —, und seitdem liegen die Bilder hinter der Anmeldung, sichtbar unter Medien → Meine Medien.

Und dann der stille Ausfall

Die Automatisierung horchte auf den Wechsel von gesperrt nach entsperrt. Das klingt wie die einzig sinnvolle Bedingung.

Der aufgezeichnete Verlauf des Schlosses sagt etwas anderes:

10:22:18  locked
18:12:45  unlocking        18:18:41  opening
18:12:52  opening          18:18:42  open
18:12:53  open             18:18:45  unlocked
18:12:55  unlocked

Den Sprung von locked nach unlocked gibt es nicht. Dieses Schloss läuft über unlocking → opening → open und erreicht unlocked erst aus open heraus.

Die Bedingung konnte also nie greifen. Und sie scheitert auf die unangenehmste Art:

Keine Fehlermeldung, keine Aufzeichnung, kein roter Punkt. Nur Stille. Genau die Fehlerart, die man monatelang nicht bemerkt — weil „nichts passiert“ aussieht wie „es war nichts“.

Der Beleg kam von der Schwesterautomatisierung

Das ist der Teil, der die Diagnose von einer Vermutung zu einem Beweis gemacht hat.

Am selben Schloss hängt eine zweite Automatisierung, die eine Kamera scharf schaltet, wenn die Tür zu ist. Dieselbe Entität, derselbe Zeitpunkt — nur mit einem Unterschied: Sie horcht auf to: unlocked ohne Angabe, woher.

Sie hat um 18:18:45.348 sauber angeschlagen. In derselben Millisekunde, in der die andere schwieg.

Zwei Automatisierungen, eine Entität, ein Ereignis, ein unterschiedliches Ergebnis. Der Unterschied lag allein in der Angabe des Ausgangszustands.

Ein from: in einem Zustandsauslöser ist keine Präzisierung. Es ist eine stille Annahme über die Zwischenzustände eines Geräts — und die kennt man nicht, bevor man sie nachgesehen hat.

Nachsehen geht in einer Zeile: den Verlauf dieser einen Entität über die Schnittstelle abfragen und die Zustandsfolge lesen.

Die Berichtigung, und zwei Feinheiten darin

Der Auslöser hat jetzt zwei Fälle und keine Herkunftsangabe:

triggers:
  - trigger: state
    entity_id: lock.<tür>
    to: open        # jemand kommt wirklich herein
  - trigger: state
    entity_id: lock.<tür>
    to: unlocked    # entsperrt ohne zu öffnen, etwa aus der Ferne
mode: single
max_exceeded: silent

Zwei Auslöser, weil es zwei Ereignisse sind. Jemand öffnet die Tür — oder jemand entsperrt sie, ohne zu öffnen, etwa für einen Handwerker.

Und genau eine Meldung, obwohl beide greifen. Aus der Folge open → unlocked innerhalb von zwei Sekunden feuern beide Auslöser. Der zweite fällt weg, weil der erste noch läuft — dafür steht mode: single da. Und max_exceeded: silent sorgt dafür, dass dieses gewollte Verwerfen nicht als Warnung im Protokoll landet.

Letzteres klingt nach Kosmetik und ist keine: Ein Protokoll voller Warnungen, die alle in Ordnung sind, ist ein Protokoll, das niemand mehr liest.

Eine Entscheidung zur Kamera, die ich wichtig finde

Die Türkamera läuft auf Akku. Der erste Griff ins Bild kann misslingen, weil das Gerät gerade aufwacht.

Beide Schnappschuss-Schritte haben deshalb ein „weiter bei Fehler“ gesetzt:

Lieber eine Meldung ohne Bild als kein Bild und keine Meldung.

Ein Schritt, der eine ganze Automatisierung abbricht, weil ein Nebenprodukt misslungen ist, ist falsch gewichtet. Die Meldung ist das Wesentliche, das Bild die Zugabe.

Was ich dir rate

1. Sieh dir den echten Zustandsverlauf an, bevor du einen from:-Auslöser baust. Geräte haben Zwischenzustände, die in keiner Dokumentation stehen.
2. Miss, ob deine Automatisierung jemals ausgelöst hat. Die Zahl der Auslösungen ist die billigste Prüfung, die es gibt — und sie hätte hier sofort „null“ gesagt.
3. Leg Türbilder hinter die Anmeldung. Der Ordner für statische Dateien ist offen und liefert später hinzugekommene Dateien ohnehin nicht aus.
4. Nimm zwei Auslöser, wenn es zwei Ereignisse sind — und mach aus der Doppelung bewusst eine einzige Meldung.
5. Lass eine Automatisierung nicht an ihrer Zugabe scheitern. Ein misslungener Schnappschuss darf die Meldung nicht verhindern.
6. Halt dein Protokoll sauber. Gewolltes Verwerfen gehört nicht als Warnung hinein.

Und was heißt das?

Vier Tage lang war die Tür unbeobachtet, und niemand hätte es gemerkt. Der Unterschied zu einem lauten Fehler ist, dass ein lauter Fehler eine Nachricht schickt. Hier gab es nichts — das System war der Meinung, alles sei in Ordnung, denn aus seiner Sicht war nie etwas zu tun.

Das ist dasselbe Muster wie bei dem Umlaut, der meinen Frostalarm getötet hat und bei dem Wächter, der auf den falschen Zustand wartete. Dreimal dieselbe Bauart: eine Bedingung, die eine Annahme über das Gerät enthält, und ein Gerät, das sich anders verhält.

Gefunden habe ich es nur, weil zufällig eine zweite Automatisierung an derselben Entität hing und sauber angeschlagen hat. Ohne diese Gegenprobe hätte ich das Schloss verdächtigt, die Kamera, den Meldeweg — alles, nur nicht den einen Parameter, der das Problem war.