ble2mqtt - Bluetooth Anwesenheitserkennung

[PatrickR]

Hi!

Code Auswählen Erweitern

$ perl ble2mqttd --mqttserver localhost:1883 --mqtttopic ble2mqtt/entrance --debug 5
main::sanity_check: ERROR: gatttool not found!


War es nicht das Ziel, gatttool überflüssig zu machen? Läuft das Script auch ohne?

Gatttool wird aktuell verwendet, um den Batteriestatus abzufragen. Hatte mal probiert, es mit bluetoothctl zu lösen, habe es aber auf die Schnelle nicht hinbekommen.

Ich sehe zwei Möglichkeiten:

• Ersetzen von gatttool durch ein anderes Tool, das den Batteriestatus über gatt abfragen kann.
• Hinzufügen eines neuen Kommandozeilenparameters, der den Batteriecheck abschaltet.

Schöner wäre natürlich 1. Wenn Du eine Idee hast oder einen Beispielcode, gerne her damit. Dann schaue ich es mir an und baue es ein. Es müsste aber ziemlich flexibel funktionieren, u. a. auch mit Raspbian.

Patrick

[decaflo]

Ok, danke für die Infos! Ich schaue mir das an, komme aber voraussichtlich erst über die Feiertage dazu. Viele Grüße!

[FHEM_Starter]

Hallo Patrick,

ich habe die Version mit der Battery Abfrage installiert. Aktuell werden jedoch keine Battery Readings angelegt, auch im mqtt Explorer (ich arbeite auf einem Mac) werden keine Topics angezeigt.
Dafür kommen in zwei Zeilen Fehlermeldungen:
Use of uninitialized value $current_mac in hash element at ./ble2mqttd line 488.
Use of uninitialized value $current_mac in hash element at ./ble2mqttd line 483.

Ich versuche meine Siemens GTags zu erkennen.

Danke und Gruß
Wolfgang

[PatrickR]

Hallo Wolfgang!

ich habe die Version mit der Battery Abfrage installiert. Aktuell werden jedoch keine Battery Readings angelegt, auch im mqtt Explorer (ich arbeite auf einem Mac) werden keine Topics angezeigt.
Dafür kommen in zwei Zeilen Fehlermeldungen:
Use of uninitialized value $current_mac in hash element at ./ble2mqttd line 488.
Use of uninitialized value $current_mac in hash element at ./ble2mqttd line 483.

Kannst Du mal ein Debug-Log erstellen und posten/mir per PN schicken? Dann schaue ich es mir mal an.

MQTT Explorer ist auf jeden Fall schonmal ein ausgesprochen schönes Debuggingwerkzeug.

Patrick

[FHEM_Starter]

erledigt, PM ist raus.

Wolfgang

[decaflo]

Die Abfrage des Akkuladezustandes mit bluetoothctl funktioniert über die Befehlsfolge

connect
menu gatt
select-attribute
read
disconnect

Code Auswählen Erweitern


# connect 58:9E:C6:10:51:26
Attempting to connect to 58:9E:C6:10:51:26
[CHG] Device 58:9E:C6:10:51:26 Connected: yes
Connection successful
...
[Gigaset G-tag]# menu gatt
...
[Gigaset G-tag]# select-attribute 00002a19-0000-1000-8000-00805f9b34fb
[Gigaset G-tag:/service0019/char001a]# read
Attempting to read /org/bluez/hci0/dev_58_9E_C6_10_51_26/service0019/char001a
[CHG] Attribute /org/bluez/hci0/dev_58_9E_C6_10_51_26/service0019/char001a Value:
  55                                               U               
  55                                               U               


wobei "55" dasselbe ist, was ich mit gatttool erhalte:

Code Auswählen Erweitern


~# gatttool -b 58:9E:C6:10:51:26 -t public --char-read --uuid=00002a19-0000-1000-8000-00805f9b34fb
handle: 0x001b value: 55


