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

[OdfFhem]

@MadMax-FHEM

Der Stand vom "Thu Jan 28 12:06:05 GMT 2021" scheint für den Pi3B+ momentan wohl der aktuellste Stand zu sein - apt-get bietet zumindest nichts Neues an.

Folglich kann ich auf einen problemlosen Betrieb seit August 2020 "verweisen" ... die Datümer der sorgenfreien Stände davor kenne ich leider nicht mehr ... ich selbst nutze die GTags seit Anfang 2018 ununterbrochen ...

[MadMax-FHEM]

Also ich nutze die G-Tags auch seit etwa Anfang 2019 und immer ohne Probleme, bislang.

Leider habe ich aktuell keinen PI3B+ "rumliegen", dann könnte ich noch testen, ob es da auch mit aktuellem Buster keine Probleme gibt.

Aber nach aktuellem Teststand:

1x PI3B mit aktuellem Buster machen mit internem BT seit ca. 1 Woche Probleme (ist auch die "HUE-Bridge")

1x PI3B mit aktuellem Buster ganz frisch aufgesetzt macht mit internem und externem BT Probleme
(zuvor noch den Treiber für internes BT von einem älteren Stand kopiert: trotzdem Probleme)

DENSELBEN PI3B (also den Test-PI) mit älterem Buster aufgesetzt: läuft nun seit (fast) 24h stabil... So lange lief es vorher nie (seit ich Probleme habe)

Daher denke ich liegt es schon sehr "eindeutig" (bei mir) am OS...

Werde dann mal den Test-PI updaten auf den aktuellen Stand und dann mal sehen...

Gruß, Joachim

Wobei mich das mit "keine Updates" wundert, weil seit ich das erste Mal Probleme hatte gab es schon ein Update (was nicht geholfen hat) und mittlerweile gibt es seit gestern wieder eines. Ich habe AptToDate laufen und das prüft ja täglich und zeigt Updates an... Und meine Buster-Instalationen sind von gestern auf heute wieder "rot"

Aktuell ist doch apt statt apt-get? Gut macht (verm.) noch dasselbe...

[OdfFhem]

@MadMax-FHEM

Ich nutze derzeit auch einen Pi4B für den reinen Desktop-Einsatz - also ohne echten Servernutzen.

Hier habe ich auch mal auf Updates getestet und dort gab es welche; nachdem ich diese eingespielt hatte, Reboot durchgeführt. Nach dem Neustart geprüft - an der reinen OS-Version hatte sich nichts geändert, da nur Updates für Browser, o.ä. bereitstanden.


"vcgencmd version" liefert auf dem 3B+ (Server-Einsatz)

Code Auswählen Erweitern


Jan 27 2021 22:26:53
Copyright (c) 2012 Broadcom
version 99d9a48302e4553cff3688692bb7e9ac760a03fa (clean) (release) (start)

auf dem 4B (Desktop-Einsatz)

Code Auswählen Erweitern


Jan 27 2021 22:19:57
Copyright (c) 2012 Broadcom
version 99d9a48302e4553cff3688692bb7e9ac760a03fa (clean) (release) (start)


Datum stimmt überein, Zeit nicht ganz, der Rest aber komplett ...


"uname -a" sagt, dass sich beide Rechner auf dem Stand "... 5.10.11 ... #1399 ... Jan 28 ..." befinden ...

[MadMax-FHEM]

Bei meinem PI3B auf dem es aktuell seit 24h stabil mit dem INTERNEN BT läuft:

Code Auswählen Erweitern


$ vcgencmd version
Feb 12 2020 12:38:29
Copyright (c) 2012 Broadcom
version 53a54c770c493957d99bf49762dfabc4eee00e45 (clean) (release) (start_cd)
$ uname -a
4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux


Auf dem mit den Problemen:

Code Auswählen Erweitern


$ vcgencmd version
Jan 27 2021 22:27:11
Copyright (c) 2012 Broadcom
version 99d9a48302e4553cff3688692bb7e9ac760a03fa (clean) (release) (start_cd)
$ uname -a
5.10.11-v7+ #1399 SMP Thu Jan 28 12:06:05 GMT 2021 armv7l GNU/Linux


Beim 2ten wo es Probleme gibt kann ich erst ein andermal posten, der ist ja noch mit dem OS/SD versorgt, die aktuell stabil läuft

