ble2mqtt - Bluetooth Anwesenheitserkennung

Begonnen von drhirn, 07 April 2022, 13:45:09

Vorheriges Thema - Nächstes Thema

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
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

drhirn

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

betateilchen

Zitat von: drhirn am 24 März 2024, 10:11:36Super! 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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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!

Zitat von: hkspks am 23 Juli 2024, 09:04:021) 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.

Zitat von: hkspks am 23 Juli 2024, 09:04:023) 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
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

hkspks

#202
Zitat von: PatrickR am 23 Juli 2024, 11:55:10Ist 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:

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!
Zitat von: hkspks am 23 Juli 2024, 13:38:29Hilft 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.

Zitat von: hkspks am 23 Juli 2024, 13:38:29Update 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
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

hkspks

Hey Patrick,

Zitat von: PatrickR am 23 Juli 2024, 14:10:59Ich 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.

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.

Zitat von: PatrickR am 23 Juli 2024, 14:10:59Nach 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:
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

--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
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

hkspks

Zitat von: PatrickR am 23 Juli 2024, 14:34:35--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!