Warum meine Türklingel nachts von selbst klingelte

Zwei Alarme um 01:41, der ganze Haushalt wach, und vor der Tür stand niemand. Die Ursache steckt in der Art, wie Home Assistant BLE-Events verarbeitet.

Das Symptom

In einer Nacht Ende August feuerte meine Türklingel-Automation zweimal: 01:41:56 und 01:42:15. Push-Benachrichtigungen mit maximalem Alarm-Ton, Alexa-Durchsagen in drei Räumen. Alle wach. Türsensor-Log: nichts. Der Cloud-Weg der Klingel: stumm. Es hat niemand geklingelt.

Die Ursache: das Phantom-ring

Die Klingel ist ein SwitchBot Keypad Vision, per Bluetooth Low Energy über einen ESP32-Proxy an Home Assistant angebunden. HA sieht den Tastendruck als event-Entität (event.keypad_vision_1681_turklingel), Zustandswert ring.

Der entscheidende Punkt: Wenn die Keypad nach einem BLE-Aussetzer wieder verbindet, also von unavailable zurück auf einen Wert wechselt, erzeugt sie dabei ein ring-Event. Und HA stempelt Events auf die Empfangszeit, nicht auf die echte Druckzeit. Das Phantom sieht damit aus wie ein Tastendruck, der genau jetzt passiert ist.

In dieser Nacht war die Keypad rund zehn Minuten komplett weg (BLE-Link zusammengebrochen). Beim Reconnect: zwei Phantom-ring, zwei Alarme.

Der Ein-Zeilen-Schutz

Der Reconnect-Fall lässt sich am Trigger abfangen. Statt „reagiere auf jeden Wechsel des Klingel-Events":

triggers:
  - trigger: state
    entity_id: event.keypad_vision_1681_turklingel
    not_from: [unavailable, unknown]
    not_to: [unavailable, unknown]

not_from: [unavailable, unknown] unterdrückt genau die unavailable → ring-Flanke. Ein echter Tastendruck kommt aus einem gültigen vorherigen Zustand, kein unavailable, der wird nicht gefiltert.

Diesen Guard hatte ich zuerst genau dafür eingebaut, dann in einem Anfall von „ich verpasse damit vielleicht ein echtes Klingeln" wieder entfernt, und prompt kam die Nacht mit den zwei Alarmen. Seitdem ist er wieder drin und bleibt drin.

Was der Guard NICHT löst

Es gibt einen zweiten Phantom-Typ: dieselbe Keypad feuert manchmal ein ring aus verbundenem Zustand heraus: from_state ist dann ein gültiger alter Zeitstempel, kein unavailable. not_from greift nicht, eine „Event ist frisch"-Bedingung auch nicht (der Phantom-Zeitstempel ist frisch). Einmal abends beim Abendessen: zwei solche Fehlalarme, danach ein echtes Klingeln verpasst, weil die Keypad in dem Moment gerade unavailable war.

Die unbequeme Wahrheit: Kein Trigger-Filter kann ein Phantom von einem echten Druck unterscheiden, wenn beide einen frischen Zeitstempel tragen. Der einzige echte Fix ist ein stabiler BLE-Link, dann werden die Aussetzer selten und beide Phantom-Typen praktisch verschwinden. Genau das hat bei mir am Ende ein PoE-Bluetooth-Proxy mit externer Antenne direkt an der Tür gebracht: der Empfang der Keypad ging von -63 auf -46 dBm.