lepresenced: Neue Testversion (lepresenced0.93dev21)

[Jamo]

Ja, danke. Hab alles gemacht, Log in deiner privaten e-mail.

[PatrickR]

Hi!

Ja, danke. Hab alles gemacht, Log in deiner privaten e-mail.

Interessant. Es sieht so aus als würden nach der Batterieabfrage und dem Neustart des Scans keine Beacons mehr empfangen. Habe im Startposting die Version lepresenced0.93dev15 angehängt, die kleinere Probleme behebt aber vor allem etwas mehr loggt. Kannst Du das mal ausführen, mindestens 5 Minuten laufen lassen und mir wieder das Log schicken?

Danke!

Patrick

[Jamo]

Erstmal Danke für den neuen LePresenced, Du hast eine neue PN.

[PatrickR]

Hi!

Danke für das Log.

Erstmal Danke für den neuen LePresenced, Du hast eine neue PN.

Code Auswählen Erweitern


Aug 19 18:08:08 wohny lepresenced[27754]: [tid:0] main::stats_task: Active clients: 9, known devices: 35 (min/max age: 93/195), received beacons (hcitool/hcidump/difference): 3735/0/3735

Auch das ist interessant. Ab dem Zeitpunkt des Neustarts der Prozesse nach der Batterieabfrage empfängt hcidump keinen einzigen Beacon mehr, hcitool aber schon. Werde Dir heute oder morgen nochmal eine weitere Version mit mehr Logging schicken, um der Sache auf den Grund zu gehen.

Noch eine Frage: Von den 5 zum Zeitpunkt des Logs erreichbaren Geräten hat nur eins auf die Batteriaabfrage geantwortet, 4 geben "Function not implemented" zurück. Hast Du für die mit Deiner alten Batteriemethode einen Wert bekommen?

Patrick

[Jamo]

Hallo Patrick,
ja, ich habe für alle einen BatterieLevel (Mumpitz) bekommen, aber auch nur sporadisch, also 1 x pro Woche oder so was. Mit dem Modul von Mumitz läuft die batterieabrage ja auch nur auf einem raspi, aber die GTags sind im ganzen Haus verteilt.
Der eine GTag, der im Syslog auf die Batterieanfrage in den 5 Minuten reagiert hat, hängt direkt neben dem "wohny" Raspi, auf dem der neue dev15 lepresenced läuft. Bei den anderen 4 GTags sind mindestens 1 oder 2 Wände dazwischen, deswegen hat der eine Raspi "wohny" die anderen 4 GTags in den 5 Minuten wahrscheinlich ncht empfangen (Und ich habe den neuen dev15 lepresenced ja nur auf einem (dem wohnzimmer raspi) von meinen 4 Raspis/inuc installiert)
Sobald ich überall den neuen lepresenced installieren würde, würde das ja dann über den collectord kommen.
Danke!

[dkreutz]

Welche Version hast Du vorher eingesetzt, also die, die funktionierte?

lepresenced.0.91dev - funktionierte bisher am besten und lief wochenlang ohne Neustart des Service.

Welche BLE-Tags setzt Du ein?

Gigaset G-Tag