Ich hatte Probleme, das in den Code reinzufummeln, weil ich dem Expect Modul nicht beibringen konnte, mit dem mehrzeiligen Output umzugehen. Liegt aber wohl an mir 

[decaflo]

Da ich im Erdgeschoss in der Innenstadt wohne und seit der Corona-Warn-App alle Handys Bluetooth eingeschaltet haben, landen bei mir sehr viele MAC-Adressen in der readingList des korrespondierenden MQTT_DEVICE. Und damit meine ich mehrere tausend innerhalb weniger Tage. Das führt bei mir zu erheblicher Kommunikation im Netz und dazu, dass wegen der umfangreichen Device-Konfiguration der ganze fhem-Server in die Knie geht. 

Ich habe deswegen in ble2mqttd noch einen MAC-Filter eingebaut, so dass nur bestimmt MACs weitergegeben werden:

Code Auswählen Erweitern


$ ./ble2mqttd
ble2mqttd --mqttserver <mqtt server:mqtt port> --mqttfingerprint <ssl fingerprint> --mqttuser <mqtt user> --mqttpass <mqtt pass> --loglevel <log level> --logtarget <log target> --daemon --mac <regex>
...
--mac <regex> - filter handled MAC Adresses with regular expression.
examples:
...
ble2mqttd --mqttserver mqtt.domain:8883 --mqttfingerprint 'sha256$11e20bbb668da517a0ae8536f3c79887d06ddec945fab60401deab92dc7e7c1f' --mqttuser user --mqttpass pass --mac 'AB:CD:EF:.*'


Vielleicht kann das ja noch jemand gebrauchen.

[PatrickR]

Hi!

erledigt, PM ist raus.

Du setzt scheinbar eine alte oder veränderte Version ein. Ich erstelle heute noch eine neue Version mit decaflos Regex-Patch. Vielleicht probierst Du es mit der nochmal und dann geht es dem Bug (sofern er dann noch auftritt) an den Kragen.

Die Abfrage des Akkuladezustandes mit bluetoothctl funktioniert über die Befehlsfolge

connect
menu gatt
select-attribute
read
disconnect

Schaue ich mir an. Ich erinnere mich dunkel, dass ich das mal probiert hatte und es bei mir (ebenfalls G-Tags) nicht zuverlässig funktioniert hat. Ich teste das auf jeden Fall mal.

Da ich im Erdgeschoss in der Innenstadt wohne und seit der Corona-Warn-App alle Handys Bluetooth eingeschaltet haben, landen bei mir sehr viele MAC-Adressen in der readingList des korrespondierenden MQTT_DEVICE. Und damit meine ich mehrere tausend innerhalb weniger Tage. Das führt bei mir zu erheblicher Kommunikation im Netz und dazu, dass wegen der umfangreichen Device-Konfiguration der ganze fhem-Server in die Knie geht. 

Ich habe mich ja immer gegen den Filter gewehrt, weil die Argumente mich nicht überzeugt haben. Aber Dein Szenario hatte ich dabei definitiv nicht im Kopf. Auch wenn man FHEM-seitig vielleicht noch etwas filtern könnte ist das ja gruselig.

Ich habe deswegen in ble2mqttd noch einen MAC-Filter eingebaut, so dass nur bestimmt MACs weitergegeben werden:

Schöner Patch. Baue ich (ggf. mit minimalen Anpassungen) so ein.

Patrick

[PatrickR]

Version 0.08 mit decaflos MAC-Filter-Patch

/Edit: Datei entfernt. Neue Version siehe unten.

[PatrickR]

Hi!

Die Abfrage des Akkuladezustandes mit bluetoothctl funktioniert über die Befehlsfolge

connect
menu gatt
select-attribute
read
disconnect

Hmpf:

Code Auswählen Erweitern


[bluetooth]# connect 58:9E:C6:10:YY:XX
Attempting to connect to 58:9E:C6:10:YY:XX
Failed to connect: org.bluez.Error.Failed