Aber: beim PI mit Problemen stehen (wie ja geschrieben) aktuell schon wieder Updates bereit...

Code Auswählen Erweitern


libzstd1/stable 1.3.8+dfsg-3+rpi1+deb10u1 armhf [upgradable from: 1.3.8+dfsg-3+rpi1]
raspi-config/testing 20210212 all [upgradable from: 20210119]


Ich werde dann mal den laufenden PI updaten und dann sehen...
...meine Vermutung: es wird (wieder) Probleme geben.
EDIT: so update durchgeführt. Mal sehen... Ich hab mal "mitgeschrieben" was da so upgedated wurde. Evtl. spiele ich dann mal die alten Versionen bzgl. BT ein...
EDIT: jetzt lief es gut 2h durch. Dachte schon, dass ich "bekloppt" bin. Aber: grad wieder "absent" obwohl "da"... Ich versuche mal die "alten" BT-Versionen (vom "Mitschrieb") einzuspielen... Mal sehen...

Danach werde ich mir überlegen wie ich da weiter mache...

- PI ZeroW der aktuell "nur" die FlowerSense macht mittels BT-USB-Dongle auch die Anwesenheit

- Meinen Test-PI wieder mit der alten FW versorgen und gut

- Einen ESP32 anschaffen und da mal weiterschauen

Gruß, Joachim

[MadMax-FHEM]

So, also ich habe nun wieder ein älteres Buster eingespielt und bluez und pi-bluetooth vom Update "excluded"...

Hat aber nicht geholfen...
(bin jetzt nicht sicher, ob ich da den externen Dongle auch getestet habe / mal sehen, vielleicht hab ich ja noch mal Zeit/Lust)

Für weitere Tests, um herauszufinden WAS in dem (letzten) Buster-Update nun dazu führt, dass es nicht mehr geht, habe ich keine Lust mehr

Mein (aktueller) Weg: ich hab einfach den BT-Dongle (danke @Jamo   ) an meinen "PI-ZeroW-BT-Extender" (der Name ist ja "Programm" ) angeschlossen und dort lepresenced installiert.

Nun macht er eben BT (intern) für die FlowerSense auf dem Balkon...
...und BT (extern) bzgl. PRESENCE von meinem G-Tag...

Der wird einfach nie nicht mit einem (dem) Update versehen und gut

Danke für die Unterstützung!

Und: evtl. mal bzgl. OS-Updates etwas "vorsichtiger" sein...
(wobei ich nat. nicht sage: ja nicht updaten und ja Sicherheitslöcher offen lassen!! )

Gruß, Joachim

[RockThisParty]

Moin!

Ich bin beeindruckt von Eurer Energie und sage Lautstark DANKE für die ganze Forschungsarbeit!!! Leider kann ich da vom Zeitaufwand her lange nicht mithalten.
Mein Buster-Update auf Pi3B von gestern hat leider auch nichts geändert.

Bestätigen kann ich

Code Auswählen Erweitern

"Feb 13 17:23:12 Pi4 lepresenced[752]: [tid:1] main::bluetooth_scan_thread: Received unknown output: 'Set scan parameters failed: Connection timed out'!"

Als Ausgabe von lepresenced status. Leider hat mich das bei Web-Recherche auch noch nicht weitergebracht

Viele Grüße
Stefan

[micky0867]

Die beste Herangehensweise bei solchen Sachen ist es, das Ganze zu Fuß (also ohne lepresenced) zu probieren.
Deshalb erstmal den lepresenced stoppen (sudo systemctl stop lepresenced und dann mit ps -ef schauen, ob er tatsächlich beendet wurde)
Das ist nur temporär, beim nächsten Reboot wird lepresenced wieder automatisch gestartet.

sudo dmesg -C ausführen, um den  Kernel-Ringpuffers zu löschen
Dann prüfen, ob der Bluetoothdaemon läuft (sudo systemctl status bluetooth).
Dann mit "sudo hciconfig" schauen, welche Adapter überhaupt erkannt wurden.
Dann mit "sudo hcitool -i hci<x> lescan --duplicates" (das <x> durch die Nummer(n) eines Geräts aus hciconfig (s.o.) ersetzen) herausfinden, ob ein lescan überhaupt funktioniert
Und mal einen reset "sudo hcitool -i hci<X> reset" probieren.
sudo dmesg, um Meldungen aus dem Kernel-Ringpuffer anzuzeigen