Wie hoch ist das check-interval der PRESENCE-Instanzen in FHEM? (

INTERVAL_NORMAL 30
INTERVAL_PRESENT 120

[PatrickR]

Hi!

Der eine GTag, der im Syslog auf die Batterieanfrage in den 5 Minuten reagiert hat, hängt direkt neben dem "wohny" Raspi, auf dem der neue dev15 lepresenced läuft. Bei den anderen 4 GTags sind mindestens 1 oder 2 Wände dazwischen, deswegen hat der eine Raspi "wohny" die anderen 4 GTags in den 5 Minuten wahrscheinlich ncht empfangen

Interessante Theorie. Aber das kriegen wir leichter in den Griff, wenn der Dump erstmal wieder funktioniert und Du die gefixte Version in Deiner Monsterinfrastruktur ausrollen kannst

Bitte erstelle nochmal mit der angehängten Version ein Log wie gehabt.

@all: Die angehängte Version erzeugt nur mehr Logs, d. h. sie dient nur zur Eingrenzung des Fehlers.

Gruß
Patrick

[Jamo]

... in Deiner Monsterinfrastruktur ausrollen kannst

Wer kann der kann und wer hat der hat

Aber das kriegen wir leichter in den Griff, wenn der Dump erstmal wieder funktioniert

So machen wir das!
Du hast eine neue PN.

[TL]

Moin!

Wollte mich nur mal einklinken und anmerken, dass ich diesen Thread mit Spannung verfolge und gern auch bei der Fehlersuche mithelfen könnte, wenn gewünscht. Ich habe ein ähnliche Konfiguration wie dkreutz, 5 Gigaset G-tags die ich überwache und einen Zusatzadapter am Raspi.
Die von Patrick beschriebenen Phänomene habe ich ganz genauso beobachtet: Nach dem Neustart des lepresenced funktioniert es kurz, alle G-tags sind present, dann kommt die Batterieabfrage (die scheinbar auch funktioniert), und danach kommen dann keine Daten beim lepresenced mehr an und die G-tags werden als absent gemeldet.

Was mir auffällt: Wenn ich gleich nach dem Stoppen des lepresenced versuche, das hcitool auf der Commandline direkt zu benutzen, gibt es folgende Fehlermeldungen:

Code Auswählen Erweitern

hcitool -i hci0 lescan
Set scan parameters failed: Input/output error
bzw.

Code Auswählen Erweitern

hcitool -i hci0 leinfo 7C:2F:80:xx:xx:xx
Requesting information ...
Could not create connection: Input/output error

Nach so 1-2 Minuten funktioniert es dann wieder. Beobachtet ihr das auch?

[Jamo]

Hallo Patrick,
dann ist es wahrscheinlich so, das der lepresenced exclusiven Zugriff auf den hci0 benötigt. Für die Batterieabfrage bräuchte man dann einen extra BT-Dongle, z.B. hci1 oder hci2. Das ist bei dem Modul von Mumpitz auch so, das läuft nur zuverlässig wenn das Modul Zugriff auf einen anderes BT interface hat.
Bei mir läufts so:
- hci0: LEprecenced
- hci1: presenced
- hci2: myBleTagBattery (Mumpitz)

Siehe auch https://forum.fhem.de/index.php/topic,68104.msg999363.html#msg999363

Zitat von Mumiptz:

Lepresenced und vielleicht auch presenced usw. scannen nach USB Geräten und belegen bei diesem Vorgang den Adapter exklusiv! Wenn jetzt mein Modul kommt, dann stiehlt es sich für kurze Zeit den exklusiven Zugriff. Lepresenced merkt das aber nach einigen Sekunden und holt sich den Zugriff dann zurück.

Oder kannst Du das Interface zwischendurch für die Batterieabfrage freigeben, also abwechselnd batterieabfrage/lepresence check machen?

[PatrickR]

Hallo zusammen!
Erstmal Danke für die Resonanz!

Wollte mich nur mal einklinken und anmerken, dass ich diesen Thread mit Spannung verfolge und gern auch bei der Fehlersuche mithelfen könnte, wenn gewünscht.

Bislang bleiben durch die Logs von Jamo wirklich keine Wünsche offen. Wenn das soweit im Griff ist, können wir glaube ich im größeren Stil testen. Ich habe ärgerlicherweise bei mir das Problem, dass es bei mir einwandfrei funktioniert, bei Euch aber nicht. Das ist praktisch der Worst Case für die Fehlersuche.

Was mir auffällt: Wenn ich gleich nach dem Stoppen des lepresenced versuche, das hcitool auf der Commandline direkt zu benutzen, gibt es folgende Fehlermeldungen:

Code Auswählen Erweitern

hcitool -i hci0 lescan
Set scan parameters failed: Input/output error

Ärgerlicherweise treten immer mal wieder Fehler beim Zugriff auf das Bluetooth-Gerät auf. Daher trackt lepresenced sie und schickt ggf. ein hciconfig reset los.

dann ist es wahrscheinlich so, das der lepresenced exclusiven Zugriff auf den hci0 benötigt. Für die Batterieabfrage bräuchte man dann einen extra BT-Dongle, z.B. hci1 oder hci2. Das ist bei dem Modul von Mumpitz auch so, das läuft nur zuverlässig wenn das Modul Zugriff auf einen anderes BT interface hat.

Mein Ansatz war, auch eine Variante mit einem Interface zu unterstützen, was bei mir auch funktioniert. Aktuell ist es so, dass das auf der Kommandozeile übergebene Gerät für Scan _und_ Batteriecheck genommen wird. Das könnte man natürlich ändern. Ich hoffe noch, dass das nicht nötig sein wird.

Oder kannst Du das Interface zwischendurch für die Batterieabfrage freigeben, also abwechselnd batterieabfrage/lepresence check machen?

Genau das macht der lepresenced. Er beendet den Scan- und den Dump-Prozess, fragt die Batterien ab, startet die Prozesse wieder und korrigiert die Abfrage der Geräte um die "Blindflugzeit". Das ist auch der Haupt-Mehrwert von einer Integration in lepresenced direkt.

Danke übrigens für die letzten Logs. Die sind sehr aufschlussreich.

Patrick

[PatrickR]

Hi!

@Jamo:
Habe wieder eine neue Version fertig gemacht, die noch etwas mehr loggt und zwei kleine, leider für das Problem nicht relevante Fehler behebt.

Kannst Du das mal testen, 1x im Originalzustand und 1x wenn Du in Zeile 55 von lepresenced $BATTERY_TASK_SETTLE_SLEEP von 2 auf 30 umstellst?

Gruß
Patrick

[Jamo]

Gerne, alles schon in deiner Inbox!

[PatrickR]

Hi!

Gerne, alles schon in deiner Inbox!

Nochmal vielen Dank für Deine Tests und Logs.

Ärgerlicherweise komme ich langsam zu dem Schluss, dass ich das Problem nur sinnvoll eingrenzen kann, wenn es bei mir auch auftritt. Mein Ziel ist es also, meine Installation kaputt zu machen.

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:

-Hardware (RPi1, Rpi2, Rpi3, NUC, VM etc.):
-Welche Bluetooth-Geräte (Sticks, intern bei Rpi) etc. sind angeschlossen/aktiv:
-Mit welchem Bluetooth-Gerät wird lepresenced verwendet:
-Die Ausgabe von

Code Auswählen Erweitern

cat /etc/issue;uname -a;dpkg -l|grep -iE '(blue|firmware)';lsusb|grep -iE '(hci|blue)';/opt/vc/bin/vcgencmd version
-Welche Bluetooth-relevanten Programme/Dienste laufen noch (presenced, Batterieskripte, FHEM-Module mit BLE wie XiaomiBTLESens):

Ich hoffe, wir sehen dann eine Gemeinsamkeit, die ich bei mir nachrüsten kann.

Parallel probiere ich gerade, mein System durch Anstecken weiterer BLE-Sticks kaputt zu bekommen.

Grüße
Patrick

[Jamo]

Hallo Patrick,
Info per PN geschickt. Zusätzliche habe ich gerade nochmal folgendes gemacht (grundconfig ist Raspberry mit internem BT + 1 x externer BT Dongle:
- den externe BT-dongle abgezogen, damit nur der interne Raspi-BT läuft, dann dev17 lepresenced auf hci0 gestartet
- einen weiteren 2-ten externen BT-dongle an den Raspberry gesteckt, und den dev17 lepresenced dann auf hci2 gestartet, weil ich wissen wollte es ob es am internen raspberry BT liegt.
- den raspberry sshhost für den XiaomiBTLESens abgeschaltet, damit XiaomiBTLESens keine Abfrage auf dem raspberry bezüglich der Blumen-Sensoren starten kann. Aber eigentlich ist das XiaomiBTLESens  intervall schon auf 14400 und sollte nicht stoeren.

Alle 3 Versuche haben keine Verbesserungen gebracht.
Bist Du Dir sicher das es bei Dir läuft und auch funktioniert?

Beste Grüsse!