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

[MadMax-FHEM]

Hallo Joachim,
menno, das tut mir jetzt echt leid, wo ich Dir doch auch zu einem externen BT dongle geraten habe.

Hallo Jamo,

kein Problem.
Sicher ist sicher...

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?

Ja, nein, da hat jeder sein eigenes

Also ein einsamer PI wo nur deCONZ läuft, dort läuft auch lepresenced und hat hci0 (intern) exklusiv.
Habe WLAN dekativiert, der hängt also an der Leine

Die FlowerSense macht ein PI ZeroW, ebenfalls mit dem internen BT.

Kein sonstiges BT.
Also ein bt-lan PRESENCE für meinen G-Tag.
Sonst nur ein paar (3-4-5) lan-ping PRESENCE...

Bislang (1 Jahr+ bzw. die FlowerSense schon deutlich länger) beides ohne Probleme.

Seit ein paar Tagen eben dann absent trotz Anwesenheit (des G-Tag).
Ist mir aufgefallen, weil ich eben "Licht noch an etc." Meldungen bekommen habe, obwohl ich ja "da" war...


Dann zum Test einen frischen PI3 mit neuestem Buster und erst mal internem BT: selbes Problem. Manchmal läuft es so eine (knappe) Stunde, manchmal auch mehrere Stunden oder sogar einen halben Tag... Aber immer wieder "absent"...

Auf dem deCONZ-PI hab ich dann lepresenced deaktiviert und auch das zugehörige PRESENCE in fhem...


Dann an den PI3 (Test) eben den Dongle. Komischerweise wird nach einem Reboot MIT Dongle nur dieser "erkannt" und ist hci0 (auch ohne Eintrag in /boot/config.txt).
Wenn ich OHNE boote und dann anstecke ist der Dongle hci1.
Ich hab jetzt mal per Overlay den internen deaktiviert.

Noch mal alles laut Wiki und auch (sicherheitshalber) noch mal die neueste lepresenced.deb geholt und installiert...
...mal sehen.
EDIT: hmm, auch damit, also Test-PI wieder dasselbe


Nächster Versuch: ein älteres Buster auskramen und damit mal testen...



Dass es am G-Tag liegt kann das sein?
Wobei ich ja da bereits neue Batterien rein habe und auch im Fehlerfall schon "Batterie raus und wieder rein" probiert habe: hilft nix.
EDIT: funktionieren eigentlich die "Nachfolger" vom Gigaset G-Tag, also die "Keepers" auch?

Auch die üblichen Dinge bzgl. BT-Probleme beim PI hciconfig hci0 up/down usw. hilft nicht.

Sobald ich aber den lepresenced service neu starte geht es sofort wieder...


Eigenartig...


Trotzdem nat. DANKE!

Gruß, Joachim

[gestein]

- 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.

Das ist eine tolle Idee. Das werde ich auch so machen.
lg, Gerhard

[gestein]

Hallo Joachim,

was sagen denn die logs vom lepresenced?
Arbeitest Du auch mit collectord?

lg, Gerhard

[MadMax-FHEM]

- 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.

Das ist eine tolle Idee. Das werde ich auch so machen.
lg, Gerhard

Hmm, ja, ginge auch.

Aktuell überlege ich das ohne extra G-Tag hinzubekommen...
...mal sehen...

Hallo Joachim,

was sagen denn die logs vom lepresenced?
Arbeitest Du auch mit collectord?

lg, Gerhard

Ja, Log mal sehen, evtl. mal auf Debug stellen...
Jetzt mache ich noch den Versuch mit einem älteren Buster, mal sehen...

Nein, kein collectord.
Nur bt-lan...

Gruß, Joachim

[det.]

Hallo Joachim,
hatte selbige Probleme - hilft Dir mglw. nicht wirklich weiter - gelöst - abschließend, durch Verschenken der Gtag (1 älterer und 1 Keeper) und löschen in FHEM. Ich löse die Herausforderung (IPhones und Android Handys - Anwesenheit von gelegentlichen Besuchern bzw. Geofency Verweigerern) sehr zuverlässig über die Readings im Unifi Modul.
Das ist doch eine der herausragenden Eigenschaften von FHEM, das es zu nahezu jeder Aufgabe eine Vielzahl an Lösungsmöglichkeiten gibt. So kann man leicht umsatteln, anstatt das tote Pferd ewig weiter zu reiten.

