lepresenced - hciconfig hcitool gatttool deprecated

[drhirn]

Hallo,

im Zuge von ständigen Problemen mit lepresenced in letzter Zeit und der daraus folgenden Beschäftigung mit dem Thema, habe ich den Verdacht gewonnen, dass hciconfig hcitool gatttool eigentlich schon lange deprecated sind? Liege ich da richtig? Verdacht wird dadurch bestärkt, dass ich in letzter Zeit wieder mal eine Runde Linux Updates gemacht habe. Und eben seit dem die Probleme hab.

Wenn ja, ist angedacht, die Tools zu ersetzen (bluetoothctl)?

Danke
Stefan

P.S.: Das angesprochene Problem:

Code: [Auswählen]

hcitool lescan
Set scan parameters failed: Input/output error

[PatrickR]

Hi!

im Zuge von ständigen Problemen mit lepresenced in letzter Zeit und der daraus folgenden Beschäftigung mit dem Thema, habe ich den Verdacht gewonnen, dass hciconfig hcitool gatttool eigentlich schon lange deprecated sind? Liege ich da richtig? Verdacht wird dadurch bestärkt, dass ich in letzter Zeit wieder mal eine Runde Linux Updates gemacht habe. Und eben seit dem die Probleme hab.

Streng genommen haben diese Tools von Anfang an Probleme gemacht, was der Grund für die Armada von Workarounds in lepresenced ist. Insofern lässt sich daraus keine Deprecation ableiten. Dennoch hast Du trotzdem Recht, s. insb.: https://github.com/bluez/bluez/blob/master/Makefile.tools

Wenn ja, ist angedacht, die Tools zu ersetzen (bluetoothctl)?

Das ist schon länger angedacht. Das Problem ist aber, dass damit ein großflächiger Rewrite (mit einer deutlichen Verschlankung) verbunden wäre. Auch ist auf Grund der bisherigen Erfahrungen davon auszugehen, dass trotz des Wechsels immer noch eine Reihe von Workarounds nötig sein werden. Aber da kann ich falsch liegen. Auch wäre das vermutlich ein Anlass, nicht mehr an das PRESENCE-Protokoll anzuknüpfen sondern auf MQTT umzusatteln. Das würde lepresenced besser von FHEM entkoppeln, FHEM damit entlasten und lepresenced mehr Flexibilität gewähren. Ungeachtet dessen fehlte mir bislang die Zeit, mich darum zu kümmern.

P.S.: Das angesprochene Problem:

Code: [Auswählen]

hcitool lescan
Set scan parameters failed: Input/output error

Sollte dieser Fehler auftreten - bei mir in den letzten 30 Tagen exakt einmal - kümmert sich lepresenced darum:

Code: [Auswählen]