Jetzt ist natürlich die Frage, was meinen G-Tag von Deinem unterscheidet. Ggf. ist/war meiner mal mit einem Gerät gekoppelt oder so. Für die (unschöne) Gatttool-Variante scheint das aber egal zu sein.

Grüße
Patrick

[FHEM_Starter]

Hallo Patrick,

der Patch mit der mac-adresse klappt, ich sehe "nur" noch die G-Tags mit der korrespondierenden Mac Adresse. Ist das eine komma separierte Liste? Also "AA:BB:CC.*,AA:BB:DD.*"?

Die Battariewerte kommen leider immer noch nicht, ich habe die ein neues Log-File gesendet.

Code Auswählen Erweitern

wolfgang@WSP-NUC:/lib/systemd/system$ sudo systemctl status ble2mqttd
● ble2mqttd.service - ble2mqtt daemon
   Loaded: loaded (/lib/systemd/system/ble2mqttd.service; enabled; vendor preset: enabled)
   Active: active (running) since Fr 2022-12-23 18:05:01 CET; 19min ago
  Process: 30762 ExecStartPre=/bin/sleep 10 (code=exited, status=0/SUCCESS)
Main PID: 31277 (ble2mqttd)
    Tasks: 2
   Memory: 15.0M
      CPU: 4.190s
   CGroup: /system.slice/ble2mqttd.service
           ├─ 4595 bluetoothctl
           └─31277 /usr/bin/perl /home/wolfgang/ble2mqttd --mqttserver 127.0.0.1:1883 --mqttuser myuser --mqttpass mypasswd --mqtttopic ble2mqtt/keller --absentinterval 180 --mac 7C:2F:80.*

Dez 23 18:05:05 WSP-NUC ble2mqttd[31277]: Use of uninitialized value $current_mac in hash element at /home/wolfgang/ble2mqttd line 498.
Dez 23 18:05:07 WSP-NUC ble2mqttd[31277]: Use of uninitialized value $current_mac in hash element at /home/wolfgang/ble2mqttd line 493.
Dez 23 18:05:07 WSP-NUC ble2mqttd[31277]: Use of uninitialized value $current_mac in hash element at /home/wolfgang/ble2mqttd line 498.
Dez 23 18:07:01 WSP-NUC ble2mqttd[31277]: main: Scan started.
Dez 23 18:10:07 WSP-NUC ble2mqttd[31277]: main::evaluation_task: Device 7C:2F:80:AB:FD:0B is now absent.
Dez 23 18:10:25 WSP-NUC ble2mqttd[31277]: main::evaluation_task: Device 7C:2F:80:AB:FC:43 is now absent.
Dez 23 18:14:37 WSP-NUC ble2mqttd[31277]: main::evaluation_task: Device 7C:2F:80:AB:FC:43 is now absent.
Dez 23 18:15:25 WSP-NUC ble2mqttd[31277]: main::evaluation_task: Device 7C:2F:80:AB:FD:10 is now absent.
Dez 23 18:20:02 WSP-NUC ble2mqttd[31277]: Use of uninitialized value in subtraction (-) at /home/wolfgang/ble2mqttd line 311.
Dez 23 18:20:02 WSP-NUC ble2mqttd[31277]: main::cleanup_task: Cleanup finished, deleted 1 devices in 0 seconds.

Danke dass Du hier so viel Zeit und Arbeit investierst.

Frohe Weihnachten,
Wolfgang

[decaflo]

der Patch mit der mac-adresse klappt, ich sehe "nur" noch die G-Tags mit der korrespondierenden Mac Adresse. Ist das eine komma separierte Liste? Also "AA:BB:CC.*,AA:BB:DD.*"?

Hallo Wolfgang,

nein, das ist eine Regular Expression, keine kommaseparierte Liste. D.h. ein solche Liste kannst Du z.B. so angeben:

Code Auswählen Erweitern

