Auweia, ein weiteres "Opfer" der BLU-Geräte 
:
Shelly BLU-Geräte schicken ihre Daten als "broadcast" weg und IRGENDEIN Shelly (bei mir einer der 6 Shelly Plus 2PM) empfängt das und sendet es an den Empfänger weiter (bei mir Home Assistant => Node RED)
Das Shelly BLU-Gerät bekommt dabei KEINERLEI Informationen über überhaupt IRGENDWER die Daten empfangen hat => es gibt keine "Empfangsbestätigung". Somit kann es bei schlechten Empfang vorkommen dass mehrere Packete von gar keinem empfangen werden.
Darüber hinaus werden durch Node RED nicht DIREKT die Daten von dem Shelly BLU-Gerät ausgelesen sondern nur von dem "Gateway".
d.h.: Wenn ein z.b.: Shelly BLU Door/Window einen Batteriestatus "80%" sendet und danach spontan stirbt und/oder der Empfang zu schlecht ist, dann wird dieser Status NIEMALS aktualisiert. Der Consumer (=> Node RED) glaubt dann auf Dauer dass der Shelly BLU Door/Window noch immer 80% Batteriestand hat.
Meine Lösung war:
Ich beobachte pro Shelly BLU-Gerät die ÄNDERUNG der "Packet ID" um ein jeweiliges Timout zu resettieren. Wenn dieses Timeout "ausläuft" weiß ich dass das Shelly BLU-Gerät nicht mehr aktiv ist und gehe in meiner Automatisierung in einen "sicheren Zustand".
Problem dabei:
Ein z.b.: Shelly BLU Door/Window sendet per default nur alle 7h ein "I am alive"-Signal, manche Geräte sogar noch seltener => d.h.: du weißt für die nächsten 7h also nicht ob das Fenster/die Tür nicht zwischenzeitlich doch aufgemacht wurde und der Frame einfach "verpasst" wurde oder der Sensor einfach ausgefallen ist.
Wenn das in deiner Applikation ein Problem ist musst du den "Beacon mode" aktivieren, dann wird relativ oft ein Frame geschickt und die "blinde Zeit" kann auf Kosten der Batterie deutlich reduziert werden.
der BLU-Geräte
Der Door/Window 2 ist WLAN basiert, das ist kein BLU Gerät
auweia, der ganze rant dann umsonst 🙃 - wer genauer ließt weiß mehr.
Aber ich habe hier auch noch einen Shelly Door/Window 2 herumliegen den ich VORHER verbaut gehabt habe - da habe ich im Wesentlichen das Gleiche gemacht. Da es aber keine "Packet ID" gab (soweit ich noch weiß), habe ich einfach ALLE Datenpakete des Devices zum Resettieren des Timeouts herangezogen und so evaluiert ob das Gerät "noch lebt".
