lepresenced: Neue Testversion (lepresenced0.93dev21)

[PatrickR]

Hi!

Erstmal @Jamo, dkreutz: Besten Dank für die ausführlichen Infos.

Bist Du Dir sicher das es bei Dir läuft und auch funktioniert?

Langsam frage ich mich auch, ob ich sie noch alle habe. Sollte ich mal auf Arbeitsunfähigkeit klagen wollen bräuchte ich Euch als Zeugen.

Interessant ist, dass Jamo's wohny nahezu exakt aussieht wie mein funktionierendes System. Du hast ein Paket mehr installiert, das aber dkreutz nicht drauf hat. Ansonsten ist Distri, Patchstand und sogar Firmwarestand absolut identisch. Die USB-IDs sind abei uns Dreien auch exakt gleich. Das ist ziemlich überraschend, da mein UD100 (ein ziemlich teurer Stick) die gleichen USB IDs hat wie mein bzw. Eure noname Sticks.

Was mir jetzt noch einfällt:

• Meinen UD100 abziehen und exklusiv mit dem Billigdongle testen.
• Irgendeine Art von gemeinsamem Remote-Debugging (shared screen Session oder vielleicht besser Teamviewer)

evtl. auch so lange mit dem Hammer auf meinen Pi dreschen, bis der Fehler auftritt.

Patrick

[TL]

Moin!

Daher benötige ich Eure Hilfe:
Wenn bei Euch das Problem auftritt, dass ca. 2 Minuten nach dem Start (also beim Batteriecheck) alle Tags auf absent wechseln und dort bleiben (und auch nur dann), interessieren mich folgende Infos:

per PM geschickt.

Gruß
TL

[Jamo]

Hallo Patrick,
ja vielleicht tauscht Du mal den high-tech Industrie SENA Parani-UD100 gegen einen CSL Bluetooth adapter. Ich habe mal gegoogled und die Spec/Beschreibung unter folgender Seite gelesen:

https://www.bressner.de/shop/connectivity-iot/serial-adapter/sena-parani-ud100/
SENA Parani-UD100 - Unterstützt Bluetooth  v4.0, 7 gleichzeitige unabhängige Verbindungen - mit Antenne bis zu 1000 Metern

Vielleicht liegt es wirklich an den vielen Verbindungen die der UD100 gleichzeitig kann.

Ich habe das einfache Modell hier, https://www.amazon.de/CSL-Bluetooth-verbesserte-Energieeffizienz-Technologie/dp/B01N0368AY
CSL - Bluetooth 4.0 USB Adapter - V4.0 verbesserte Energieeffizienz

Das ist ja wie David gegen Goliath.

[PatrickR]

ja vielleicht tauscht Du mal den high-tech Industrie SENA Parani-UD100 gegen einen CSL Bluetooth adapter.

So high-tech ist der garnicht, sieht nur gut aus und ist teuer. Ich komme nichtmal ein Stockwerk weit...
Habe ihn mal gerade gegen den hier getauscht:
https://www.amazon.de/gp/product/B00D757YZ4/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
Und siehe da: Immer noch alles super.

CSL - Bluetooth 4.0 USB Adapter - V4.0 verbesserte Energieeffizienz

Habe den mal bestellt auch wenn ich nicht dran glaube.

Experimentiere gerade mit ner Race Condition beim Neustart des Adapters und mit einem schlecht erreichbaren G-Tag.

Grüße
Patrick

[Jamo]

Hallo Patrick,
also dann liegt es wohl nicht am Stick, und den CSL hätte ich Dir auch gerne für alle deine Mühen bei der Modulentwicklung zur Verfügung gestellt - ich glaube nicht, das es daran liegt.
Was ist denn sonst noch anders, zwischen deinem setup und unserem setup?
- Die Anzahl der G-Tags / erreichbarkeit der G-Tags?
- Collectord (der bei mir auf einem anderen Rechner / der FHEM Hauptinstanz läuft) <- Du hast gesagt den hast Du nicht installiert. Kann es daran liegen?
  Ich weiss ja nicht wie der lepresenecd und der collectord zusammenarbeiten.

Gruss, Jamo

[TL]

Moin!

Ich war gestern im Zshg. mit unserem Problem auf folgenden Thread gestoßen:
https://www.raspberrypi.org/forums/viewtopic.php?t=201992

Darin gibt es den Vorschlag, das btusb-Modul zu entladen und wieder neu zu laden:

Code Auswählen Erweitern

modprobe -r btusb && sleep 1 && modprobe btusb

Gesagt, getan - seitdem funktionieren die Dongles wieder wie gewohnt, also An- und Abwesenheit werden wieder erkannt. Dafür funktioniert jetzt offenbar die Batterieabfrage nicht mehr.  Hier der entsprechende Auszug aus dem Syslog:

Code Auswählen Erweitern

Aug 22 12:34:49 fhem lepresenced[13469]: [tid:0] main::battery_task: Starting battery task, 5 reachable device(s) to query...
Aug 22 12:34:49 fhem lepresenced[13469]: [tid:0] main::battery_task: Battery level for mac 7c:2f:80:... is unknown.
Aug 22 12:34:49 fhem lepresenced[13469]: [tid:0] main::battery_task: Battery level for mac 7c:2f:80:...is unknown.
Aug 22 12:34:49 fhem lepresenced[13469]: [tid:1] main::bluetooth_scan_thread: hcitool was stopped.
Aug 22 12:34:49 fhem lepresenced[13469]: [tid:2] main::bluetooth_dump_thread: hcidump was stopped.
Aug 22 12:34:49 fhem lepresenced[13469]: [tid:0] main::battery_task: Battery level for mac 7c:2f:80:... is unknown.
Aug 22 12:34:49 fhem lepresenced[13469]: [tid:0] main::battery_task: Battery level for mac 7c:2f:80:... is unknown.
Aug 22 12:34:49 fhem lepresenced[13469]: [tid:0] main::battery_task: Battery level for mac 7c:2f:80:... is unknown.
Aug 22 12:34:51 fhem lepresenced[13469]: [tid:0] main::battery_task: Battery task completed.
Aug 22 12:34:52 fhem lepresenced[13469]: [tid:1] main::bluetooth_scan_thread: Received 'Set scan parameters failed: Input/output error', resetting...
Aug 22 12:34:52 fhem lepresenced[13469]: [tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...
Aug 22 12:34:53 fhem lepresenced[13469]: [tid:1] main::bluetooth_scan_thread: Received 'LE Scan ...'.
Aug 22 12:36:16 fhem lepresenced[13469]: [tid:0] main::cleanup_task: Cleanup finished, deleted 6 devices in 0 seconds.

Viele Grüße
   TL

[PatrickR]

Hi!

lso dann liegt es wohl nicht am Stick, und den CSL hätte ich Dir auch gerne für alle deine Mühen bei der Modulentwicklung zur Verfügung gestellt - ich glaube nicht, das es daran liegt.

Das ist garnicht nötig. Habe die Bestellung schon wieder storniert.

Es gibt nämlich gute Nachrichten. Ich habe gestern noch einmal die Logs gewälzt und endlich die Ursache gefunden. lepresenced beendet vor der Batterieabfrage hcitool und hcidump. Hcidump interessiert das aber nicht. Es läuft einfach weiter, aber nur genau dann, wenn lepresenced vom wundervollen Systemd gestartet wird, d. h. wenn mein deb-Paket benutzt wird. Das müsste man mal im Detail erforschen aber ich unterdrücke den Drang einfach mal.

Ich baue gerade an einer aktualisierten Version.

Grüße
Patrick

[Jamo]

Es gibt nämlich gute Nachrichten.

TADA!!! Glückwunsch!! Das freut mich wenn es das gewesen sein sollte!

[PatrickR]

Mahlzeit!

So, im Startposting hängt die neue Version lepresenced0.93dev18.

Änderungen:

• hcidump wird nun beim Batteriecheck mit Gewalt beendet. Dadurch startet es danach sauber.
• Die Batteriewerte werden nur gesendet, wenn sie vorliegen (also nicht unknown sind) und nicht älter als das 4-fache des Batterie-Intervalls sind, d. h. im Standardfall nicht älter als 24 Stunden. Das sollte die oben beschriebene collectord-Problematik abmildern.

Viel Spaß beim Testen!

Grüße
Patrick

[Jamo]

Läuft! Er hat die ersten 5 Minuten anstandslos überstanden.

[UPDATE] Läuft immer noch, habe den dev18 jetzt auf allen 3 Raspi + FHEM Hauptinstanz iNUC am laufen.
Der collectord zeigt jetzt auch im Reading daemon den lepresenced V0.93dev18 an
Das battery_level ist bei 3 von 5 GTags aktualisiert.

!.Glückwunsch.! und Danke!

[Jamo]

Hi Patrick,
das battery_level wird jetzt auch jede Minute aktualisiert. Da Du geschrieben hast, das der hcidump im Intervall mit Gewalt beendet wird (und er wird ja auch dann wieder gestartet) - Bei mir ist das Intervall 60 Sekunden - Macht das nicht Sinn, den battery_level e.g. nur alle 4-6 Stunden abzufragen, und auch nur dann, wenn das BT device present ist? Alle 60 sekunden einen prozess zu killen und dann wieder neu zu starten hoert sich komisch an.

[PatrickR]

Hi!

Das battery_level wird jetzt auch jede Minute aktualisiert. Da Du geschrieben hast, das der hcidump im Intervall mit Gewalt beendet wird (und er wird ja auch dann wieder gestartet) - Bei mir ist das Intervall 60 Sekunden - Macht das nicht Sinn, den battery_level e.g. nur alle 4-6 Stunden abzufragen, und auch nur dann, wenn das BT device present ist? Alle 60 sekunden einen prozess zu killen und dann wieder neu zu starten hoert sich komisch an.

Oh, da habe ich mich unklar ausgedrückt. Also: Das battery_level wird standardmäßig alle 6 Stunden bei den GTags abgefragt, aber bei jeder Aktualisierung (z. B. weil 60 Sekunden um sind oder sich die rssi stark geändert hat) mit übertragen (Ausnahme: Es ist älter als 24 Stunden). Das siehst Du auch nach einer Stunde sehr gut, wenn battery_level_age von 0 auf 1 springt. Die 6 Stunden kannst Du unabhängig ändern mit --batteryinterval.

Schön, dass es funktioniert. Danke auf jeden Fall für Deine tatkräftige Hilfe. @all: Das gilt auch für Euch.

Das kannst Du übrigens schön im Syslog sehen, wenn der Log Level auf DEBUG steht. Da solltest Du ihn aber beim Raspberry nicht stehen lassen, da die SD-Karte das dauerhaft nicht gut findet.

Grüße
Patrick

[Jamo]

Super, dann schau ich bei den beiden GTags, mit den noch nicht aktualisiertem battery_level, in 6h wieder vorbei. Danke nochmal, bei mir läufts perfekt. Die BTLEBattery Instanz ist schon dem delete Knopf zum Opfer gefallen  

[TL]

Jo, läuft bei mir jetzt auch. Batterieabfrage muss ich noch weiter beobachten, aber der status ist auf jeden Fall jetzt wieder brauchbar. Vielen Dank, Patrick!

[dkreutz]

Die dev18 läuft bei mir seit ca. 10h, presence funktinioniert, battery_level wurde aber bisher nicht aktualisert (reading timestamp ist immer noch von gestern).