ble2mqtt - Bluetooth Anwesenheitserkennung

[drhirn]

Ja, hab ich auch schon mal vorgeschlagen. Die Antwort von PatrickR war: https://forum.fhem.de/index.php?msg=1286119

Ich kann aber in der Zwischenzeit mal einen Hinweis im Wiki unterbringen.

[Ellert]

Ein Hinweis im Wiki kann schnell veraltet sein, wenn es eine neue Version in einem anderen Beitrag gibt. Da wäre ein festes Verzeichnis in contrib schöner.
Vielleicht contrib/BluetoothLowEnergy mit einer readme.txt, die auf den Thread und das Wiki verweist.

Oder in das in dem verlinkten Beitrag erwähnte GitHub/Lab, falls es existiert.

[PatrickR]

@DrHirn, Ellert:
Ihr habt ja alle Recht

Habe ble2mqttd 0.15 jetzt direkt unter contrib eingescheckt, da ich aktuell nicht mehr als eine Datei benötige. Debian-Pakete werden daran scheitern, dass es einzelne Perl-Module nicht als Debian-Pakete und damit als potenzielle Dependencys gibt.

Patrick

[drhirn]

Super! Hab die Wiki-Seite dementsprechend geändert.

[betateilchen]

Super! Hab die Wiki-Seite dementsprechend geändert.

Kurzer Hinweis:

Die im Wiki Artikel genannten Pakete CPAN::DistnameInfo und Net::MQTT::Simple gibt es auch als Debian Pakete.
Das erstgenannte kann (zumindest bei bookworm) einfach über
apt install libcpan-distnameinfo-perl

installiert werden, das zweite Paket kann man von hier laden:
http://ftp.de.debian.org/debian/pool/main/libn/libnet-mqtt-simple-perl/libnet-mqtt-simple-perl_1.29-2_all.deb

und anschließend beispielsweise mit apt install ./libnet-mqtt-simple-perl_1.29-2_all.deb installieren.

[hkspks]

Hallo zusammen,

ich laufe unregelmäßig/ im Schnitt so alle 2-4 Wochen in das Problem, dass meine beiden G-Tags als abwesend (also kein Update von last-seen-reading bzw. present = 0) angezeigt werden, obwohl diese anwesend sind. Bei mir laufen ein Pi3b und ein pi zero w. Drei Symptome:

1) Der Tag wird nur von einem Pi erkannt. Hier hilft ein Restart des ble2mqtt service auf dem Pi, der gerade nichts findet. Der Service scheint auf dem Pi aber grundsätzlich zu funktionieren, weil der Pi zumindest den anderen Tag erkennt.
2) Ein Tag wird auf beiden Geräten nicht erkannt, der andere schon. Hier hilft es den Tag kurz "abzuschirmen" und dann wieder sichtbar zu machen (also sozusagen, kurz außer Haus gehen und zurückzukommen).
3) Wenn ich auf dem Handy die G-Tag App starte, um die Schlüssel zu orten, werden diese nicht mehr von den Pis erkannt, bis ich die App wieder abschieße. Scheint, die Tags können nur "eine aktive Verbindung". Nutze die App aber nur 1x im Jahr, sonst ist sie deaktiviert, d.h. schließe Abhängigkeiten zu 2/3 aus.

Kennt jemand diese Symptome und kann diese technisch erklären sodass ich mir eine Lösung überlegen kann?

[PatrickR]

Hi!

1) Der Tag wird nur von einem Pi erkannt. Hier hilft ein Restart des ble2mqtt service auf dem Pi, der gerade nichts findet. Der Service scheint auf dem Pi aber grundsätzlich zu funktionieren, weil der Pi zumindest den anderen Tag erkennt.
2) Ein Tag wird auf beiden Geräten nicht erkannt, der andere schon. Hier hilft es den Tag kurz "abzuschirmen" und dann wieder sichtbar zu machen (also sozusagen, kurz außer Haus gehen und zurückzukommen).

Ist mir beides noch nicht untergekommen. Zumindest bei 1.) kann es nicht am Tag selbst liegen, da der Neustart von ble2mqttd hilft. Stelle doch mal bitte den Logmodus auf DEBUG (Achtung: Die SD-Karte leidet) und lade das Log hier hoch, vielleicht ab 15 Minuten bevor das Problem auftritt und 5 Minuten danach.

3) Wenn ich auf dem Handy die G-Tag App starte, um die Schlüssel zu orten, werden diese nicht mehr von den Pis erkannt, bis ich die App wieder abschieße. Scheint, die Tags können nur "eine aktive Verbindung". Nutze die App aber nur 1x im Jahr, sonst ist sie deaktiviert, d.h. schließe Abhängigkeiten zu 2/3 aus.

