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

[StephanFHEM]

In BT5 gibt es eine Funktion LE Coded PHY die die Reichweite vervierfacht.
Aber soweit ich inzwischen rausgefunden habe funktioniert es nicht mit dem Pi4 weil dort nur die minimal BT5 Version implementiert ist...
Kennst du ansonsten Tags die eine höhere Reichweite haben als die G-Tags? Ich war der Meinung, dass die schon Class 1 sind.

[StephanFHEM]

Übrigens noch einen Hinweis auf einen Fehler im Wiki: dort steht, dass bei Collectord und Lepresenced FHEM auf allen Instanzen laufen muss. Das stimmt so nicht. FHEM ist nur auf dem System erforderlich auf dem Collectord läuft. Auf den anderen nicht. Könnte das noch jemand anpassen? Das erspart Neuen viel Arbeit

[mumpitzstuff]

https://www.techstage.de/ratgeber/Kaufberatung-Vergleichstest-Bluetooth-Schluesselfinder-3733724.html

Tile Pro soll auch laut Heise eine hohe Reichweite haben. Für die Benutzung von deren App braucht man zwar ein Abo, aber das braucht man mit Fhem ja zum Glück nicht.

[StephanFHEM]

Super.... probiere ich mal aus. Hab jetzt erst mal mit PIZeros meine BT Erkennung erweitert

[Martin Fischer]

Übrigens noch einen Hinweis auf einen Fehler im Wiki: dort steht, dass bei Collectord und Lepresenced FHEM auf allen Instanzen laufen muss. Das stimmt so nicht. FHEM ist nur auf dem System erforderlich auf dem Collectord läuft. Auf den anderen nicht. Könnte das noch jemand anpassen? Das erspart Neuen viel Arbeit

Das ist so nicht richtig. Sowohl für presenced als auch lepresenced erfordert collectord keine FHEM Instanz auf dem selben Host. Das entsprechende FHEM Device zeigt via IP auf den entsprechenden collectord Host, der demnach auf einem beliebigen, vom FHEM Host ereichbaren, System laufen kann. Die Angabe von 127.0.0.1 bedeutet nicht zwangsläufig, dass das auch unbedingt auf localhost laufen muss.

[StephanFHEM]

Da hast du natürlich recht! Im Wiki steht aber, dass auf allen beteiligten Systemen FHEM laufen muss mit den entsprechenden Definitionen. Ich wollte nur verdeutlichen, dass weiterhin nur ein FHEM laufen braucht. Das muss natürlich nicht der Collectord-Server sein.

[StephanFHEM]

https://www.techstage.de/ratgeber/Kaufberatung-Vergleichstest-Bluetooth-Schluesselfinder-3733724.html

Tile Pro soll auch laut Heise eine hohe Reichweite haben. Für die Benutzung von deren App braucht man zwar ein Abo, aber das braucht man mit Fhem ja zum Glück nicht.

Hab den jetzt mal ausprobiert. Dummerweise habe ich ihn zuerst mit der App genutzt und dann über lescan gesucht. Das war leider nicht mehr möglich. Der TILE wird selbst dann nicht gefunden wenn das Handy im Flugmodus ist oder die App ausgeschaltet. Das war bei den G-Tags anders. Da man das Pairing anscheinend auch nicht Rückgängig machen kann wird der TILE Pro wohl eher nicht mit FHEM nutzbar sein

[PatrickR]

Hi!

https://www.techstage.de/ratgeber/Kaufberatung-Vergleichstest-Bluetooth-Schluesselfinder-3733724.html

Tile Pro soll auch laut Heise eine hohe Reichweite haben. Für die Benutzung von deren App braucht man zwar ein Abo, aber das braucht man mit Fhem ja zum Glück nicht.

Hatte mal testweise ein Tile bestellt. Erkennbar ist es leider nur für eine begrenzte Zeit wenn man den Knopf drückt. Das Pairen habe ich auf die Schnelle leider auch nicht hinbekommen:

Code Auswählen Erweitern


[CHG] Controller XXXX Discovering: no
[bluetooth]#
[bluetooth]# discoverable on
Changing discoverable on succeeded
[CHG] Controller XXXX Discoverable: yes
[bluetooth]# pairable on
Changing pairable on succeeded
[bluetooth]# agent on
Agent is already registered
[bluetooth]# default-agent
Default agent request successful
[bluetooth]# pair YYYY
Attempting to pair with YYYY
[CHG] Device YYYY Connected: yes
Failed to pair: org.bluez.Error.AuthenticationFailed
[CHG] Device YYYY Connected: no


