Eine geratene Wartezeit ist keine Prüfung

Die Wohnungstür in Meran sperrt sich selbst ab, wenn beim Hinausgehen der Taster lange gedrückt wird. Dafür musste sie erst wissen, ob sie überhaupt zu ist.

Der Türkontakt dazu ist montiert. Und er ist kein Zigbee-Gerät — er steckt als Zubehör im Schloss und kommt über dessen eigene Integration.

Ich hatte das Zigbee-Anlernfenster schon offen, bevor der Hinweis kam. Ein Neuladen der vorhandenen Integration genügte, und die Entität war da.

Bevor man ein Gerät anlernt, lohnt die Frage, ob es nicht längst da ist.

Zwei Kleinigkeiten, bevor es losging

Der Name. Home Assistant setzte den Bereich als Präfix davor, aus dem Kontakt wurde ein Name mit Flur und Gang darin. Nachgezogen auf etwas Lesbares — denn bei einem Türkontakt bedeutet „an“ offen, und der Name muss sich richtig herum lesen, sonst baut man die Bedingung verkehrt.

Die Messung vor dem Vertrauen. Ein Kontakt, der auf „offen“ klemmt, würde das Absperren dauerhaft und lautlos verhindern. Deshalb wurde er vor dem Einbau in die Logik bewegt:

15:17:32  zu
15:21:32  offen
15:22:02  zu        — 30 Sekunden offen

Beide Zustände belegt, nicht angenommen.

Nebenbefund: Beide Wechsel liegen auf :32 und :02. Das Schloss wird etwa alle 30 Sekunden abgefragt — der Messwert kann also eine halbe Minute alt sein. Für eine Verzögerung von drei Minuten belanglos, aber es gehört gewusst.

Was der Kontakt bewirkt

Taster lang → 3 min → Tür zu?   ja       → absperren
                      Tür offen → bis zu 10 min warten
                                  dann zu?  ja   → absperren
                                            nein → WARNUNG, nicht absperren

Die zehn Minuten sind kein Luxus: Wer beim Hinausgehen noch Taschen holt, hält die Tür länger als drei Minuten auf. Das ist der Normalfall, kein Fehler — also warten statt abbrechen.

Bleibt sie nach zehn Minuten offen, fährt der Riegel nicht aus. Er würde ins Leere fahren und beim Zuziehen gegen den Rahmen schlagen.

Der Probelauf — und der Fehler darin

15:39:05  Taster lang
15:39:12  abwesend
15:39:34  Tür offen, Heizung Bad → 12 °C
15:42:11  Türautomatik ausgelöst — und hat NICHT zugesperrt   ← der Prüfpunkt
15:42:14  Wasser zu
15:46:33  Tür zu
15:46:42  sperrt
15:47:20  gesperrt
15:47:36  Taster kurz → anwesend, Wasser auf, Heizung 21 °C

Die Sperre hat gehalten, die Logik stimmte. Von außen sah alles richtig aus.

Im Protokoll stand trotzdem ein Fehler — und der Grund ist eine Zahl:

Das Schloss braucht 38 Sekunden und steht die ganze Zeit auf „sperrt“. Meine erste Fassung wartete stur 20 Sekunden, fand „sperrt“ statt „gesperrt“, hielt das für einen verschluckten Befehl und schickte einen zweiten — mitten in die laufende Fahrt.

Das Schloss wies ihn zurück. Home Assistant wertete die Zurückweisung als Fehler, und die Automatisierung brach ab.

Die Tür ging zu. Die Bestätigung kam nie.

Das ist derselbe stille Ausfall, gegen den dieses ganze Paket gebaut ist — diesmal in meinem eigenen Code. Gefunden habe ich ihn nur, weil ich nach dem Probelauf ins Protokoll gesehen habe.

Zweimal an einem Tag, zwei Geräte

Der eigentliche Befund ist nicht der Fehler, sondern das Muster:

Gerät	geprüft nach	Motor braucht	Folge
Wasserventil	15 s	40 s	der Rückfall sprang immer an
Türschloss	20 s	38 s	der zweite Anlauf riss die Meldung mit

Beide Zahlen waren geraten. Beide waren plausibel. Beide waren zu kurz.

Eine geratene Wartezeit ist keine Prüfung. Sie ist eine Behauptung darüber, wie lange ein Motor braucht — und die trifft genau einmal zu, nämlich bei dem Gerät, an dem man sie geraten hat.

Richtig ist, auf das Ergebnis zu warten, nicht auf die Uhr:

- action: lock.lock
  target: { entity_id: lock.<tür> }
  continue_on_error: true
- wait_for_trigger:
    - trigger: state
      entity_id: lock.<tür>
      to: "locked"
  timeout: "00:01:30"
  continue_on_timeout: true

Drei Dinge daran sind Absicht:

Das Warten auf den Zustand statt einer festen Pause. Es ist fertig, wenn das Gerät fertig ist, nicht wenn die Uhr abgelaufen ist.

Das Zeitlimit mit „weiter bei Zeitüberschreitung“. Bleibt die Bestätigung aus, soll die Meldung trotzdem hinausgehen — mit dem Hinweis, dass sie ausblieb.

Und „weiter bei Fehler“ am Schaltbefehl selbst, damit ein zurückgewiesener Befehl nie wieder die Meldung verschluckt.

Ein Fehler beim Schalten darf alles Mögliche. Nur nicht dafür sorgen, dass niemand davon erfährt.

Was ich dir rate

1. Frag, ob das Gerät nicht schon da ist, bevor du ein Anlernfenster öffnest. Zubehör kommt oft über die Integration des Hauptgeräts.
2. Bewege einen Kontakt, bevor du ihm glaubst. Ein Sensor, der auf einem Zustand klemmt, blockiert lautlos alles, was von ihm abhängt.
3. Miss, wie lange dein Gerät wirklich braucht — und nimm dann nicht diese Zahl, sondern warte auf das Ergebnis.
4. Setz ein Zeitlimit und lass die Meldung trotzdem hinaus. „Keine Bestätigung“ ist eine Information, kein Grund zu schweigen.
5. Lass einen zurückgewiesenen Befehl die Automatisierung nicht abbrechen.
6. Lies das Protokoll nach einem Probelauf, auch wenn alles funktioniert hat. Hier war von außen nichts zu sehen.

Und was heißt das?

Die Tür war zu, die Heizung war unten, das Wasser war ab. Alles, was dieses Paket tun soll, hat es getan.

Und trotzdem war es kaputt — an der einen Stelle, die man von außen nicht sieht: Es hätte mir nicht mehr sagen können, dass es getan hat, was es tun soll. Beim nächsten Mal, wenn die Tür wirklich nicht zugeht, wäre das Schweigen identisch gewesen.

Zwei geratene Zahlen an einem Tag, beide zu kurz, beide plausibel. Das ist kein Zufall, sondern eine Eigenschaft von geratenen Zahlen: Man rät sie nach dem, was man sich vorstellt — und ein Motor, der 38 Sekunden fährt, kommt in keiner Vorstellung vor.