Apr  1 13:21:36 rpi-flur lepresenced[28377]: [tid:1] main::bluetooth_scan_thread: Received 'Set scan parameters failed: Input/output error', resetting...
Apr  1 13:21:37 rpi-flur lepresenced[28377]: [tid:2] main::bluetooth_dump_thread: Received 'HCI sniffer - Bluetooth packet analyzer ver 5.55'.
Apr  1 13:21:37 rpi-flur lepresenced[28377]: [tid:2] main::bluetooth_dump_thread: Received 'device: hci0 snap_len: 1500 filter: 0xffffffff'.
Apr  1 13:21:37 rpi-flur lepresenced[28377]: [tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...
Apr  1 13:21:39 rpi-flur lepresenced[28377]: [tid:1] main::bluetooth_scan_thread: Received 'LE Scan ...'.
Hast Du mal einen Logauszug mit LOG_DEBUG von lepresenced, am besten direkt nach einem Neustart des Systems ohne konkurrierende Ausführung von Tools auf der Kommandozeile? Hast Du parallel andere Tools laufen, die Bluetooth nutzen?
Wie äußern sich Deine vorwiegenden Probleme denn genau, also startet lepresenced garnicht oder wird er nach zufälliger Zeit "blind"?

Falls Du einen Raspberry PI einsetzt:
Im Schwesterthread überschlagen sich gerade die positiven Emotionen nach der Installation einer älteren Bluetooth-Firmware (https://forum.fhem.de/index.php/topic,75559.msg1177215.html#msg1177215). Hast Du das mal probiert?

Patrick

[drhirn]

Das ist schon länger angedacht. Das Problem ist aber, dass damit ein großflächiger Rewrite (mit einer deutlichen Verschlankung) verbunden wäre. Auch ist auf Grund der bisherigen Erfahrungen davon auszugehen, dass trotz des Wechsels immer noch eine Reihe von Workarounds nötig sein werden. Aber da kann ich falsch liegen.

Man müsste es versuchen.

Auch wäre das vermutlich ein Anlass, nicht mehr an das PRESENCE-Protokoll anzuknüpfen sondern auf MQTT umzusatteln. Das würde lepresenced besser von FHEM entkoppeln, FHEM damit entlasten und lepresenced mehr Flexibilität gewähren.

Das ist eine richtig gute Idee!

Ungeachtet dessen fehlte mir bislang die Zeit, mich darum zu kümmern.

Und das hab ich schon befürchtet . Ich hab mir den Code mal angesehen und überlegt, ob ich da etwas beitragen könnte. Aber das übersteigt meine Fähigkeiten bei Weitem. Leider. Wenn aber Tester bzw. Leute für niedrige Arbeiten gesucht werden, ich stehe zur Verfügung.

Hast Du mal einen Logauszug mit LOG_DEBUG von lepresenced, am besten direkt nach einem Neustart des Systems ohne konkurrierende Ausführung von Tools auf der Kommandozeile? Hast Du parallel andere Tools laufen, die Bluetooth nutzen?

Ging mir jetzt gar nicht so sehr um Hilfe bei der Problemlösung. Ich wollte es nur nicht unerwähnt lassen. Wiki-Hinweis dazu kenne ich und den Thread mit dem Rückstieg auf alte Firmware auch.
Bei mir erholt sich nur lepresenced nicht (immer) von selber. Und mein wichtigster Bluetooth-"Empfänger" ist eine Debian-VM mit BT-Dongle. Da nützt mir die alte PI-BT-Firmware nichts. Sonstige BT-Tools laufen nicht.
Bezüglich Raspberrys ist aber meine - kaum verifizierte - Erkenntnis, dass es mit Raspberry Pi OS Legacy (Buster) gut funktioniert. Ist halt Buster, aber sicherheitstechnisch noch aktuell. Und ich hab noch so viele alte PIs rumliegen, dass ich meine ganze Wohnung damit pflastern könnte. Könnte also meine bisher genutzten "Empfänger" ersetzen.

Naja, vielleicht findet sich ja jemand, der Lust und die Fähigkeiten hat, das Thema irgendwann anzugehen.

Danke dir auf jeden Fall!

[PatrickR]

Hi!

Das Problem bei dem MQTT-Ansatz ist, dass sicherlich nicht alle Nutzer umsatteln werden und ich auch nicht zwei Versionen pflegen möchte. Aber das könnte man ggf. mit Tutorials abfangen.

Bei mir erholt sich nur lepresenced nicht (immer) von selber. Und mein wichtigster Bluetooth-"Empfänger" ist eine Debian-VM mit BT-Dongle. Da nützt mir die alte PI-BT-Firmware nichts. Sonstige BT-Tools laufen nicht.

Bei mir läuft gerade einen Developmentversion, die einen Watchdog enthält. Der prüft regelmäßig, ob (überhaupt) Geräte gesehen werden und startet ggf. die Scan-Prozesse neu. Das setzt aber natürlich voraus, dass (fast) immer irgendwelche Geräte erreichbar sind. Würde Dir das helfen?

Patrick

[PatrickR]

Hi!

So, ich habe mal was gebaut. Das braucht noch etwas Feinschliff, dann kann ich es mal zum Testen hochladen.

Patrick

[drhirn]

Bei mir läuft gerade einen Developmentversion, die einen Watchdog enthält. Der prüft regelmäßig, ob (überhaupt) Geräte gesehen werden und startet ggf. die Scan-Prozesse neu. Das setzt aber natürlich voraus, dass (fast) immer irgendwelche Geräte erreichbar sind. Würde Dir das helfen?

Sorry Patrick, der Beitrag ist bei mir leider untergegangen.
Seit April läuft's bei mir überraschend stabil. Aber ein Watchdog schadet natürlich nie. Könnte man den optional machen und mittels Attribut oder Config-Eintrag aktivieren?

[GlennDandy]

Hallo,

ich würde mich den Problem anschließen, ich hatte immer einen USB Stick mit einem Broadcom bt4.0 Chipsatz verwendet, der geht sehr gut aber die Reichweite ist extrem bescheiden.

Im Zuge eines Hardware upgrades kam eine m.2 Karte Intel AX200 (BT5) rein, mit dieser Karte ist es absolut nicht möglich hcitool zu nutzen um einen LE Scan durchzuführen.
Es kommt direkt ein Input/output error, nach langer suche und intensiver Recherche hies es hcitool ist veraltet nutze bluetoothctl,
mit bluetoothctl ist ein LE scan ohne Probleme möglich.

Das Resultat daraus ist leider das keine Anwesenheitskontolle funktioniert, weil alle auf hcitool bassieren.

[PatrickR]

Hi!

Seit April läuft's bei mir überraschend stabil. Aber ein Watchdog schadet natürlich nie. Könnte man den optional machen und mittels Attribut oder Config-Eintrag aktivieren?

Der ist per Default aus, aber beliebig konfigurierbar. Wenn ich aber sehe, was bei mir hier an Geräten rumschwirrt, die teilweise vermutlich den Nachbarn gehören, ist eigentlich genug für den Watchdog los.

Gruß
Patrick

[PatrickR]

Hi!

Es kommt direkt ein Input/output error, nach langer suche und intensiver Recherche hies es hcitool ist veraltet nutze bluetoothctl,
mit bluetoothctl ist ein LE scan ohne Probleme möglich.

Bluetoothctl scheint in der Tat deutlich stabiler zu laufen. Werde wenn ich so weit bin in den nächsten Tagen mal mein neues Werkzeug hochladen, was mit bluetoothctl scannt und nicht mehr das Presence-Modul bedient sondern die Ergebnisse per mqtt verschickt (siehe Screenshot oben). Dank dem MQTT2_SERVER-Modul von Rudi sollte das sogar ohne externe Dienste nutzbar sein.

Patrick

[PatrickR]

Guten Abend!

So, hier gibt es mal etwas zum Ausprobieren.

Installationsvoraussetzungen:

Code: [Auswählen]

apt-get install bluez libexpect-perl libnet-server-perl libreadonly-perl
cpan Net::MQTT::Simple Net::MQTT::Simple::Auth

Aufruf des Skripts, z. B. mit:

Code: [Auswählen]

ble2mqttd --mqttserver mqtt.domain:8883
ble2mqttd --mqttserver mqtt.domain:8883 --mqttuser user --mqttpass pass
Eine SSL-Verbindung wird ebenfalls unterstützt. Infos dazu und weitere Optionen gibt es mit --help.

ble2mqttd lauscht nach Bluetooth-LE-Geräten (wie lepresenced) und schickt die Ergebnisse an einen MQTT-Server. In FHEM kann man dafür bspw. ein MQTT2_SERVER-Device angelegt werden (falls nicht ohnehin ein externer mqtt-Server wie mosquitto läuft) und jeweils ein MQTT2_DEVICE pro zu überwachendem Bluetooth-Tag.

Patrick

[drhirn]

**edit**
Da tut sich bei mir nicht viel:

Code: [Auswählen]

user@server:~$ sudo ./ble2mqttd --mqttserver url:1883 --mqttuser user --mqttpass password --debug 6 --logtarget stdout --daemon
main::sanity_check: md5 digest of './ble2mqttd' is: 'a59431f8eb0e6b9b4bb14ab66099c17d'.
main::sanity_check: bluetoothctl found at '/usr/bin/bluetoothctl'.
main: Sending 'menu scan'...
main: Sending 'clear'...
main: Sending 'duplicate-data on'...
main: Sending 'transport le'...
main: Sending 'back'...
main: Sending 'scan on'...
main: Scan started.
### Match:      [NEW] 44:44:44:69:01:9C (44-44-44-69-01-9C)
### Match RSSI: [CHG] 44:44:44:69:01:9C -> -60
### Match:      [CHG] 44:44:44:69:01:9C (ManufacturerData Key: 0x00e0)
### Match:      [CHG] 44:44:44:69:01:9C (ManufacturerData Value:)
### Match:      [CHG] 44:44:44:69:01:9C (ServiceData Key: 0000fe9f-0000-1000-8000-00805f9b34fb)
### Match:      [CHG] 44:44:44:69:01:9C (ServiceData Value:)
### Match RSSI: [CHG] 44:44:44:69:01:9C -> -59
### Match:      [CHG] 44:44:44:69:01:9C (ManufacturerData Key: 0x00e0)
### Match:      [CHG] 44:44:44:69:01:9C (ManufacturerData Value:)
### Match:      [CHG] 44:44:44:69:01:9C (ServiceData Key: 0000fe9f-0000-1000-8000-00805f9b34fb)
### Match:      [CHG] 44:44:44:69:01:9C (ServiceData Value:)
### Match RSSI: [CHG] 44:44:44:69:01:9C -> -59
### Match:      [CHG] 44:44:44:69:01:9C (ManufacturerData Key: 0x00e0)
### Match:      [CHG] 44:44:44:69:01:9C (ManufacturerData Value:)
### Match:      [CHG] 44:44:44:69:01:9C (ServiceData Key: 0000fe9f-0000-1000-8000-00805f9b34fb)
### Match:      [CHG] 44:44:44:69:01:9C (ServiceData Value:)
### Match RSSI: [CHG] 44:44:44:69:01:9C -> -60
### Match:      [CHG] 44:44:44:69:01:9C (ManufacturerData Key: 0x00e0)
### Match:      [CHG] 44:44:44:69:01:9C (ManufacturerData Value:)
### Match:      [CHG] 44:44:44:69:01:9C (ServiceData Key: 0000fe9f-0000-1000-8000-00805f9b34fb)
### Match:      [CHG] 44:44:44:69:01:9C (ServiceData Value:)
### Match RSSI: [CHG] 44:44:44:69:01:9C -> -59

Bricht irgendwie nach dem ersten gefundenen Gerät ab.
Das heißt --daemon nicht --daemonzie. Ist in der Hilfe auch falsch.

Am MQTT-Server kommt aber trotzdem nichts an.

(Und in der Hilfe sind die Debug-Optionen falsch beschrieben. Da wird offenbar eine Zahl erwartet).

[PatrickR]

Hi!

**edit**

Code: [Auswählen]

user@server:~$ sudo ./ble2mqttd --mqttserver url:1883 --mqttuser user --mqttpass password --debug 6 --logtarget stdout --daemon
main::sanity_check: md5 digest of './ble2mqttd' is: 'a59431f8eb0e6b9b4bb14ab66099c17d'.
main::sanity_check: bluetoothctl found at '/usr/bin/bluetoothctl'.
main: Sending 'menu scan'...
main: Sending 'clear'...
main: Sending 'duplicate-data on'...
main: Sending 'transport le'...
main: Sending 'back'...
main: Sending 'scan on'...
main: Scan started.
### Match:      [NEW] 44:44:44:69:01:9C (44-44-44-69-01-9C)
### Match RSSI: [CHG] 44:44:44:69:01:9C -> -60
### Match:      [CHG] 44:44:44:69:01:9C (ManufacturerData Key: 0x00e0)
### Match:      [CHG] 44:44:44:69:01:9C (ManufacturerData Value:)
### Match:      [CHG] 44:44:44:69:01:9C (ServiceData Key: 0000fe9f-0000-1000-8000-00805f9b34fb)
### Match:      [CHG] 44:44:44:69:01:9C (ServiceData Value:)
### Match RSSI: [CHG] 44:44:44:69:01:9C -> -59
### Match:      [CHG] 44:44:44:69:01:9C (ManufacturerData Key: 0x00e0)
### Match:      [CHG] 44:44:44:69:01:9C (ManufacturerData Value:)
### Match:      [CHG] 44:44:44:69:01:9C (ServiceData Key: 0000fe9f-0000-1000-8000-00805f9b34fb)
### Match:      [CHG] 44:44:44:69:01:9C (ServiceData Value:)
### Match RSSI: [CHG] 44:44:44:69:01:9C -> -59
### Match:      [CHG] 44:44:44:69:01:9C (ManufacturerData Key: 0x00e0)
### Match:      [CHG] 44:44:44:69:01:9C (ManufacturerData Value:)
### Match:      [CHG] 44:44:44:69:01:9C (ServiceData Key: 0000fe9f-0000-1000-8000-00805f9b34fb)
### Match:      [CHG] 44:44:44:69:01:9C (ServiceData Value:)
### Match RSSI: [CHG] 44:44:44:69:01:9C -> -60
### Match:      [CHG] 44:44:44:69:01:9C (ManufacturerData Key: 0x00e0)
### Match:      [CHG] 44:44:44:69:01:9C (ManufacturerData Value:)
### Match:      [CHG] 44:44:44:69:01:9C (ServiceData Key: 0000fe9f-0000-1000-8000-00805f9b34fb)
### Match:      [CHG] 44:44:44:69:01:9C (ServiceData Value:)
### Match RSSI: [CHG] 44:44:44:69:01:9C -> -59


Das sieht doch schonmal gut aus.

Das heißt --daemon nicht --daemonzie. Ist in der Hilfe auch falsch.

--daemon und --daemonize funktionieren beide. Aber durch das Setzen von --debug "verzichtest" Du wieder darauf, was aktuell auch die richtige Entscheidung ist (s. u.).

(Und in der Hilfe sind die Debug-Optionen falsch beschrieben. Da wird offenbar eine Zahl erwartet).

Zumindest missverständlich. Level ist ja kein wohldefinierter Begriff. Werde es aber anpassen. Bisher sehe ich das Ding eher so als PoC, bei dem - wenn er denn mal bei anderen Personen als mir zuverlässig funktioniert - ggf. jemand unterstützt. Die Doku gehört definitiv dazu.

Am MQTT-Server kommt aber trotzdem nichts an.

Das ist insofern etwas doof als dass ich in CPAN keine vernünftige MQTT-Library gefunden habe. Die, die ich verwende, hat leider exakt Null Error Handling. Rudi hat das gelöst, in dem er einfach gleich beim Urknall angefangen und alles handgeklöppelt hat.

Kannst Du Dich vielleicht mal von einem einfachen Setup schrittweise zu einem komplexeren durchhangeln? Also z. B. ohne SSL (jetzt schon der Fall), ohne ACLs und ohne Auth starten und dann schauen, ab wann es schief geht?

Alternativ: Kannst Du mir mal Deine MQTT-Server-Config beschreiben/schicken, damit ich das reproduzieren kann? Nutzt Du Mosquitto oder das Modul in FHEM oder was ganz anderes?

Bei mir funktioniert es aktuell zuverlässig mit SSL, Auth und ACLs. Mit einem blanken MQTT2_SERVER hatte ich auch mal gestet. Aber wie gesagt traue ich der MQTT-Library nicht.

Patrick

[drhirn]

Aber wie gesagt traue ich der MQTT-Library nicht.

Zu recht

Mosquitto schreibt in die Logs:

Code: [Auswählen]

1656329337: Invalid protocol version 3 in CONNECT from 10.168.1.11.
Mit einem MQTT2_SERVER hat's funktioniert, den möchte ich aber eigentlich nicht verwenden.

Hier noch meine Mosquitto-Config:

Code: [Auswählen]

listener 1883

persistence true
persistence_location /mosquitto/data/
log_dest file /mosquitto/log/mosquitto.log

allow_anonymous true
password_file /mosquitto/config/mosquitto.passwd


[PatrickR]

Zu recht

Mosquitto schreibt in die Logs:

Code: [Auswählen]

1656329337: Invalid protocol version 3 in CONNECT from 10.168.1.11.

Interessanterweise funktioniert es bei mir mit der aktuellen offiziellen Docker-mosquitto-Version.

Aber das Problem ist wohl bekannt:
https://community.home-assistant.io/t/zoneminder-zone-specific-alarms/92227/6

Die "Lösung" scheint zu sein, Nett::MQTT::Simple::Auth zu patchen 

Großartig. Das kann natürlich jeder für sich machen, aber für eine breite Lösung taugt das überhaupt nicht.

Patrick

[drhirn]

Interessanterweise funktioniert es bei mir mit der aktuellen offiziellen Docker-mosquitto-Version.

Verwende ich auch (image: eclipse-mosquitto:latest). Das macht's aber nur noch merkwürdiger.

Die "Lösung" scheint zu sein, Nett::MQTT::Simple::Auth zu patchen 

Großartig. Das kann natürlich jeder für sich machen, aber für eine breite Lösung taugt das überhaupt nicht.

**edit**
Bringt nichts, da kommt dann gleich der nächste Fehler
Wenn man's richtig ändert, funktioniert das