Patrick

[StephanFHEM]

Danke für die Info. Das deckt sich mit meiner Erfahrung. Dann geht der Tile Pro zurück. Schade eigentlich, da er sehr wertig verarbeitet war und einen guten Eindruck gemacht hat

[Steffen]

Hi!

Hatte mal testweise ein Tile bestellt. Erkennbar ist es leider nur für eine begrenzte Zeit wenn man den Knopf drückt. Das Pairen habe ich auf die Schnelle leider auch nicht hinbekommen:

Code Auswählen Erweitern


[CHG] Controller XXXX Discovering: no
[bluetooth]#
[bluetooth]# discoverable on
Changing discoverable on succeeded
[CHG] Controller XXXX Discoverable: yes
[bluetooth]# pairable on
Changing pairable on succeeded
[bluetooth]# agent on
Agent is already registered
[bluetooth]# default-agent
Default agent request successful
[bluetooth]# pair YYYY
Attempting to pair with YYYY
[CHG] Device YYYY Connected: yes
Failed to pair: org.bluez.Error.AuthenticationFailed
[CHG] Device YYYY Connected: no


Patrick

hast du es wirklich nicht mehr hinbekommen die Verbindungen zu Fhem?

Ich suche einen einen besseren Bluetooth Tag mit der Reichweite als meine Gigaset G-Tag.

[_fhemuser_]

Hallo,

ich möchte mit einem Raspberry4 mit dem internen Bluetooth Modul auch gerne BLE Tags erkennen und auf einem anderen Raspberry3 anzeigen lassen. Auf beiden Raspberries läuft Debian Buster.

Dazu habe ich auf dem Raspberry4 den lepresenced laufen und greife von dem Raspberry3 über fhem mit
define BleTag PRESENCE lan-bluetooth E8:12:23:56:78:90 IP.DES.RA3:5333 180
attr BleTag bluetoothHciDevice hci0
auf die Ausgabe von lepresenced zu.

Installiert ist auf den 4er: https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/PRESENCE/deb/lepresenced-0.9-1.deb

Aber der Deamon arbeitet nur sehr kurz. Manchmal sogar über eine Stunde. Über einen Crontab Eintrag lasse ich den Service schon stündlich neu starten.

