lepresenced und G-Tags - nach einiger Zeit nur noch absent/unreachable

[gestein]

Hallo,

ich versuche auch schon seit einiger Zeit lepresenced mit collectord stabil mit meinem Gtags zum Laufen zu bringen.
Bis dato leider ohne jeden Erfolg.
Sobald lepresenced startet, erscheinen die Gtags in fhem als present, aber nach einiger Zeit (kann auch Stunden dauern) sind die wieder absent.
Dann hin und wieder sind die Gtags wieder present und wieder weg.
Insgesamt habe ich 3 USB-Adapter im Raspberry 4 (den internen und 2 Sticks), wobei lepresend mit einem eigenen Stick läuft.

Ich bin leider nicht der Profi und hoffe, dass ich einigermaßen richtig beschreibe, was ich getan habe und warum.

Über die Feiertage habe ich tagelang die logs von hcitool und hcidump mitlaufen lassen (sowohl mit lepresenced als auch direct in der shell).
Nach einiger Zeit passiert es bei mir, dass hcidump nichts mehr anzeigt - dachte ich zumindest.
Dann bin ich draufgekommen, dass - zumindest bei mir - das hcitool das Scannen einstellt bzw. keine Ausgaben mehr anzeigt.
Damit kommen auch keine Meldungen mehr vom hcidump (also vermute ich, dass hcitool das Scannen einstellt).

Kurz bevor hcitool seine Meldungen einstellt, erscheinen beim hcidump keine "> HCI Event:" mehr, sondern einige "< HCI Command:" Meldungen.
Woher die kommen, weiß ich nicht.

Sobald einige dieser "< HCI Command:" Meldungen gekommen sind, stellt hcitool dann das Scannen ein.
Der Prozess läuft aber weiter.
Ich habe mir im perl script von lepresenced ein paar weitere printf eingebaut um zu sehen, was so unter der Haube passiert, z.B. habe ich die $pid des Aufrufs von hcitool ausgegeben:

Code Auswählen Erweitern

$pid_hcitool = open($hcitool, "-|", "stdbuf -oL hcitool -i " . $device . " lescan --duplicates 2>&1") || die('Unable to start scanning. Please make sure hcitool and stdbuf are installed!');
Während lepresenced läuft, kann ich mit "ps -ax | grep hci" den Prozess und die gleiche pid sehen.
Stimmt also.

Wenn hcidump und hcitool die Ausgaben im log-File einstellen, bleiben beide Prozesse am Laufen.
Das Problem im Code von lepresenced ist der folgende Aufruf in der Procedure "bluetooth_scan_thread":

Code Auswählen Erweitern

while (<$hcitool>)
Da hcitool keine Ausgaben mehr liefert, bleibt der Thread hier quasi stehen und die while-Schleife wird nicht mehr weiter abgearbeitet.

Testweise habe ich daher quick&dirty die globale Variable "my $pid_hcitool :shared;" und in der Prozedur " bluetooth_dump_thread" folgenden Code eingefügt:

Code Auswählen Erweitern

      if ($_ =~ m/^< HCI Command: /) {
          printf("DEBUG: HCI Dump Command erkannt, state:%d, '%s', resetting...\n", $state, $_);
          system(sprintf('sudo kill %d', $pid_hcitool));
          close($hcidump);
          last;
     }

Ich weiß, das ist ziemlich rüde und es gibt sicherlich viel bessere Lösungen dafür.
Aber es funktioniert nun bei mir seit ein paar Tagen stabil.
Vielleicht könnte sich da mal jemand genauer hineindenken, eventuell ist es ja zumindest eine "heiße" Spur.

Die nächsten Tage werde ich mal weiter testen.

lg, Gerhard

[PatrickR]

Hallo Gerhard,

Das Problem im Code von lepresenced ist der folgende Aufruf in der Procedure "bluetooth_scan_thread":

Code Auswählen Erweitern