[MadMax-FHEM]

Hallo Joachim,
hatte selbige Probleme - hilft Dir mglw. nicht wirklich weiter - gelöst - abschließend, durch Verschenken der Gtag (1 älterer und 1 Keeper) und löschen in FHEM. Ich löse die Herausforderung (IPhones und Android Handys - Anwesenheit von gelegentlichen Besuchern bzw. Geofency Verweigerern) sehr zuverlässig über die Readings im Unifi Modul.
Das ist doch eine der herausragenden Eigenschaften von FHEM, das es zu nahezu jeder Aufgabe eine Vielzahl an Lösungsmöglichkeiten gibt. So kann man leicht umsatteln, anstatt das tote Pferd ewig weiter zu reiten.

Lustig...

Ich hatte auch erst Handy (lange Zeit), dann kam irgendein FW-Update mit "zu viel Sleep"

Dann hping3 und PRESENCE lan-ping kombiniert (wegen höherem Akkuverbrauch bei hping3)...
...hat auch ganz gut geklappt.

Bevor ich dann zu BT gegangen bin habe ich mal hping3 und UnifiClient parallel laufen lassen und da war mir die "Abwesend-Erkennung" zu langsam.
Teilweise über 5min...

Und wie geschrieben hat das mit BT wunderbar funktioniert bis...
...naja...

Einen Verscuh gebe ich dem ganzen noch...

Ansonsten evtl. doch auch noch mal UnifiClient, evtl. isses ja besser (geworden)...

Oder eine Kombination aus allen 3en

Gruß, Joachim

[MadMax-FHEM]

Jetzt mache ich noch den Versuch mit einem älteren Buster, mal sehen...

Läuft: Buster ca. Mai 2020...
Mal sehen.

sudo service lepresenced status

liefert schon mal keinen Fehler:

Code Auswählen Erweitern


● lepresenced.service - lepresenced
   Loaded: loaded (/lib/systemd/system/lepresenced.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2021-02-11 18:55:04 CET; 53s ago
  Process: 288 ExecStartPre=/bin/sleep 10 (code=exited, status=0/SUCCESS)
Main PID: 453 (lepresenced)
    Tasks: 5 (limit: 2319)
   Memory: 14.9M
   CGroup: /system.slice/lepresenced.service
           ├─453 /usr/bin/perl /usr/sbin/lepresenced --device hci0 --listenaddress 0.0.0.0 --listenport 5333 --loglevel LOG_WARNING
           ├─465 hcitool -i hci0 lescan --duplicates
           └─467 hcidump -i hci0

Feb 11 18:54:54 MadMax-OMV-Test systemd[1]: Starting lepresenced...
Feb 11 18:55:04 MadMax-OMV-Test systemd[1]: Started lepresenced.


Beim SELBEN Pi mit neuestem Buster kamen da schon mal 2 Meldungen:

Code Auswählen Erweitern


● lepresenced.service - lepresenced
   Loaded: loaded (/lib/systemd/system/lepresenced.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2021-02-11 18:58:36 CET; 4s ago
  Process: 21066 ExecStartPre=/bin/sleep 10 (code=exited, status=0/SUCCESS)
Main PID: 21158 (lepresenced)
    Tasks: 5 (limit: 2181)
   CGroup: /system.slice/lepresenced.service
           ├─21158 /usr/bin/perl /usr/sbin/lepresenced --device hci0 --listenaddress 0.0.0.0 --listenport 5333 --loglevel LOG_WARNING
           ├─21176 hcidump -i hci0
           └─21215 hcitool -i hci0 lescan --duplicates

Feb 11 18:58:26 MadMax-PI-HUE systemd[1]: Starting lepresenced...
Feb 11 18:58:36 MadMax-PI-HUE systemd[1]: Started lepresenced.
Feb 11 18:58:37 MadMax-PI-HUE lepresenced[21158]: [tid:1] main::bluetooth_scan_thread: Received 'Set scan parameters failed: Input/output error', resetting...
Feb 11 18:58:37 MadMax-PI-HUE lepresenced[21158]: [tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...


Gruß, Joachim

[micky0867]

Ich schmeiß hier mal eine andere Lösung rein, vllt ist das ja für jemanden interessant.

Nachdem mir die Reaktionszeit von lepresenced zu langsam und das System zu kompliziert (wg Prozessen unter Linux) war, habe ich mir was anderes überlegt.
Außerdem wollte ich die Option haben, andere Sensoren (FlowerCare) per Bluetooth anzubinden.

Ich habe meine 3 ESP8266 mit BT-Empfänger, die von einem modifizierten lepresenced gesteuert wurden, gegen 3 x ESP32 ersetzt. Die ESP32 haben schon BT on board.
Darauf läuft OpenMQTTGateway (https://github.com/1technophile/OpenMQTTGateway) und leitet alle BLE-Nachrichten an FHEM weiter. BLE wird dabei alle 39 Sekunden gescannt.
Auf FHEM werden dann nur die Nachrichten rausgefiltert, die meine 2 GTags betreffen. Ein Notify sorgt dann dafür, dass bei den 2 zughörigen Dummy-Devices der state auf present und die Readings für Garage/Flur/Garten mit den gemeldeten RSSI-Werten besetzt werden, fast so, wie es beim collectord gemacht wurde.
Ein "defmod at_gtag1 +0:02:00 ..." setzt einen Timeout immer wieder auf 2 Minuten, so dass bei 3 fehlenden "pings" der Status des Dummies auf "absent" gesetzt wird.

Vorteile:
Keine zusätzlichen Prozesse unter Linux
Der Scan alle 40 Sekunden deaktiviert meine Alarmanlage schneller als früher. (besserer WAF)
Einen ESP32 habe ich noch mit BME280 und PIR-Sensor ausgestattet, was dann auch per MQTT übertragen wird

Nachteile:
Die ESPs hängen sich von Zeit zu Zeit auf

[OdfFhem]

Ich beschreibe auch mal kurz mein Einsatz-Scenario:

Ich nutze produktiv 2xPi3B (1xStretch ; 1xBuster) und 1xPi3B+ (Buster). Auf allen wird das on-board-Bluetooth zum Scannen der GTags unter Einsatz von lepresenced bzw. collectord genutzt.

Ein generelles Auftreten von Ausfällen kann ich nicht nachvollziehen. Höchstens der Stretch-Abkömmling ist/war etwas hakelig, aber aktuell ist auch die Uptime von bisher 97 Tagen sorgenfrei geblieben.

Beim Verlassen der Wohnung nutze ich einen Timeout von 5 Minuten, bevor die Alarmanlage tatsächlich scharf geschaltet wird. Beim Kommen gibt es logischerweise keinen Timeout und die Alarmanlage wird sofort abgeschaltet. Klappt somit eigentlich erwartungsgemäß.

[MadMax-FHEM]

@OdfFhem: wie aktuell sind deine Buster?

Weil aktuell läuft mein PI3 mit älterem Buster stabil...

Und es ist DERSELBE PI3 der mit AKTUELLEM Buster die Probleme hat(te)...

Ich lasse noch ein wenig laufen...
...aber für mich sieht es tatsächlich so aus, als wäre irgendwas mit dem Buster-Update vor so einer guten Woche "passiert" was "nicht gut" ist...

@micky0867: darüber habe ich auch schon nachgedacht. Aber wenn: "bleibt ab und an hängen", ist das genauso "schlecht" wie mit aktuellem Buster...
Bzw. schlechter, weil hier reicht es den Service neu zu starten. Beim ESP32? Strom ziehen, oder?

Und nochmal: mit aktuellem Buster nicht nur Probleme mit "onboard" BT sondern genau dasselbe Verhalten auch mit BT-Dongle!!

Weil auch "nur" den Treiber hatte ich auch schon mal einen "älteren" eingespielt, hat nicht geholfen...
Und: es gibt eben auch Probleme mit dem externen Dongle...

Gruß, Joachim

[OdfFhem]

@MadMax-FHEM

Pi3B:

Code Auswählen Erweitern


Linux raspberrypiX 5.4.51-v7+ #1333 SMP Mon Aug 10 16:45:19 BST 2020 armv7l GNU/Linux



Pi3B+ für längere Zeit ...

Code Auswählen Erweitern


Linux raspberrypiY 5.4.72-v7+ #1356 SMP Thu Oct 22 13:56:54 BST 2020 armv7l GNU/Linux

... und seit ein paar Tagen:

Code Auswählen Erweitern


Linux raspberrypiY 5.10.11-v7+ #1399 SMP Thu Jan 28 12:06:05 GMT 2021 armv7l GNU/Linux


[MadMax-FHEM]

Naja: deine sind ja (bis auf eines) noch recht alt...
Evtl. sogar das mit Januar...

So genau weiß ich leider nicht mehr, welches (vermutlich/vermeintliche) Update zur aktuellen Lage geführt hat...

Gefühlt Ende Januar (evtl. eher) Anfang Februar...

Das Image was jetzt läuft (müsste mal nachsehen, geht aber grad nicht) müsste so Mai 2020 sein...
Und: es läuft immer noch stabil mit dem internen BT...

Also für mich sieht es (aktuell immer noch) so aus, als würde es am PI-Update liegen/gelegen haben...

Aktuell tendiere ich dazu einen PI ZeroW zu nehmen. Ich clone einfach den, den ich für die BT-FlowerSense nutze (oder schaue mal wie der mit der reichweite so hinhaut), der läuft noch und wurde (auch aus "solchen Gründen" nicht geupdated   )

Gruß, Joachim

[micky0867]

@micky0867: darüber habe ich auch schon nachgedacht. Aber wenn: "bleibt ab und an hängen", ist das genauso "schlecht" wie mit aktuellem Buster...
Bzw. schlechter, weil hier reicht es den Service neu zu starten. Beim ESP32? Strom ziehen, oder?

Das kann man schlecht miteinander vergleichen.
Mein Ziel war ja auch, die notwendige Hardware und damit Stromverbrauch zu minimieren, bei gleichzeitig maximalem Nutzen (BME280, BT-Forwarding) und billiger HW.
Für die überall rumstehenden PIs sehe ich keinen angemessenen Nutzen und die Sache mit den SD-Karten ist mir ein persönliches Gräuel (mein einziger PI bootet vom Netzwerk von einem NUC).

Das Problem mit den Hängern hat mich bisher auch gar nicht so enorm gestört, aber ich habe gestern mal die aktuellste OMG-Version installiert, um zu testen, ob das Problem mittlerweile beseitigt ist.
Ansonsten muss ich mich mal an die serielle Schnittstelle hängen, um der Ursache auf den Grund zu gehen...wenn der Leidensdruck groß genug ist

Alternativ hänge ich den ESP32 an eine Wifisteckdose mit schaltbarem USB-Ausgang. Ist ohnehin fast genauso billig, wie eine reine USB-Stromversorgung und bietet noch zusätzliche Funktionalität.

[MadMax-FHEM]

Ja, Stromverbrauch etz. wäre auch meine einzige Überlegung zu einem ESP32 zu wechseln...

...den ich aber noch nicht habe...

Der PI ist ja eigentlich meine HUE-Bridge und macht noch Abfrage eines USB-CO2-Messers...

Steht also nicht nur rum und macht BT...

Meine "wichtigen" PI, z.B. tvheadend und fhem booten von SSD...

Aber mal sehen, wenn es hierfür keine Lösung gibt, außer einen anderen PI (gut den PI ZeroW für BT-Flowersense hätte ich schon) mit ALTEM Buster zu nehmen und einfach nicht mehr mit einem Update zu versorgen, dann vielleicht auch einen ESP32...

Eine per fhem schaltbare USB-Steckdose hätte ich ja noch

Hast du noch einen Link für mich, was da auf den ESP32 drauf muss usw.? DANKE!

Gruß, Joachim

[micky0867]

Habe jetzt was gefunden, was ich noch gar nicht kannte....
...sehe aber gerade, dass der Wikieintrag erst seit Dezember existiert.
Da gibt's scheinbar auch eine intelligenter Lösung für den Timeout...muss ich mir selbst mal anschauen.

https://wiki.fhem.de/wiki/OpenMQTTGateway