Das Problem hatte ich leider auch. Ich hatte sogar G-Tags, die vollständig verstummt sind ab dem Zeitpunkt, an dem ich sie mit der App gekoppelt habe. Habe die Tags dann exklusiv für FHEM genutzt und auf die App verzichtet.

Patrick

[hkspks]

Ist mir beides noch nicht untergekommen. Zumindest bei 1.) kann es nicht am Tag selbst liegen, da der Neustart von ble2mqttd hilft. Stelle doch mal bitte den Logmodus auf DEBUG (Achtung: Die SD-Karte leidet) und lade das Log hier hoch, vielleicht ab 15 Minuten bevor das Problem auftritt und 5 Minuten danach.

Also gestern Abend war folgende Konstellation:

	-- GTag A --	-- GTag B --
Pi 1	Abwesend	Abwesend
Pi 2	Abwesend	Anwesend

Hatte gerade mal noch im journalctl geschaut und folgenden Eintrag bei Pi 1 gefunden:

Code Auswählen Erweitern

Jul 22 21:46:09 raspberrypi ble2mqttd[25350]: main::cleanup_task: Cleanup finished, deleted 0 devices in 0 seconds.
Jul 22 22:01:10 raspberrypi ble2mqttd[25350]: main::cleanup_task: Cleanup finished, deleted 0 devices in 0 seconds.
Jul 22 22:04:37 raspberrypi ble2mqttd[25350]: main::battery_task: Executing battery task.
Jul 22 22:04:42 raspberrypi ble2mqttd[25350]: main::battery_task: Battery level of device 7C:2F:XX:XX:04:D9 is 100, updating reading...
Jul 22 22:04:49 raspberrypi ble2mqttd[25350]: main::battery_task: Battery level of device 7C:2F:XX:XX:A2:12 is unknown, skipping reading update...
Jul 22 22:04:49 raspberrypi kernel: Bluetooth: hci0: Opcode 0x200d failed: -110
Jul 22 22:04:49 raspberrypi kernel: Bluetooth: hci0: request failed to create LE connection: err -110
Jul 22 22:04:49 raspberrypi ble2mqttd[25350]: main: Scan started.
Jul 22 22:04:49 raspberrypi ble2mqttd[25350]: main::__ANON__: Found bluetoothctl version 5.55.
Jul 22 22:14:38 raspberrypi ble2mqttd[25350]: main::evaluation_task: Device 7C:2F:XX:XX:04:D9 is now absent.
Jul 22 22:15:02 raspberrypi ble2mqttd[25350]: main::evaluation_task: Device 7C:2F:XX:XX:A2:12 is now absent.
Jul 22 22:23:07 raspberrypi ble2mqttd[25350]: main::__ANON__: Caught signal, cleaning up and exiting...
Jul 22 22:23:07 raspberrypi systemd[1]: Stopping ble2mqttd...
Jul 22 22:23:07 raspberrypi systemd[1]: ble2mqttd.service: Main process exited, code=exited, status=1/FAILURE
Jul 22 22:23:07 raspberrypi systemd[1]: ble2mqttd.service: Failed with result 'exit-code'.
Jul 22 22:23:07 raspberrypi systemd[1]: Stopped ble2mqttd.
Jul 22 22:23:07 raspberrypi systemd[1]: ble2mqttd.service: Consumed 2h 17min 4.792s CPU time.
Jul 22 22:23:07 raspberrypi systemd[1]: Starting ble2mqttd...
Jul 22 22:23:17 raspberrypi systemd[1]: Started ble2mqttd.
Jul 22 22:23:20 raspberrypi ble2mqttd[28452]: main: Version 0.15 started (device: hci0, mqtt server: 192.168.178.XX:1883, mqtt user: -none-, mqtt fingerprint: -none-, get mqtt fingerprint: 0, mqtt topic: ble2mqtt/XXX, daemon>
Jul 22 22:23:20 raspberrypi ble2mqttd[28452]: main::sanity_check: md5 digest of '/usr/local/bin/ble2mqttd' is: 'XXX'.
Jul 22 22:23:20 raspberrypi ble2mqttd[28452]: main::sanity_check: bluetoothctl found at '/usr/bin/bluetoothctl'.
Jul 22 22:23:20 raspberrypi ble2mqttd[28452]: main::sanity_check: gatttool found at '/usr/bin/gatttool'.
Jul 22 22:23:20 raspberrypi ble2mqttd[28452]: main::mqtt_check_reconnect: (Re-)connect detected, handling...
Jul 22 22:23:20 raspberrypi ble2mqttd[28452]: main: Scan started.
Jul 22 22:23:20 raspberrypi ble2mqttd[28452]: main::__ANON__: Found bluetoothctl version 5.55.
Jul 22 22:25:20 raspberrypi ble2mqttd[28452]: main::battery_task: Executing battery task.
Jul 22 22:25:20 raspberrypi ble2mqttd[28452]: main: Scan started.
Jul 22 22:25:20 raspberrypi ble2mqttd[28452]: main::__ANON__: Found bluetoothctl version 5.55.

Hilft das? Scheint, er hatte ein Problem mit dem Batterie-Check, ist dann abgeraucht und nicht mehr richtig gestartet. Um 22:23 hab ich den Service neu gestartet über systemctl. Könnte den Batteriecheck mal ausschalten. Was denkst Du?

Bei dem "der Tag muss mal offline sein um Wiedererkannt zu werden" oder bei dem App-Thema glaube ich, dass das Thema an externen Effekten liegt. Vielleicht scannt auch noch ein Service (Mehrfamilienhaus). Es scheint wirklich, dass der Tag gleichzeitig nur mit einem Service sprechen kann.

Update 13:57: nach Studium des Journals: ble2mqttd macht jedes Stunde eine Abfrage des Batteriestatus. 1/5 mal kommt danach der Bluetooth-Kernelfehler.

[PatrickR]

Hi!

Hilft das? Scheint, er hatte ein Problem mit dem Batterie-Check, ist dann abgeraucht und nicht mehr richtig gestartet. Um 22:23 hab ich den Service neu gestartet über systemctl. Könnte den Batteriecheck mal ausschalten. Was denkst Du?

Ich denke, ein längeres Log mit LOG_DEBUG würde helfen. Das hier ist leider kurz, scheinbar mit LOG_INFO und dann auch noch oben, unten und rechts abgeschnitten. Warum hast Du das md5 digest des Skripts getilgt? Hast Du ble2mqttd gepatcht? Was ist denn konkret abgeraucht? Der Prozess scheint nur durch Deinen Neustart beendet zu werden.

Update 13:57: nach Studium des Journals: ble2mqttd macht jedes Stunde eine Abfrage des Batteriestatus. 1/5 mal kommt danach der Bluetooth-Kernelfehler.

Nach meinem Verständnis kann das schonmal passieren. Ich versuche das zu umschiffen, indem ich nur bei erreichbaren Tags die Batterie abfrage. Tritt die Kernelmeldung immer dann auf, wenn die Erkennung auch kaputt ist?

Patrick

[hkspks]

Hey Patrick,

Ich denke, ein längeres Log mit LOG_DEBUG würde helfen. Das hier ist leider kurz, scheinbar mit LOG_INFO und dann auch noch oben, unten und rechts abgeschnitten. Warum hast Du das md5 digest des Skripts getilgt? Hast Du ble2mqttd gepatcht? Was ist denn konkret abgeraucht? Der Prozess scheint nur durch Deinen Neustart beendet zu werden.

ne, hab nichts gepatched - keine Ahnung, warum ich das gegraut habe Mit "abgeraucht" meine ich, dass der Service danach die Tags nicht mehr findet (obwohl das Skript läuft), bis ich das Skript neu starte.

Code Auswählen Erweitern

raspberrypi ble2mqttd[32341]: main::sanity_check: md5 digest of '/usr/local/bin/ble2mqttd' is: '184e277135055f86fb50b4d0c0771aa9'.
Wollte ein LOG_DEBUG über die kommenden 2-4 Wochen (so oft dauert es normalerweise, bis ein Tag nicht mehr als anwesend angezeigt wird) meiden, weil ich meine SD-Karte nicht unnötig belasten wollte. Ich hab jetzt mal den Batterie-Check ausgestellt und schau mal, ob dies das Problem bereits behebt. Falls nein, mach ich LOG_DEBUG an.

Nach meinem Verständnis kann das schonmal passieren. Ich versuche das zu umschiffen, indem ich nur bei erreichbaren Tags die Batterie abfrage. Tritt die Kernelmeldung immer dann auf, wenn die Erkennung auch kaputt ist?

Es gibt ganz verschiedene Konstellationen - scheint vom Ergebnis aber unabhängig zu sein:

Code Auswählen Erweitern

Jul 22 18:03:59 raspberrypi ble2mqttd[25350]: main::battery_task: Battery level of device 7C:XX:D9 is 100, updating reading...
Jul 22 18:04:04 raspberrypi kernel: Bluetooth: hci0: Opcode 0x200d failed: -110
Jul 22 18:04:04 raspberrypi kernel: Bluetooth: hci0: request failed to create LE connection: err -110
Jul 22 18:04:04 raspberrypi ble2mqttd[25350]: main::battery_task: Battery level of device 7C:XX:12 is 100, updating reading...
Jul 22 19:04:08 raspberrypi ble2mqttd[25350]: main::battery_task: Battery level of device 7C:XX:D9 is 100, updating reading...
Jul 22 19:04:13 raspberrypi ble2mqttd[25350]: main::battery_task: Battery level of device 7C:XX:12 is unknown, skipping reading update...
Jul 22 19:04:13 raspberrypi kernel: Bluetooth: hci0: Opcode 0x200d failed: -110
Jul 22 19:04:13 raspberrypi kernel: Bluetooth: hci0: request failed to create LE connection: err -110
Jul 22 19:04:13 raspberrypi ble2mqttd[25350]: main: Scan started.
Jul 22 19:04:13 raspberrypi kernel: Bluetooth: hci0: Opcode 0x2005 failed: -16
Jul 22 20:04:13 raspberrypi ble2mqttd[25350]: main::battery_task: Executing battery task.
Jul 22 20:04:17 raspberrypi ble2mqttd[25350]: main::battery_task: Battery level of device 7C:XX:D9 is unknown, skipping reading update...
Jul 22 20:04:23 raspberrypi ble2mqttd[25350]: main::battery_task: Battery level of device 7C:XX:12 is 100, updating reading...
Jul 22 20:04:23 raspberrypi ble2mqttd[25350]: main: Scan started.
Jul 22 20:04:23 raspberrypi ble2mqttd[25350]: main::__ANON__: Found bluetoothctl version 5.55.

Ich glaube man kann sagen, wenn der Bluetooth-Kernerfehler auftritt, dann beim Batterie-Check. Er ist aber unabhängig vom Erfolg des Checks. In Ausnahmefällen, werden danach die Tags nicht mehr gefunden (alle 2-4 Wochen).

[PatrickR]

Hi!

Da die strukturierte Fehleranalyse zurückgestellt ist kannst Du Dir auch nochmal

Code Auswählen Erweitern

--watchdogthreshold
ansehen. Das startet den Scan neu, wenn über den eingestellten Zeitraum überhaupt nichts empfangen wurde. In Deinem Mehrfamilienhausszenario könnte das gut funktionieren, weil dort immer etwas funkt.

Sehe aber gerade, dass das aktuell nur funktioniert, wenn macregex nicht gesetzt ist.

Patrick

[hkspks]

Code Auswählen Erweitern

--watchdogthreshold
ansehen. Das startet den Scan neu, wenn über den eingestellten Zeitraum überhaupt nichts empfangen wurde. In Deinem Mehrfamilienhausszenario könnte das gut funktionieren, weil dort immer etwas funkt.

Sehe aber gerade, dass das aktuell nur funktioniert, wenn macregex nicht gesetzt ist.

Cool, kann den macregex ja einfach mal rausnehmen und die Option rein. Danke!

[PatrickR]

Hi!

Habe im SVN mal eine neue Version eingescheckt. Der Watchdog sollte jetzt auch mit macregex funktionieren.

Patrick

[volschin]

Super! Hab die Wiki-Seite dementsprechend geändert.

Kurzer Hinweis:

Die im Wiki Artikel genannten Pakete CPAN::DistnameInfo und Net::MQTT::Simple gibt es auch als Debian Pakete.
Das erstgenannte kann (zumindest bei bookworm) einfach über
apt install libcpan-distnameinfo-perl

installiert werden, das zweite Paket kann man von hier laden:
http://ftp.de.debian.org/debian/pool/main/libn/libnet-mqtt-simple-perl/libnet-mqtt-simple-perl_1.29-2_all.deb

und anschließend beispielsweise mit apt install ./libnet-mqtt-simple-perl_1.29-2_all.deb installieren.

Unter dem aktuellen Ubuntu 24.04 lässt sich das zweite auch ganz normal über apt installieren.

[hkspks]

Ich glaube man kann sagen, wenn der Bluetooth-Kernerfehler auftritt, dann beim Batterie-Check. Er ist aber unabhängig vom Erfolg des Checks. In Ausnahmefällen, werden danach die Tags nicht mehr gefunden (alle 2-4 Wochen).

Kurzes Update nach knapp 2 Monaten "Produktionsbetrieb": Keine Fehler/ Ausfälle mehr seitdem ich den Batterie-Check deaktiviert habe. Es scheint also damit im Zusammenhang zu stehen. Für mich wäre das so fein, es sei denn jemand möchte hier noch Fehleranalyse betreiben. Dann biete ich mich da natürlich gerne an Infos beizusteuern. Es scheint aber, ich wäre ein Einzelschicksal und bleibe das auch gerne! Bleibt ein cooles Skript!