while (<$hcitool>)
Da hcitool keine Ausgaben mehr liefert, bleibt der Thread hier quasi stehen und die while-Schleife wird nicht mehr weiter abgearbeitet.

Das klingt ja fast so als wäre lepresenced schuld, weil er falsch wartet

Aber das tatsächliche Problem hast Du ja schon isoliert: Aus irgendeinem Grund wirft hcidump keine sinnvollen Events mehr aus. Jetzt ist mir natürlich schleierhaft, was genau dazu führt. Möglicherweise beißt sich irgendwas auf Deinem System mit lepresenced, bzw. dem Bluetooth-Gerät, das es benutzt. Kannst Du zur Sicherheit mal ein Log mit LOG_LEVEL Debug vom Start posten, einen Dump der "HCI Command"s und evtl. ein Stück Syslog um den Problemzeitpunkt herum?

Es gibt mittlerweile eine neue Methode, wie man sauberer dumpen kann. Eine positiver Nebeneffekt davon ist, dass man nur noch einen Prozess benötigt und nicht mehr das Duo hcitool und hcidump. Ggf. würde das Dein Problem auch beheben.

Patrick

/Edit: Gerade noch einmal nachgesehen, sowohl hcitool als auch hcidump werden mit dem Wunschdevice aufgerufen, zumindest in 0.9.

[gestein]

Hallo Pattrick,

So war das natürlich nicht gemeint 😉
Ich werde die logs sammeln und schicken.
Besonderes ist mir nicht aufgefallen.

Welche neue Methode gibt es denn?

Lg, Gerhard

[dieda]

Hier ist es ähnlich. Lepresenced macht was es will. Egal ob auf Jessie oder Buster... Das Ganze fing vor ca 9 Monaten an... Mein Buster ist frisch aufgesetzt. Alles bis auf die zWave-Neugeräte-Anmeldung läuft rund. So als Hinweis.

[gestein]

Hallo Patrick,

ich benutze auch die Version 0.9 von lepresenced und auf den richtigen Adapter wird auch richtig zugegriffen.
Aber erst die Änderung mit dem "kill" für den hcitool-Prozess brachte das gewünschte Ergebnis.

lg, Gerhard

[PatrickR]

Hi!

Welche neue Methode gibt es denn?

bluetoothctl. IIRC war das zur Anfangszeit von lepresenced nicht verfügbar, weshalb das aktuelle Konstrukt entstanden ist.

bluetoothctl hat diverse Vorteile:
-Es vereint hcitool und hcidump in einem Tool.
-Es schreibt brav an stdout (d. h. der Trick mit stdbuf fällt auch weg.)
und vermutlich weitere.

Patrick

[PatrickR]

Das Ganze fing vor ca 9 Monaten an...

Was ist denn vor 9 Monaten passiert?

[gestein]

Hallo Patrick,

Klingt gut. 
Nutzt lepresenced denn bluetoothctl?
Oder wie bindet man das dann über collectd an fhem?

Momentan läuft lepresenced zwar immer noch ohne weitere Probleme.
Aber wer weiß - wenn es etwas besseres gibt

Danke!
Lg, Gerhard

[PatrickR]

Hi!

Nutzt lepresenced denn bluetoothctl?

Aktuell nicht. Aber das wollte ich mir schon länger mal ansehen. Dummerweise habe ich so einen kleinen Projektrückstau.

Oder wie bindet man das dann über collectd an fhem?

Direkt garnicht, wobei man sicherlich irgendein Skript hinfrickeln könnte, was dann über einen Shell-Aufruf von PRESENCE aufgerufen wird. So war es ja in der Anfangszeit als es mit den BLE-Tags losging. Durch die Instabilität der Bluetooth-Implementierung unter Linux ist einem das dann regelmäßig um die Ohren geflogen.

Momentan läuft lepresenced zwar immer noch ohne weitere Probleme.
Aber wer weiß - wenn es etwas besseres gibt

