Batteriestandsmeldungen bei Bluetooth Komponenten fehlerhaft

Das "BTHome"-System von Shelly beruht ja auf BLE (Bluetooth Low Energy).
Wenn man sich das BTHome etwas auf der Homepage durchließt und auch (wie ich) in Home Assistant/ioBroker/... beobachtet realisiert man: BTHome "streamt" offensichtlich seine Daten einfach so raus ohne zu überprüfen ob IRGENDWER die Daten auch wirklich empfängt (im Gegensatz zu WLAN/LAN/Bluetooth/...
D.h.: wenn du einen Türsensor hast, der schön fleißig "Tür wurde gerade geöffnet" als 1-maliges Event meldet => wenn aus irgendeinem Grund diese Meldung untergeht, dann kommt das nie bei der Steuerung an. Erst nach 1-24h (je nach Implementierung) wird das mit dem nächsten zyklischen Frame mitgeschickt.

Das Ganze kannst du mit der "packet ID" schön mitschauen:
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Im roten Kästchen empfing mein Home Assistant länger gar kein Packet von meinem Shelly BLU Distance, aber auch überall anders wo du hier "eine kleine Stufe" siehst ist mindestens 1 Packet ausgefallen, da wenn JEDES Packet empfangen wird das Inkrement "+1" in diesem Graphen fast nicht erkennt.

Darüber hinaus werden BTHome-Geräte zumindest bei mir im HA NICHT als "offline" angezeigt auch wenn schon tagelang keine Frames mehr empfangen wurden - es scheint hier kein "timeout" zu geben. Somit glauben die Automatisierungen weiterhin dass die "Tür geschossen" ist, obwohl sie u.u. bereits geöffnet wurde....

Schlussfolgerung:
BTHome (über BLE) ist im Gegensatz zu "reinem Bluetooth" einfach ein "nicht bestätigter Dienst" - und somit für eventgetriggerte Events, die nur 1x geschickt werden, meiner Meinung nach unbrauchbar.

BLE selber ist i.W. connectionless und ohne Device pairing. Die Hauptidee ist somit: Data broadcast - mit allen Nachteilen, aber dafür eben sehr geringer Stromverbrauch (vor allem weil null Handshake benötigt wird).

BTHome ist lediglich ein higher-level Protokoll oberhalb von BLE.

https://www.mokosmart.com/bluetooth-vs-b…led-comparison/

bp4willi

Auch ich habe auf meinem Wall Display gelegentlich (selten) eine Mitteilung über niedrigen Batteriestand (bspw. 40%). Zugleich läuft auf einem anderen Shelly ein Skript mit Webseitengenerierung, über das ich diese Daten mit Uhrzeit (bei eingetroffener BTHome Nachricht) sehr aktuell sehen kann. Während das WD diese Falschmeldung nicht wiederholend anzeigt, zeigen die Daten mit Uhrzeit keine solche Merkwürdigkeit.

Wenn auf dem WD kein Softwarefehler vorliegen sollte, dann wird offenbar unterschiedlich empfangen.

Das WD meldet Batteriestand von 40%, meine skriptgenerierte Webseite 88% mit sehr aktueller Zeit. Ich vertraue dabei mehr über die skriptgenerierte Webseite, welche (testweise) bis zu 15 BTHome Werte anzeigt. Dabei hat mich überrascht, dass auch Nachrichten von Shelly BLU Geräten recht verlässlich empfangen werden, die ca. 15m entfernt liegen und 3 Altbauwände sowie eine Wohnmobil Außenwand dazwischen liegen.

Somit tippe ich in meinem Fall auf einen gelegentlich (selten) auftretenden Fehler im Wall Display. Der betreffende BLU H&T Sensor liegt nur 4m (zum WD) bzw. 8m (Pille) ohne Zwischenwand entfernt.

Wie gesagt: bei H&T-Geräten sind mir "gelegentliche verpasste Packete" ja egal (solange IRGENDWIE ein "Totalausfall" in endlicher Zeit erkannt wird, was scheinbar bei Shelly nicht per Default der Fall ist), aber bei eventgetriggerten Nachrichten sollte es dann schon ein "bestätigter Dienst" sein:
- Shelly BLU Motion: Bewegungserkennung
- Shelly BLU Button Tough 1: Tastendruck
- Shelly BLU Door/Window: Öffnungserkennung
- Shelly BLU Distance: Vibrationssensor
- u.u. Shelly BLU TRV: ???- dort gibt es ja anscheinend gröbere Probleme
- uvm.

=> also quasi bei fast alle BLU-Geräte

Ich weiß nicht ob da Zigbee besser geeignet ist, hab mich damit hoch nicht beschäftigt, aber man kann nur hoffen.
Und MIR kommt subjektiv vor dass Shelly nun Zigbee-Geräte DEUTLICH mehr in den Markt treibt, u.u. schwenken sie ja gerade von BT auf ZB um?