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

Begonnen von stiefl, 18 August 2017, 13:00:51

Vorheriges Thema - Nächstes Thema

volst

Nachtrag: seit der Installation von broadcom-bt-firmware-10.1.0.1115.deb ist das Problem bei mir behoben. Die Erkennung läuft mittlerweile seit einer Woche stabil.

RockThisParty

#181
Moin!

Ich versuche es mal in diesem nicht mehr ganz taufrischen Thread, da er inhaltlich prima passt.
Da mir die Anwesenheitserkennung mit Fritz!/WLAN zu ungenau bzw. zu langsam war, bastele ich seit einer Weile mit Bluetooth herum und habe mir letztlich Tags bestellt.

Die Einrichtung mit LEPRESENCED war ziemlich problemlos. Leider wird nach kurzer Zeit das GTag dauerhaft absent angezeigt.

Hardware

  • Raspberry Pi 3 Model B Plus Rev 1.3
  • internes Bluetooth

Log mit Verbose 5
2021.02.09 08:37:26 5: PRESENCE (gTagSchwarz) - received data: absence;rssi=unreachable;model=lan-lepresenced;daemon=lepresenced V0.93

Device-List
Internals:
   ADDRESS    58:9E:C6:0E:F3:88
   CFGFN     
   DEF        lan-bluetooth 58:9E:C6:0E:F3:88 127.0.0.1:5333 60
   DeviceName 127.0.0.1:5333
   FD         16
   FUUID      6021b4f1-f33f-d7f8-1c7a-a202601a3e60bd37
   INTERVAL_NORMAL 60
   INTERVAL_PRESENT 60
   MODE       lan-bluetooth
   NAME       gTagSchwarz
   NOTIFYDEV  global
   NR         371
   NTFY_ORDER 50-gTagSchwarz
   PARTIAL   
   STATE      absent
   TYPE       PRESENCE
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1612857086.24221
           VALUE      absent
   READINGS:
     2021-02-08 23:02:26   command_accepted yes
     2021-02-09 08:51:26   daemon          lepresenced V0.93
     2021-02-08 23:53:26   device_name     Gigaset G-tag
     2021-02-09 08:51:26   model           lan-lepresenced
     2021-02-09 08:51:26   presence        absent
     2021-02-09 08:51:26   rssi            unreachable
     2021-02-09 08:51:26   state           absent
   helper:
     CURRENT_STATE present
     CURRENT_TIMEOUT normal
Attributes:
   DbLogInclude state
   room       Start,Zentral
   verbose    5


So richtig die ultimative Lösung habe ich aus diversen Foren-Threads noch nicht gefunden ... vielleicht könnt Ihr mir mit ein paar Einsteigerfragen weiterhelfen:

  • Ich habe oft gelesen, dass mit RPI3 und internem Bluetooth die Erkennung unzuverlässig läuft. Gilt das auch für RPI3B?
  • Wenn der RPI das Problem sein sollte: ist RPI4 besser?
  • Wenn der RPI das Problem sein sollte: ist RPI4 besser?
  • Und mal leider ziemlich Linux-DAU: Wie starte ich HCITOOL neu?
  • Wie starte/ stoppe ich LEPRESENCED?
  • Ist es richtig, dass "hcitool lescan" auf der Kommandozeile nicht nutzbar ist, wenn LEPRESENCED installiert ist? Ich bekomme seitdem immer nur "Set scan parameters failed: Connection timed out" Trotzdem hatte ich für mindestens eine Stunde den GTag in FHEM als present.

Nachtrag:

  • bluez-hcidump ist schon die neueste Version (5.50-1.2~deb10u1+rpt2).

Vielen Dank im Voraus!
Viele Grüße
Stefan

MadMax-FHEM

#182
Seit ein paar Tagen habe ich das Problem auch.

Lief zuvor ca. 1 Jahr (+) sehr gut.

Evtl. (bzw. halte ich das so) mit einem Update vom PI!?

Wie aktuell bist du?
Welches System?

EDIT: 2x PI3 (1x das eigentliche System und 1x "Testsystem für das BT-Problem") Buster aktuell (das eigentliche System hat noch deCONZ / das Testsystem hat nichts außer "frisches" Buster und leprecensed + "Abhängigkeiten")...


Wenn ich den leprecensed Service neu starte geht es wieder (eine Weile): sudo service lepresenced restart

Ich habe auch mal einen 2ten PI aufgesetzt, um auszuschließen, dass es das interne BT Modul ist bzw. das halt "kaputt" ist...

War schon drauf und dran einen BT-Stick zu bestellen...

Aktuell (seit gestern) läuft es zumindest mal einen Tag+ durch.

Also beide...

Es gab aber gestern oder so noch mal ein Update (aber eigentlich nichts mit BT) für den PI...