Über die Statusabfrage erhalte ich dann zB:
sudo service lepresenced status
● lepresenced.service - lepresenced
   Loaded: loaded (/lib/systemd/system/lepresenced.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2020-04-04 10:03:11 CEST; 10min ago
  Process: 30699 ExecStartPre=/bin/sleep 10 (code=exited, status=0/SUCCESS)
Main PID: 30708 (lepresenced)
    Tasks: 5 (limit: 1171)
   Memory: 9.3M
   CGroup: /system.slice/lepresenced.service
           ├─30708 /usr/bin/perl /usr/sbin/lepresenced --device hci0 --listenaddress 0.0.0.0 --listenport 5333 --loglevel LOG_WARNING
           ├─30725 hcidump -i hci0
           └─30726 hcitool -i hci0 lescan --duplicates

Apr 04 10:03:01 raspi4 systemd[1]: Starting lepresenced...
Apr 04 10:03:11 raspi4 systemd[1]: Started lepresenced.
Apr 04 10:03:12 raspi4 lepresenced[30708]: [tid:1] main::bluetooth_scan_thread: Received 'Set scan parameters failed: Input/output error', resetting...
Apr 04 10:03:12 raspi4 lepresenced[30708]: [tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...

Wie kann ich es erreichen, dass die BLE Erkennung dauerhaft funktioniert.

Vielen Dank und bleibt alle Gesund
_fhemuser_

[PatrickR]

Hi!

Apr 04 10:03:01 raspi4 systemd[1]: Starting lepresenced...
Apr 04 10:03:11 raspi4 systemd[1]: Started lepresenced.
Apr 04 10:03:12 raspi4 lepresenced[30708]: [tid:1] main::bluetooth_scan_thread: Received 'Set scan parameters failed: Input/output error', resetting...
Apr 04 10:03:12 raspi4 lepresenced[30708]: [tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...

Wie kann ich es erreichen, dass die BLE Erkennung dauerhaft funktioniert.

Dem Log nach zu urteilen dürfte es überhaupt nicht funktionieren. Poste doch mal bitte ein Log mit LOG_DEBUG (/etc/default/lepresenced anpassen.).

Ansonsten wird leider sehr oft berichtet, dass es mit dem internen Bluetooth-Modul des RPi4 Probleme gibt. Der Ansatz ist üblicherweise ein billiger USB-Dongle.

Patrick

[_fhemuser_]

Vielen Dank für die schnelle Antwort.

Ich werden das Log aktivieren und das Ergenis hier posten

VG
_fhemuser_

[RoB81]

Hallo,

ich hoffe ich darf mich mit meinem Anliegen hier an den Thread dran hängen.

Ich nutze in FHEM die Anwesenheitserkennung mittels lepresence (0.9.1) und den Blutetoothtags von Gigaset.
Ich habe dabei nach einem Neustart des RPI3 immer wieder das Problem, dass in Fhem (presence als lan-bluetooth) meine G-Tags nach einiger Zeit (dem voreingestellten Intervall = 120 sek.) als absent angezeigt werden. Wenn ich dann auf der Console meines RPI3 ein sudo hcitool lescan ausführe, werden die Tags für die nächsten 2 Minuten wieder als present angezeigt. Danach wechseln Sie dann wieder auf absent. Ich bin leider ein totaler Noob und schaffe es lediglich die im Netz verfügbaren step-by-step Anleitungen abzuarbeiten. Daher habe ich selber auch wenig Möglichkeiten auf Fehlersuche zu gehen.

Es scheint sich aber, meiner Auffassung nach um eine Art "Wackelkontakt" zu handeln. Denn immer wenn ich lescan manuell ausführe werden die Tags für 2 min. als present angezeigt. Wenn ich den Pi ein paar Mal neustarte, klappt es dann sogar auch manchmal dauerhaft wieder bis zum nächsten Neustart. Also aktuell habe ich den Pi ein paar Mal neugestartet und nun werden meine Tags wieder ordnungsgemäß als present angezeigt (seit immerhin 20 min.). Damit scheint es nun wieder zu Laufen, bis zum nächsten Neustart des Pis.

Ist dieser Fehler bekannt? Gibt es hierfür einen Lösungsansatz? Wie kann ich dem Fehler auf die Spur kommen? Es wäre sehr nett, wenn man mir hier helfen würde. Ich liefere dafür auch gerne aller erforderlichen Informationen, aber ich bräuchte dafür bitte genaue Anweisungen, welche Befehle ich ausführen muss, damit ich die entsprechenden Logs bzw. Ausgaben erzeugen kann.

Vielen Dank schon mal vorab.

[PatrickR]

Hi!

Ist dieser Fehler bekannt? Gibt es hierfür einen Lösungsansatz? Wie kann ich dem Fehler auf die Spur kommen? Es wäre sehr nett, wenn man mir hier helfen würde. Ich liefere dafür auch gerne aller erforderlichen Informationen, aber ich bräuchte dafür bitte genaue Anweisungen, welche Befehle ich ausführen muss, damit ich die entsprechenden Logs bzw. Ausgaben erzeugen kann.

Es gibt leider eine Reihe von Problemen, die sich nur schwer eingrenzen lassen. Kollisionen mit anderen Programmen/Modulen/Skripten, die Bluetooth verwenden gehören dazu. Wenn Du so etwas benutzt, dann lohnt es sich, das mal testweise abzustellen. lepresenced investiert einigen Aufwand, um Kollisionen zu erkennen und sich durchzusetzen (z. B. durch Zurücksetzen des Bluetooth-Geräts). Wenn das nicht der Fall ist: Manche(!) Leute haben Probleme mit dem Onboard-Bluetooth-Modul und konnten sie beseitigen, indem sie einen externen Bluetooth-Dongle angesteckt haben (Empfehlungen solltest Du hier im Forum bekommen.).

Um das Problem näher einzugrenzen:
Stelle doch mal bitte in /etc/default/lepresenced den SYSLOG_LEVEL auf LOG_DEBUG und poste einen großzügigen Ausschnitt (grep lepresenced /var/log/syslog) vom Start bis zum Zeitpunkt des Problems. Achtung: Mit der Einstellung wird ziemlich viel ins Syslog geschrieben, was bei SD-Karten-Systemen nicht gerade die Lebensdauer verlängert.

Patrick