Die Annahme, es könnte je etwas Besseres geben als lepresenced stimmt mich sehr traurig. Allein die Zahl an Workarounds, mit denen es versucht, die verbogene Bluetooth-Implementierung wieder hinzubiegen und sich gegen Batterieskripte oder andere Widersacher zu verteidigen...

Spaß bei Seite. Ich glaube, wir haben in Deinem Fall zwei Möglichkeiten:
a.) bluetoothctl lässt sich integrieren - Voraussetzung: Dein Problem tritt damit nicht auf.
b.) ich integriere Deinen Workaround in sauber. - Voraussetzung: Die Events, die Du gefunden hast, taugen als gutes Kriterium für einen Neustart des Prozesses, d. h. sie tauchen plausibel exakt dann auf, wenn das Problem besteht.

Kannst Du in Deinem gepatchten lepresenced die "< HCI Command:"s wegschreiben, z. B. ins Syslog?

Patrick

[PatrickR]

Guten Abend!

@gestein: Habe mal Deinen Workaround in etwas schöner eingebaut. Leider kann ich Dein Problem nicht wirklich rekonstruieren.

Probiere doch mal die angehängte Version 0.91dev.

Patrick

[gestein]

Hallo Partick,

Das ging ja schnell.
Ich lasse gerade die logs mitlaufen.
Aber ich probiere Deine neue Version gerne gleich aus.

Kann ein bisschen dauern, da die "HCI Commands" nur sporadisch kommen.

lg, Gerhard

[gestein]

Hallo Patrick,

ich habe mir Deinen Code angesehen.
Allerdings machst Du kein "kill $hcitool_pid".

Das Problem ist, dass hcitool stehen bleibt und keine weiteren Ausgaben mehr von sich gibt (und nur manchmal nach einiger Zeit neu mit dem Scannen beginnt).
Bei mir treten diese "< HCI Commands" auch auf, wenn bspw. ein anderer Prozess auf den gleichen Adapter zugreift oder wenn man "sudo hciconfig <adapter> down" eingibt.
Dann hört hcitool zu scannen auf, aber der Prozess läuft weiter.
Auch wenn man z.B. "sudo hciconfig <adapter> up" eingibt, startet hcitool nicht mehr.

Kannst Du das mal versuchen?
Vielleicht ist das nur bei mir so?

lg, Gerhard

[PatrickR]

ich habe mir Deinen Code angesehen.
Allerdings machst Du kein "kill $hcitool_pid".

Stimmt! Ich wollte es wie gesagt etwas sauberer lösen. Ich konnte gestern ein hoffentlich vergleichbares Problem mit einem parallelen hcitool lescan provozieren und der neue Code machte wie geplant kurzen Prozess.

Vorschlag: Teste die Version doch mal, am besten mit LOG_DEBUG.

Patrick



Von unterwegs gesendet.

[StephanFHEM]

An alle BT-spezialisten:-) ich habe mir BT5 Tags besorgt und diese über lepresenced eingebunden. Das funktioniert soweit auch perfekt analog zu den G-Tags. Ziel war es, die Reichweite etwas zu erhöhen im Haus ohne einen BT-Repeater zu bauen. Leider ist die Reichweite/RSSI-Wert genau gleich zu den G-Tags. Ich gehe also davon aus, dass die Erkennung vom Pi4 nicht über BT5 läuft (obwohl er das können sollte). Kann irgendwo rausfinden welches BT gerade genutzt wird?
Muss man BT5 im PI erst mal irgendwo software-seitig aktivieren?

[Eistee]

Was bitte hat denn Bluetooth 5 mit der Reichweite der Tags zu tun? Du musst auf die Klasse achten.
- CLASS 1 bis 100m Reichweite
- CLASS 2 bis 10m Reichweite
- CLASS 3 bis 1m Reichweite