Sollte sudo hcitool -i hcix lescan funktionieren, dann das auch mal als User fhem ohne sudo probieren.

Nachtrag, ggf muss dafür lsof nachinstalliert werden:
sudo lsof | grep HCI
Das bitte mehrmals ausführen!
Damit kann geprüft werden, wer alles auf die BT-Devices zugreift, es scheint ein Problem mit konkurrierenden Zugriffen zu geben.


Nachtrag 2
Es könnte sein, dass hcitool bei dir nicht mehr unterstützt wird. Siehe https://wiki.archlinux.org/index.php/Bluetooth#Deprecated_BlueZ_tools
Alternativ könnte bluetoothctl -natürlich mit anderer Syntax- benutzt werden.
Hier ein kurzes Beispiel, wie man z.B. für den Adapter hci1 die BT-Adresse ermittelt und anschließend in bluetoothctl für einen Scan benutzt.

Code Auswählen Erweitern


root@rp:~# hciconfig hci1
hci1: Type: Primary  Bus: USB
BD Address: 00:1A:7D:DA:71:0B  ACL MTU: 310:10  SCO MTU: 64:8
UP RUNNING
RX bytes:41211 acl:0 sco:0 events:1070 errors:0
TX bytes:1935 acl:0 sco:0 commands:119 errors:1

root@rp:~# bluetoothctl
Agent registered
[bluetooth]# select 00:1A:7D:DA:71:0B
[bluetooth]# scan on
Discovery started
[CHG] Controller 00:1A:7D:DA:71:0B Discovering: yes
[NEW] Device 7C:2F:80:C4:5A:D9 Gigaset G-tag
[NEW] Device D4:9D:C0:57:9C:61 [TV] Samsung 7 Series (70)
[CHG] Device D4:9D:C0:57:9C:61 RSSI: -96
[CHG] Device D4:9D:C0:57:9C:61 RSSI: -83
[CHG] Device D4:9D:C0:57:9C:61 ManufacturerData Key: 0x0075
[CHG] Device D4:9D:C0:57:9C:61 ManufacturerData Value:
  42 04 01 20 67 19 0d 00 00 01 46 00 00 00 00 00  B.. g.....F.....
  00 00 00 00 00 00 00 00                          ........       
[bluetooth]# scan off
Discovery stopped
[CHG] Controller 00:1A:7D:DA:71:0B Discovering: no
[CHG] Device D4:9D:C0:57:9C:61 RSSI is nil
[CHG] Device 7C:2F:80:C4:5A:D9 RSSI is nil

[RockThisParty]

Danke für die ausführliche Anleitung!

Code Auswählen Erweitern

hci0: Type: Primary  Bus: UART
BD Address: B8:27:EB:A8:9E:5C  ACL MTU: 1021:8  SCO MTU: 64:1
UP RUNNING
RX bytes:112643400 acl:139 sco:180 events:3495786 errors:0
TX bytes:51303 acl:1 sco:0 commands:4570 errors:0

pi@Pi4:~ $ sudo hcitool -i hci0 lescan --duplicates
Set scan parameters failed: Connection timed out
pi@Pi4:~ $ sudo hcitool -i hci0 reset
Unknown command - "reset"
pi@Pi4:~ $ sudo hcitool -i hci0 reset
Unknown command - "reset"
pi@Pi4:~ $ sudo dmesg
[86784.291160] Bluetooth: hci0: command 0x200b tx timeout

Wegen "Unknown command - reset" habe ich ersatzweise probiert:

Code Auswählen Erweitern

pi@Pi4:~ $ sudo hciconfig hci0 reset
pi@Pi4:~ $ sudo dmesg
[86784.291160] Bluetooth: hci0: command 0x200b tx timeout
[87073.572484] Bluetooth: hci0: Frame reassembly failed (-84)
[87073.572542] Bluetooth: hci0: Frame reassembly failed (-84)
[87073.572559] Bluetooth: hci0: Frame reassembly failed (-84)
[87073.572575] Bluetooth: hci0: Frame reassembly failed (-84)
[87073.572591] Bluetooth: hci0: Frame reassembly failed (-84)
[87073.572611] Bluetooth: hci0: Frame reassembly failed (-84)
[87073.572664] Bluetooth: hci0: Frame reassembly failed (-84)
[87073.572681] Bluetooth: hci0: Frame reassembly failed (-84)
[87073.572724] Bluetooth: hci0: Frame reassembly failed (-84)
[87073.572741] Bluetooth: hci0: Frame reassembly failed (-84)
[87073.572757] Bluetooth: hci0: Frame reassembly failed (-84)
[87075.651983] Bluetooth: hci0: command 0x1003 tx timeout

Das sieht für mich zwar nicht nach einem Erfolg aus, dafür funktioniert danach aber der lescan wieder.

Allerdings kann ich daraus nun leider nicht wirklich etwas lernen ... Vorübergehend läuft lepresenced wieder. Mal sehen wie lange.

Müsste man nun zyklisch einen BT-Reset durchführen?

[RockThisParty]

Lief ca. 5 Minuten 

[micky0867]

Ich hatte meinen ursprünglichen Post nochmal erweitert.
U.U. geht es mit hcitool gar nicht mehr vernüntig.

Das mit dem reset war ein Verdreher, es muss

Code Auswählen Erweitern

hciconfig hci0 reset
heissen

Mach auch mal den hier:

Code Auswählen Erweitern

sudo lsof | grep HCI

[RockThisParty]

Danke.

Code Auswählen Erweitern

pi@Pi4:~ $ sudo lsof | grep HCI
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
bluetooth   665                             root    5u     sock        0,8        0t0      18512 protocol: HCI
bluetooth   665                             root    8u     sock        0,8        0t0      18518 protocol: HCI
hcidump   14082                             root    3u     sock        0,8        0t0    1537993 protocol: HCI
hcitool   15955                             root    3u     sock        0,8        0t0    1616543 protocol: HCI


Andere Prozesse habe ich nicht gefunden.

Wenn ich lepresenced stoppe, bleiben die beiden "bluetooth" Prozesse übrig.

Konkurrierender Zugriff, ging mir auch schon durch den Kopf. Ich habe - weil der Raspi auch gleich eine Status-Anzeige am eigenen Touchdisplay macht - Raspberry OS mit Grafischer Oberfläche installiert. Da ist ja auch eine BT-Steuerung drin. Kann es sein, dass die dazwischenfunkt?

Ich habe die "bluetooth"-Prozesse (oder ist das nur einer?) mal gekillt und beobachte.

Dass hcitool deprecated ist, hatte ich auch irgendwo schon gesehen ...

Nachtrag: Nach einer Minute war "present" schon wieder weg

Code Auswählen Erweitern

pi@Pi4:~ $ sudo service lepresenced status
● lepresenced.service - lepresenced
   Loaded: loaded (/lib/systemd/system/lepresenced.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2021-02-14 20:08:57 CET; 2min 32s ago
  Process: 16427 ExecStartPre=/bin/sleep 10 (code=exited, status=0/SUCCESS)
Main PID: 16428 (lepresenced)
    Tasks: 5 (limit: 2062)
   CGroup: /system.slice/lepresenced.service
           ├─16428 /usr/bin/perl /usr/sbin/lepresenced --device hci0 --listenaddress 0.0.0.0 --listenport 5333 --loglevel LOG_WARNING
           ├─16441 hcidump -i hci0
           └─16442 hcitool -i hci0 lescan --duplicates

Feb 14 20:08:47 Pi4 systemd[1]: Starting lepresenced...
Feb 14 20:08:57 Pi4 systemd[1]: Started lepresenced.
Feb 14 20:08:57 Pi4 lepresenced[16428]: [tid:1] main::bluetooth_scan_thread: Received 'Invalid device: Network is down', resetting...
Feb 14 20:08:57 Pi4 lepresenced[16428]: [tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...

[micky0867]

Ich hatte hcidump gar nicht mehr auf dem Schirm.......
Es könnte sein, dass dadurch hcitool gestört wird....

Ich würde beim Aufruf von lepresenced

Code Auswählen Erweitern

--legacymode
mit angeben, um hcidump abzuschalten.

Der sollte dann auch bei dem lsof nicht mehr auftauchen.

[RockThisParty]

Danke!

Ich habe legacymode eingetragen. Es wird jetzt tatsächlich nur noch

Code Auswählen Erweitern

sudo lsof | grep HCI
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
hcitool   11153 
angezeigt. Es lief zwar so lange stabil, wie noch nie, das waren aber trotzdem nur leicht instabile 2 Stunden 

Status von lepresenced sagt jetzt

Code Auswählen Erweitern

pi@Pi4:~ $ sudo service lepresenced status
● lepresenced.service - lepresenced
   Loaded: loaded (/lib/systemd/system/lepresenced.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2021-02-14 22:43:01 CET; 10h ago
  Process: 20971 ExecStartPre=/bin/sleep 10 (code=exited, status=0/SUCCESS)
Main PID: 20974 (lepresenced)
    Tasks: 3 (limit: 2062)
   CGroup: /system.slice/lepresenced.service
           ├─11128 hcitool -i hci0 lescan --duplicates
           └─20974 /usr/bin/perl /usr/sbin/lepresenced --device hci0 --listenaddress 0.0.0.0 --listenport 5333 --loglevel LOG_WARNING --legacymode

Feb 15 08:46:16 Pi4 lepresenced[20974]: [tid:1] main::bluetooth_scan_thread: Received unknown output: 'Set scan parameters failed: Connection timed out'!
Feb 15 08:46:16 Pi4 lepresenced[20974]: [tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...
Feb 15 08:46:27 Pi4 lepresenced[20974]: [tid:1] main::bluetooth_scan_thread: Received unknown output: 'Set scan parameters failed: Connection timed out'!
Feb 15 08:46:27 Pi4 lepresenced[20974]: [tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...
Feb 15 08:46:38 Pi4 lepresenced[20974]: [tid:1] main::bluetooth_scan_thread: Received unknown output: 'Set scan parameters failed: Connection timed out'!
Feb 15 08:46:38 Pi4 lepresenced[20974]: [tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...
Feb 15 08:46:49 Pi4 lepresenced[20974]: [tid:1] main::bluetooth_scan_thread: Received unknown output: 'Set scan parameters failed: Connection timed out'!
Feb 15 08:46:49 Pi4 lepresenced[20974]: [tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...
Feb 15 08:47:00 Pi4 lepresenced[20974]: [tid:1] main::bluetooth_scan_thread: Received unknown output: 'Set scan parameters failed: Connection timed out'!
Feb 15 08:47:00 Pi4 lepresenced[20974]: [tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...


bluetoothctl habe ich gestern mal ganz kurz angetestet. Leider kommt die [bluetooth]# Eingabeaufforderung gar nicht erst, er bleibt ohne Fehlermeldung vorher hängen. Das schaue ich mir aber nach einem Neustart noch mal an.

[eurofinder]

Moin,

nach eine defekt musste ich leider mein System komplett von stretch auf buster mit 3b+ und pivccu3 mit RPI-RF-MOD umstellen - also ein Charly.
Für lepresenced mit G-Tags (lief bisher einwandfrei) nutze ich einen USB-Dongle.
Mir ist jetzt aufgefallen, dass wenn ich den Dongle mal vom Charly getrennt habe (fragt nicht warum, war aber notwendig) und ich den jetzt wieder damit verbinde, wird dieser nicht mehr erkannt, auch nicht nach einem Reboot.

Ich habe es dann mal mit einen aktuellen buster-lite-OS probiert. Gerät wird erlkannt. Dann abgezogen, neu gebootet, heruntergefahren, neu angesteckt und neu gebootet. Gerät wird nicht mehr erkannt.

Wie ist das möglich?
lsusb mit Gerät:

Code Auswählen Erweitern

root@raspberrypi:/home/pi# lsusb
Bus 001 Device 004: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 001 Device 005: ID 0424:7800 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


lsusb ohne USB-Dongle:

Code Auswählen Erweitern

Bus 001 Device 005: ID 0424:7800 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


Wie bekomme ich den USB-Dongle wieder zum Laufen?

Sofern weitere Infos benötigt werden, reiche ich diese gerne nach.

Gruß und ein schönes Wochenende
eurofinder

[RockThisParty]

Moin!

Ich habe gestern Abend den Raspi auf aktuellen Stand (apt full-upgrade) gebracht ... seit dem läuft lepresenced ohne Fehler durch. Sind erst 14 Stunden ... aber das ist schon 7x länger als ich je hatte. Drückt mal die Daumen  oder berichtet, ob es bei Euch auch besser geworden ist.

Viele Grüße
Stefan