Ich habe auch die Tipps durch: sudo hcitool hci0 down/up usw. Hat aber nicht geholfen...
EDIT: nach Service-Restart geht es sofort wieder...

Aktuell schaue ich wie ich das mit dem Service Restart automatisieren kann OHNE, dass meine Routinen bei "presence" loslaufen.

Weil nach dem Service-Restart ist der GTag (nat.) wieder present (davor disconnected bzw. presence ist "absent" -> und notify/DOIF etc. würden ja wieder loslaufen)...

Nicht schön aber aktuell habe ich keine andere "Lösung"... :-\


Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Jamo

Hallo Joachim,
ich habe die Erfahrung gemacht, dass das interne BT immer Probleme macht, egal auf welchem Raspberry.
Seitdem ich mir externe BT dongles angeschafft habe, läufts problemlos rund. Das wäre mein Tip an Dich,
auch nach deiner Fehlerbeschreibung 'mal gehts und mal gehts nicht'.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

MadMax-FHEM

#184
@Jamo: ja drüber nachgedacht hatte ich auch schon.

Kann aber (bis JETZT) nichts negatives bzgl. BT und PI sagen (also nicht wirklich nachvollziehen, dass da "alle schimpfen")...
...ich habe einen PI ZeroW mit bis zu 10 BT FlowerSense laufen: keine Probleme (aber auch keine Updates ;) )...

Und auch der PI3 (mit deCONZ) lief problemlos über ein Jahr.

Erst seit einem der letzten Updates gibt es Probleme...
Zufall?
(Ich werde mal einen Test-PI mit "älterem" Buster aufsetzen / mal sehen)

Aber mal sehen, vielleicht gebe ich einem externen USB-BT eine Chance...

Frage: was muss ich tun, damit dieser statt dem internen genommen wird? Nur per config.txt und Overlay das interne BT deaktivieren?

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

RockThisParty

Danke für die schnellen Antworten.

System ist Raspberry OS, sollte komplett aktuell sein. Habe gestern noch update / upgrade durchgeführt.

lepresencd restart bringt bei mir leider nichts  :'(

Müsste ich den GTag mit dem Pi3 koppeln? Ich habe an verschiedenen Stellen gefunden, dass die Dinger sonst nicht dauerhaft senden, aber an anderer Stelle, dass sie nicht mehr senden, wenn sie mit der App gekoppelt sind?

Ein Pi4, den ich für anderes nutze sieht den GTag jedenfalls beim einzeln ausgelösten LESCAN, aber das könnte ja auch mit anderen Mechanismen zusammenhängen?

Wenn es ein externer Dongle sein müsste: Welcher Typ hat sich denn bewährt?

Viele Grüße
Stefan


MadMax-FHEM

#186
Du musst nichts pairen, zumindest musste ich nichts pairen.

Nur auf einem PI das leprecensed.deb installieren und vorher die Abhängigkeiten, meine Notizen:

Zitat
sudo apt-get install libnet-server-perl
sudo apt-get install bluez-hcidump
sudo dpkg -i lepresenced-0.9-1.deb

Bei Problemen:
sudo apt-get --fix-broken install

Und dann eben das PRESENCE Device in fhem mit Angabe der IP des "BT-PI" und der MAC des BT-Tags.
Hast du beides auf einem PI laufen?

Weil soweit mir bekannt ist leprecensed für lan-bt, also auf einem läuft fhem und auf einem anderen wird BT gemacht...
Ob das auch bei "localhost" geht: keine Ahnung...

Und OS aktuell ist nur eine halbe Aussage... ;)
Weil auch ein Stretch kann/könnte aktuell sein ist aber an sich schon "veraltet" ;)

Bzgl. BT-Dongle: da ich noch keinen habe, kann ich nichts sagen ;)  Ich habe jetzt einfach mal einen bestellt wo Raspberry PI und Linux mit dabei steht... Mal sehen...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

RockThisParty

Hi!

Nee  ;) ist schon Buster. Ich habe vor 6 Wochen das komplette System neu aufgesetzt.

Ich hab das FHEM-log noch mal geprüft. Der Wechsel von present auf absent kam rund 45 Minuten nachdem alle Raspi-Updates durch, das System neu gestartet und das FHEM-Device eingerichtet war.

Ich habe gerade den Raspi neu gestartet und noch ein zweites GTag definiert. Für den Moment sind beide auf "present".

Das spricht zumindest dafür, dass die grundlegende Installation richtig ist. Mal sehen wie lange es jetzt so bleibt. Ich werde berichten.

Viele Grüße
Stefan

RockThisParty

Tja ... nach ziemlich genau einer Stunde sind beide Tags wieder "absent"  :'(

PatrickR

Hi!

