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

[Heimweh]

Hallo. Ich nutze einen BCM20702 USB Dongle an einem Intel NUC. Meine Lepresence Version ist 0.9.
Derzeit habe ich 2 (China) Beacons - diese liegen ca. 1m vom Dongle entfernt und werden auch erkannt.
Wenn ich aber nun einen Beacon "mitnehme" - werden beide als absent angezeigt. Mach ich dann von unterwegs aus einen kompletten
Systemneustart - passt wieder alles. Einer ist absent und einer present. Woran könnte es liegen dass die States nicht richtig angezeigt werden?

[Eistee]

Hi,

bei mir funktionierte Bluetooth vom PI 3B nicht mehr seit ich auf Raspbian Buster umgestellt habe. Das interne Bluetooth Modul arbeitet nicht mehr richtig da der Treiber scheinbar für den PI4 geändert wurde. Das ist ein bekanntes Problem im neuesten Raspbian Buster (https://github.com/raspberrypi/firmware/issues/1150). Die Problemlösungsvorschläge dort haben bei mir nicht geholfen. Raspbian Strech lief sehr zuverlässig. Den Fehler des Bluetooth Moduls sieht man wenn man dmesg ausführt auf dem PI.

Problemlösung: Ich hab das interne Bluetooth deaktiviert und ein USB BLE Dongle in den PI gesteckt. Das funktioniert nun wieder.

Vielleicht hilft das dem ein oder anderen.

LG Alina

[Steffen]

Hallo!

Ich habe zwar die gleiche frage schon mal im XiaomiBTLESens Forum angesprochen aber leider keine Antwort erhalten, deswegen hier nochmal der Versuch...

Mir ist was in letzter Zeit aufgefallen, das wollte ich mal hier ansprechen und vielleicht hat jemand einen Rat dazu.

Ich nutze eigentlich seit langer Zeit diese Modul hier zusammen mit dem "lepresenced/collectord" Modul, jetzt ist mir aufgefallen
das wenn das "XiaomiBTLESens" Modul den Sensor nicht erreichen kann also eine "Error" anzeigt, exakt auch zu der Zeit bricht das "PRESENCE" Modul
ein und keiner meiner Bluetooth Tags werden mehr gefunden.

Wenn ich dann "XiaomiBTLESens" auf "attr Disable 1" setzte und "lepresenced Service" per Ssh auf dem Pi3 neustarte, findet er meine Bluetooth Tags wieder sofort.

Ist es möglich das beide zusammen Arbeiten können oder muss dann extra das "XiaomiBTLESens" auf ein sagen wir PiZero ausgelagert werden?!?

Mfg Steffen

[Heimweh]

Hallo. Ich nutze einen BCM20702 USB .......

Update: ich habe mir nun (Tip hier aus dem Forum) den CSL Dongle bestellt. Mit diese funktioniert es, nur ist die Reichweite deutlich gesunken....

[Eistee]

... CSL Dongle ... Reichweite deutlich gesunken....

Welchen hast du denn?
Wenn ich so bei amazon gucke haben die CSL doch nur 10m Reichweite. Es gibt auch BLE USB Dongels mit 100m Reichweite.

[Heimweh]

Welchen hast du denn?
Wenn ich so bei amazon gucke haben die CSL doch nur 10m Reichweite. Es gibt auch BLE USB Dongels mit 100m Reichweite.

Mit den 10m hast Du recht. Ich habe jetzt den hier:

https://www.amazon.de/gp/product/B00LSGUBLI/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1

Hast Du mir mal den link zu dem 100m Dongle? 

Und den folgenden hatte ich vorher, weil hier öfters mal der BCM20702 genannt wurde:

https://www.amazon.de/gp/product/B00LSGUBLI/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1

Bin noch immer nicht ganz zufrieden...

[Eistee]

Hast Du mir mal den link zu dem 100m Dongle?

https://www.amazon.de/LogiLink-BT0015-Bluetooth-Adapter-Windows/dp/B0096Y2HFW

[Steffen]

Guten Morgen,

Ich habe auch das Problem auf einem RPI3b+ das in lepresenced die Devices irgendwann nur noch den state "absent" erhalten und nach einem restart von lepresenced ihren State auf  wieder auf "present" wechseln.

Code Auswählen Erweitern


pi@RiessHomeServer:/etc/rsyslog.d $ sudo service lepresenced status
● lepresenced.service - lepresenced
   Loaded: loaded (/lib/systemd/system/lepresenced.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2019-09-29 07:45:33 CEST; 5s ago
  Process: 3595 ExecStartPre=/bin/sleep 10 (code=exited, status=0/SUCCESS)
Main PID: 3604 (lepresenced)
    Tasks: 5 (limit: 2200)
   Memory: 9.5M
   CGroup: /system.slice/lepresenced.service
           ├─3604 /usr/bin/perl /usr/sbin/lepresenced --device hci0 --listenaddress 0.0.0.0 --listenport 5333 --loglevel LOG_WARNING
           ├─3618 hcidump -i hci0
           └─3626 hcitool -i hci0 lescan --duplicates

Sep 29 07:45:23 RiessHomeServer systemd[1]: Starting lepresenced...
Sep 29 07:45:33 RiessHomeServer systemd[1]: Started lepresenced.
Sep 29 07:45:33 RiessHomeServer lepresenced[3604]: [tid:1] main::bluetooth_scan_thread: Received 'Set scan parameters failed: Input/output error', resetting...
Sep 29 07:45:33 RiessHomeServer lepresenced[3604]: [tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...


desweiteren habe ich diese Log Einträge:

Code Auswählen Erweitern


Sep 29 07:52:48 RiessHomeServer kernel: bt_err_ratelimited: 2 callbacks suppressed
Sep 29 07:52:48 RiessHomeServer kernel: Bluetooth: hci0: advertising data len corrected
Sep 29 07:52:48 RiessHomeServer kernel: Bluetooth: hci0: advertising data len corrected
Sep 29 07:52:48 RiessHomeServer kernel: Bluetooth: hci0: advertising data len corrected
Sep 29 07:52:49 RiessHomeServer kernel: Bluetooth: hci0: advertising data len corrected
Sep 29 07:52:50 RiessHomeServer kernel: Bluetooth: hci0: advertising data len corrected
Sep 29 07:52:50 RiessHomeServer kernel: Bluetooth: hci0: advertising data len corrected
Sep 29 07:52:51 RiessHomeServer kernel: Bluetooth: hci0: advertising data len corrected
Sep 29 07:52:51 RiessHomeServer kernel: Bluetooth: hci0: advertising data len corrected
Sep 29 07:52:52 RiessHomeServer kernel: Bluetooth: hci0: advertising data len corrected
Sep 29 07:52:52 RiessHomeServer kernel: Bluetooth: hci0: advertising data len corrected


habe hier im Forum was dazu gefunden aber das klappt bei mir irgendwie auch nicht und die Einträge werden weiter geschrieben:

Code Auswählen Erweitern


cat 01-blocklist.conf
:msg,contains,"RiessHomeServer kernel: Bluetooth: hci0: advertising data len corrected" ~
:msg,contains,"Bluetooth: hci0 advertising data len corrected" ~
:msg,contains,"Bluetooth: hci0 advertising data length corrected" ~
:msg,contains,"bt_err_ratelimited:" ~
:msg,contains,"Bluetooth: hci0: advertising data len corrected" ~


das was ja in diesem Punkt nervt ist, das der state auf "absent" geht und nicht auf ein "Error" oder "Disconnect" das man dann wüsste das der Dienst nicht läuft.

Mfg Steffen

[Steffen]

Hallo!

Gibt es hier wirklich kein Support mehr dazu???

Bei mir ist das inzwischen auf 3 Systemen so und eine Vernüftige Ab und Anwesendheits erkennung ist nicht mehr möglich

Ich hoffe man kann sich vielleicht doch diesen Fehler annehmen...

Mfg Steffen

[Gasmast3r]

Hallo ich habe viel gehört das, das interne Bluetooth vom Pi3 nicht gut läuft.
Falls noch nicht passiert besorge dir ein USB dongle und schalte den internen Bluetooth Stick ab.

Habe jetzt nicht alles gelesen, habe selber 2 Zero Pi W am laufen die keinerlei Probleme machen

Gesendet mit Tapatalk

[ToKa]

Hallo zusammen,

ich hatte das gleiche Problem nun auch schon seit etlichen Wochen nach einem Betriebssystem-Update. Bei der Suche nach einer Lösung bin ich auf einen Hinweis gestoßen, der zumindest seit mehreren Tagen zu einem stabilen Verhalten mit meinen G-Tags geführt hat.

Die Lösung sieht vor in der Dateu /usr/bin/btuart in der Zeile 23 die Baud-Rate auf 115200 abzuändern:

Code Auswählen Erweitern

#!/bin/sh

HCIATTACH=/usr/bin/hciattach
if grep -q "Pi 4" /proc/device-tree/model; then
  BDADDR=
else
  SERIAL=`cat /proc/device-tree/serial-number | cut -c9-`
  B1=`echo $SERIAL | cut -c3-4`
  B2=`echo $SERIAL | cut -c5-6`
  B3=`echo $SERIAL | cut -c7-8`
  BDADDR=`printf b8:27:eb:%02x:%02x:%02x $((0x$B1 ^ 0xaa)) $((0x$B2 ^ 0xaa)) $((0x$B3 ^ 0xaa))`
fi

uart0="`cat /proc/device-tree/aliases/uart0`"
serial1="`cat /proc/device-tree/aliases/serial1`"

if [ "$uart0" = "$serial1" ] ; then
uart0_pins="`wc -c /proc/device-tree/soc/gpio@7e200000/uart0_pins/brcm\,pins | cut -f 1 -d ' '`"
if [ "$uart0_pins" = "16" ] ; then
$HCIATTACH /dev/serial1 bcm43xx 3000000 flow - $BDADDR
else
# von 921600 auf 115200 geändert
$HCIATTACH /dev/serial1 bcm43xx 115200 noflow - $BDADDR
fi
else
$HCIATTACH /dev/serial1 bcm43xx 460800 noflow - $BDADDR
fi

Für den Zweck die G-Tags anzusprechen, scheint die Rate absolut auszureichen.

Beste Grüße
Torsten

[Steffen]

Hallo zusammen,

ich hatte das gleiche Problem nun auch schon seit etlichen Wochen nach einem Betriebssystem-Update. Bei der Suche nach einer Lösung bin ich auf einen Hinweis gestoßen, der zumindest seit mehreren Tagen zu einem stabilen Verhalten mit meinen G-Tags geführt hat.

Die Lösung sieht vor in der Dateu /usr/bin/btuart in der Zeile 23 die Baud-Rate auf 115200 abzuändern:

Code Auswählen Erweitern

#!/bin/sh

HCIATTACH=/usr/bin/hciattach
if grep -q "Pi 4" /proc/device-tree/model; then
  BDADDR=
else
  SERIAL=`cat /proc/device-tree/serial-number | cut -c9-`
  B1=`echo $SERIAL | cut -c3-4`
  B2=`echo $SERIAL | cut -c5-6`
  B3=`echo $SERIAL | cut -c7-8`
  BDADDR=`printf b8:27:eb:%02x:%02x:%02x $((0x$B1 ^ 0xaa)) $((0x$B2 ^ 0xaa)) $((0x$B3 ^ 0xaa))`
fi

uart0="`cat /proc/device-tree/aliases/uart0`"
serial1="`cat /proc/device-tree/aliases/serial1`"

if [ "$uart0" = "$serial1" ] ; then
uart0_pins="`wc -c /proc/device-tree/soc/gpio@7e200000/uart0_pins/brcm\,pins | cut -f 1 -d ' '`"
if [ "$uart0_pins" = "16" ] ; then
$HCIATTACH /dev/serial1 bcm43xx 3000000 flow - $BDADDR
else
# von 921600 auf 115200 geändert
$HCIATTACH /dev/serial1 bcm43xx 115200 noflow - $BDADDR
fi
else
$HCIATTACH /dev/serial1 bcm43xx 460800 noflow - $BDADDR
fi

Für den Zweck die G-Tags anzusprechen, scheint die Rate absolut auszureichen.

Beste Grüße
Torsten

Nach großer Hoffnung kam doch wieder nur die entäuschung,
auf 3 Systemen(RPI3b+) mit Buster hat dieser Fix leider auch nicht geholfen  


Ich hoffe sehr das es hier jemand gibt der sich dem Problem hier  vielleicht auch noch mit annehmen kann, denn ich würde sehr ungern immer erst ein Bluetooth Stick jedesmal dazu kaufen.

Mfg Steffen

[Gasmast3r]

Hy hast du das den mal ausprobiert, mit nem Stick?
Wenn der interne Chip nicht laufen will dann bringt es halt nicht viel, so ein dongle bekommt man bei ebay ab 1€.

Ist zwar doof bei nem Pi3 extra ein Bluetooth Dongle zu kaufen aber wenn es nicht anders geht, muss es halt sein.

Gesendet mit Tapatalk

[Steffen]

Hallo!

Ich habe es noch nicht mit einem Stick getestet, da ich eigentlich kein Freund bin Probleme "weg zu kaufen". Ok manchmal geht es halt nicht anders aber da dieses Problem ja nun schon 3 Laufende System und dadurch auch alle zukünftigen suche ich noch nach einer Lösung.

Ich habe auf einem der RPi3b+ ein "attr bluetoothHciDevice
hci0" angehangen und seit dem läuft es Stabil aber auf den anderen wieder nicht?!?

Wenn es wenigstens ein Möglichkeit geben würde das man erkennen könnte ob der Dienst läuft, dann könnte man ihn ja wieder neu starten lassen, denn dann klappt die erkennung wieder gut?!

Mfg Steffen

[Eistee]

Es gibt doch die kostenlose Lösung. Einfach bei Strech bleiben denn das Bluetooth Problem gibt es nur bei Buster. Unter Buster gibt es halt nur die Möglichkeit ein externes Bluetooth Modul anzuschließen oder die Baudrate zu ändern.