--mac "AA:BB:(CC|DD):.*"

oder ganze Adressen so:

Code Auswählen Erweitern

--mac "AA:BB:CC:DD:EE:FF|00:11:22:33:44:55:66"

Schöne Grüße!

[decaflo]

Hi!

Hmpf:

Code Auswählen Erweitern


[bluetooth]# connect 58:9E:C6:10:YY:XX
Attempting to connect to 58:9E:C6:10:YY:XX
Failed to connect: org.bluez.Error.Failed

Jetzt ist natürlich die Frage, was meinen G-Tag von Deinem unterscheidet. Ggf. ist/war meiner mal mit einem Gerät gekoppelt oder so. Für die (unschöne) Gatttool-Variante scheint das aber egal zu sein.

Grüße
Patrick

Hallo Patrick,

komisch. Ich habe etwas rumprobiert und das tritt auf verschiedenen Geräten mit dem selben Tag bei mir auch auf:

• Beim Notebook (Dell XPS13) klappt die Abfrage.
• Beim Raspi Zero W klappt es auch
• beim Raspi 3b+ erhalte ich ebenfalls die Meldung Failed to connect: org.bluez.Error.Failed.
• auf dem cubietruck, auf dem mein fhem unter Archlinux (ohne gatttool) läuft, geht die Abfrage mit bluetoothctl auch

Allerdings geht dasselbe mit gattttool auf dem Raspi 3B+ auch nicht:

Code Auswählen Erweitern


# gatttool -b 58:9E:C6:1A:YY:ZZ -t public --char-read --uuid=00002a19-0000-1000-8000-00805f9b34fb
connect to 58:9E:C6:1A:YY:ZZ: Connection refused (111)


oder manchmal

Code Auswählen Erweitern


# gatttool -b 58:9E:C6:1A:YY:ZZ -t public --char-read --uuid=00002a19-0000-1000-8000-00805f9b34fb
connect to 58:9E:C6:1A:YY:ZZ: Function not implemented (38)



Dort wo die Abfrage mit gatttool klappt, geht sie auch mit bluetoothctl.

Kannst Du das bestätigen oder geht bei Dir auf demselben Gerät die Abfrage mit bluetoothctl nicht, mit gatttool aber schon?

[PatrickR]

Hi!

Kannst Du das bestätigen oder geht bei Dir auf demselben Gerät die Abfrage mit bluetoothctl nicht, mit gatttool aber schon?

Ich fürchte ja:

Code Auswählen Erweitern


root@rpi-az-desktop:~# gatttool -b 58:9E:C6:10:XX:YY -t public --char-read --uuid=00002a19-0000-1000-8000-00805f9b34fb
handle: 0x001b value: 13
root@rpi-az-desktop:~# bluetoothctl
Agent registered
[bluetooth]# connect 58:9E:C6:10:XX:YY
Attempting to connect to 58:9E:C6:10:XX:YY
Failed to connect: org.bluez.Error.Failed


Hatte relativ früh bei G-Tags schon merkwürdige Phänomene. U. a. haben die keine Beacons mehr gesendet wenn sie verbunden waren. Würde mal drauf tippen, dass mein Test-G-Tag irgendwas anderes "erlebt" hat als Deine. Aber ich weiß es schlichtweg nicht und auch nicht, warum gatttool das scheinbar egal ist.

Letztlich hat das aber auch was Positives: Normalerweise läuft bei mir alles zuverlässig und die Nutzer finden dann merkwürdige Probleme. Das zu rekonstruieren ist immer aufwendig. Diesmal ist es andersrum

Patrick

[FHEM_Starter]

Hallo und ein Frohes Neues,

Dank Patrick haben wir eine weitere Erkenntnis gewonnen: die bluez Version! Ab der Version 5.50 kommen die Battariewerte auch ordentlich, aktuell teste ich es mit der Version 5.55 auf zwei Raspberries.

Liebe Grüße
Wolfgang