Zitat von: RockThisParty am 09 Februar 2021, 15:32:58
Tja ... nach ziemlich genau einer Stunde sind beide Tags wieder "absent"  :'(
Ok, da es grundsätzlich geht könnte man den internen Bluetooth-Adapter des Pi ausschließen, z. B. mit diesem USB-Dongle:
https://www.amazon.de/gp/product/B00C68IQ3C/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

Gruß
Patrick
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

RockThisParty

Hallo Patrick,

danke. Was muss ich denn ändern, um dann den externen Adapter zu adressieren?

Grüße,
Stefan

PatrickR

Hi!

Zitat von: RockThisParty am 09 Februar 2021, 16:45:38
danke. Was muss ich denn ändern, um dann den externen Adapter zu adressieren?
Das kannst Du in /etc/default/lepresenced festlegen: Die Zeile

#BLUETOOTH_DEVICE="hci0"

einkommentieren und hci0 durch das gewünschte Gerät ersetzen, z. B.:

BLUETOOTH_DEVICE="hci1"

Die Geräte kannst Du mit

hciconfig

auflisten:

root@rpi-flur:~# hciconfig
hci0: Type: Primary  Bus: USB
BD Address: B8:27:12:34:56:78  ACL MTU: 310:10  SCO MTU: 64:8
UP RUNNING
RX bytes:960855721 acl:59 sco:0 events:28383314 errors:0
TX bytes:8059 acl:59 sco:0 commands:501 errors:0


Am besten vor dem Anstecken und danach ausführen, damit Du genau weißt, welches Gerät das Neue ist.

Nach der Änderung lepresenced neustarten oder den Pi durchbooten.

Patrick
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

MadMax-FHEM

#192
Ich hab mir auch mal einen bestellt, soll am Do kommen...
Mal sehen...

EDIT: Stick kam heute schon :) Und steckt bereits... Mal sehen. Ich habe mal den internen BT deaktiviert... Bleibt die Reihenfolge beim/nach dem Boot (also wenn beides aktiv ist)? Es gibt ja bzgl. USB-Funk-Dongels eine Anleitung zur Einbindung, wenn mehr als einer steckt, damit fhem nicht durcheinander kommt, wenn per /dev/tty definiert...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

MadMax-FHEM

#193
Also wie geschrieben habe ich jetzt den BT-Dongle in Betrieb...
(https://www.amazon.de/gp/product/B009ZIILLI/)

Leider kein Erfolg.

Denke also nicht (habe ich ja noch "nie"), dass es am BT des PI liegt.

Habe mal die Batterie des GiTag gewechselt: keine Verbesserung (laut Modul war die "alte" Batterie auch noch bei 85%)

Habe auch die Batterie raus/rein: immer noch "absent"

Sobald ich jedoch den Service neu starte ist er nach "disconnected" wieder present (was ja auch stimmt)...
...bis eben wieder der "Ausfall" (absent trotz "da") kommt... :-\

Kann ich irgendwie bei der Analyse weiterhelfen?

Und wie geschrieben habe ich den Verdacht, dass es mit einem PI-Update kam...
Vermutlich einem Ende Januar...

EDIT: gefühlt ist es mit dem BT-Dongle schlimmer als mit dem "onboard-BT"... Ich aktiviere mal das "onboard-BT" (overlay) wieder und stelle um auf hci1... Mal sehen...
EDIT: keine Chance. Immer wieder "absent" obwohl "da". Ich werde dann mal ein älteres Buster aufsetzen und dann sehen...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Jamo

Hallo Joachim,
menno, das tut mir jetzt echt leid, wo ich Dir doch auch zu einem externen BT dongle geraten habe.
Das einzige was mir noch einfällt, ist das evtl verschiedene fhem dienste gleichzeitig auf BT zugreifen wollen.
Weiss nicht ob es hilft:
- LePresenced versucht immer einen BT adapter hci exclusiv für sich zu reservieren. Falls noch ein weiteres FHEM modul BT abfragen macht, gehts manchmal schief
- Falls Du z.B. auch noch versuchst, dein Blumensensoren über BT abzufragen kann sein das die sich dann in die quere kommen. Das war bei mir manchmal der Fall.
- Hast Du evtl auch noch einen presence (normales BT, also nicht LE) am laufen? Also z.B. Erkennung ob das Handy BT an hat zur Anwesenheitserkennung?

Was bei mir funktioniert:
- LePresenced (BT-LE) hat exclusiv hci0, externer BT dongle
- Presenced (normales BT) und die Xiaomi Blumen sensoren laufen auf hci1 einem 2-ten externe BT dongle. Bei den Blumen kann man das im attribut einstellen welche schnittstelle genoimmen wird.
- Und dann habe ich mir noch einen stationären G-Tag in die Wohnung gehängt, der immer da ist. Wenn der presence timestamp von diesem g-tag zu alt ist, stosse ich den lepresenced service neu an.

Grüsse, Jamo
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack