lepresenced: Neue Testversion (lepresenced0.93dev21)

[PatrickR]

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

War der GTag durchgehend gut erreichbar? Kannst auch tesweise mal einen StatusRequest abschicken, dann sollte 3 Minuten später der Wert kommen. Ansonsten Loglevel hochsetzen und lepresenced durchstarten.

Patrick

[Jamo]

Hi Patrick, kann es sein, das der batteriecheck nur beim ersten mal, nach dem neu-starten des lepresenced funktioniert?
Meine beiden GTags, die noch kein update bekommen haben, sind sehr gut erreichbar (ich habe ja die verteilte installation mit einem Raspi/lepresenced in jedem Zimmer), und z.B. der GTag "black" hat jetzt nach 8 h noch kein batterie_level update bekommen. Auch mehrmaliges "statusrequest" hat kein battery_level generiert. Dann habe ich gerade mal den lepresenced bei dem rechner wo der 'black' daneben liegt, mit 'sudo service lepresenced restart' neu gestartet, und da ist das battery_level sofort gekommen.

Ich habe noch einen G-Tag 'orange', der ist auch sehr gut erreichbar, der hat auch noch kein battery_level bekommen, auch nach mehrmaligem 'statusrequest'. Kann ja eigentlich nicht sein, egal in welchem Zimmer, da ist ja immer ein Raspi mit lepresenced daneben. Ausserdem ist da auch, wie bei den anderen GTags, die Batterie neu gewechselt (hatte ich extra für unsere lepresenced Tests noch gemacht). Da mache ich jetzt mal nix und sag morgen früh nach weiteren 12h nochmal Bescheid.

PS: Nach dem G-Tag 'orange' statusrequest sehe ich dass das reading 'command_accepted' auf 'yes' updated, die rssi werden erneuert, aber kein battery_level  
Und er liegt jetzt direkt daneben. Ich berichte morgen um 12:00 nochmal

[PatrickR]

Hi!

Vielleicht nochmal eine Erläuterung, wie die Batterieabfrage organisiert ist:
2 Minuten nach dem Start und dann (Default) alle 6 Stunden erfolgt eine Batterieabfrage.
Es werden alle Tags abgefragt, die alle der folgenden Voraussetzungen erfüllen:

• Mindestens ein Client (FHEM/collectord) ist mit lepresenced verbunden und interessiert sich für die Mac-Adresse des Tags
• Der Tag ist exakt zum Zeitpunkt der Abfrage present.

Auch dann kann die Batterieabfrage noch fehlschlagen, wenn zwar die Beacons ankommen, aber keine stabile Verbindung möglich ist.

Wenn es immer noch nicht funktioniert den Log Level auf LOG_DEBUG setzen. Eine erfolgreiche Batterieabfrage sieht dann so aus:

Code Auswählen Erweitern


Aug 22 14:10:18 rpi-flur lepresenced[5068]: [tid:0] main: Version 0.93dev18 started (device: hci0, listen addr: 0.0.0.0, listen port: 5333, daemonize: 1, legacy mode: 0, rssi threshold: 10, battery interval: 6, log level: 7, debug: 0).
Aug 22 14:12:19 rpi-flur lepresenced[5077]: [tid:0] main::battery_task: Starting battery task, 3 reachable device(s) to query...
Aug 22 14:12:22 rpi-flur lepresenced[5077]: [tid:0] main::get_battery_level: gatttool (mac: 11:11:11:11:11:11, address type: 'public'): 'handle: 0x0028 #011 value: 64 '
Aug 22 14:12:22 rpi-flur lepresenced[5077]: [tid:0] main::battery_task: Battery level for mac 11:11:11:11:11:11 is 100.
Aug 22 14:12:24 rpi-flur lepresenced[5077]: [tid:0] main::get_battery_level: gatttool (mac: 22:22:22:22:22:22, address type: 'public'): 'handle: 0x001b #011 value: 64 '
Aug 22 14:12:24 rpi-flur lepresenced[5077]: [tid:0] main::battery_task: Battery level for mac 22:22:22:22:22:22 is 100.
Aug 22 14:12:27 rpi-flur lepresenced[5077]: [tid:0] main::get_battery_level: gatttool (mac: 33:33:33:33:33:33, address type: 'public'): 'handle: 0x001b #011 value: 64 '
Aug 22 14:12:27 rpi-flur lepresenced[5077]: [tid:0] main::battery_task: Battery level for mac 33:33:33:33:33:33 is 100.
Aug 22 14:12:29 rpi-flur lepresenced[5077]: [tid:0] main::battery_task: Battery task completed.
Aug 22 20:12:30 rpi-flur lepresenced[5077]: [tid:0] main::battery_task: Starting battery task, 1 reachable device(s) to query...
Aug 22 20:12:32 rpi-flur lepresenced[5077]: [tid:0] main::get_battery_level: gatttool (mac: 11:11:11:11:11:11, address type: 'public'): 'handle: 0x0028 #011 value: 64 '
Aug 22 20:12:32 rpi-flur lepresenced[5077]: [tid:0] main::battery_task: Battery level for mac 11:11:11:11:11:11 is 100.
Aug 22 20:12:34 rpi-flur lepresenced[5077]: [tid:0] main::battery_task: Battery task completed.

Man sieht Folgendes:

• Um 14:10 wird lepresenced gestartet
• 2 Minuten später wird das erste Mal der battery_task gestartet, dann 6 Stunden später.
• Beim ersten Aufruf des battery_tasks sind drei Geräte in FHEM definiert und present. Die Abfragen sind jeweils erfolgreich und ergeben 100%
• Beim zweiten Aufruf nach 6 Stunden ist nur ein Gerät definiert und present. Die Abfrage ergibt wieder 100%

Patrick

[Jamo]

Hallo Patrick, battery_level läuft!! Hammer! Ein RIESEN Danke nochmal von mir und auch von allen!

[FunkOdyssey]

Ich verfolge den Thread nun schon seit ein paar Tagen und habe die letzten vier Version auch immer eingespielt.
Irgendwie läuft das nicht so ganz verlässig. Mit der 0.92 werden mir die Mac-Adressen direkt angezeigt. Mit der 0.93dev18 kommt nichts an.

Code Auswählen Erweitern

Starte lepresenced

[tid:0] main: Version 0.93dev18 started (device: hci0, listen addr: 0.0.0.0, listen port: 5333, daemonize: 0, legacy mode: 0, rssi threshold: 10, battery interval: 6, log level: 7, debug: 0).
[tid:0] main::sanity_check: md5 digest of '/opt/lepresenced' is: '5d73a534650340199bd0de9381a48f3b'.
[tid:0] main::sanity_check: hciconfig found at '/bin/hciconfig'.
[tid:0] main::sanity_check: hcitool found at '/usr/bin/hcitool'.
[tid:0] main::sanity_check: gatttool found at '/usr/bin/gatttool'.
[tid:0] main::sanity_check: hcidump found at '/usr/bin/hcidump'.
[tid:1] main::bluetooth_scan_thread: Received 'Set scan parameters failed: Input/output error', resetting...
[tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...
[tid:0] main::stats_task: Active clients: 0, known devices: 7 (min/max age: 0/1), received beacons (hcitool/hcidump/difference): 1664/1664/0
[tid:0] main::battery_task: Skipping battery task, no devices to query.
[tid:0] main::stats_task: Active clients: 0, known devices: 8 (min/max age: 0/5), received beacons (hcitool/hcidump/difference): 3479/3479/0


Ich habe aber definitiv schon einmal die Geräte mit den 0.93er-Versionen gesehen. Ich habe aber Probleme, dies zu rekonstruieren.

Ich beobachte weiter.

Nachtrag 1:
10 Minuten später wurde ein Device gefunden. Das war bei der 0.92 direkt nach dem Start.
Ein zweites Device weigert sich vehement in 0.93. Und ich weiß nicht wieso.

Nachtrag 2:
Ich kann das reproduzieren. Ich hatte schon das Vertrauen in meinem eigenen GTag verloren.
Tatsächlich wird dieser in 0.92 direkt angezeigt. In 0.93 gar nicht mehr. Dies war in den Betas vorher aber auch schon einmal anders.

Nachtrag 3:
Ich lasse gerade den Debug-Modus laufen. In der Liste der "Known Devices" sind alle Mac-Adressen enthalten. Ist diese Info wichtig?

[MadMax-FHEM]

Hallo,

habe nun auch mal lepresenced V0.93dev18 "installiert"
("sicherheitshalber" auch mal libreadonly-perl)

SUPER!

Also Anwesenheit (bislang) "ohne Befund"...
...und Batteriewert endlich auch!!

Hatte ich bislang weggelassen, weil mir das "zu kompliziert" war...
...ich merke ja, wenn die Abwesenheit "zickt" und dann wäre das Erste gewesen mal nach den Batterien zu schauen...

So ist das nat. VIEL BESSER!

Also: vielen Dank!

Gruß, Joachim

[PatrickR]

Hi!

Hatte ich bislang weggelassen, weil mir das "zu kompliziert" war...
...ich merke ja, wenn die Abwesenheit "zickt" und dann wäre das Erste gewesen mal nach den Batterien zu schauen...

Ich hatte mich aus den gleichen Gründen und weil die Bluetooth-Implementierung immer noch sehr launisch ist immer dagegen gewehrt, bis ich mich dann mal über einen überraschend leeren G-Tag geärgert habe

Grüße
Patrick

[PatrickR]

Hi!

Ich verfolge den Thread nun schon seit ein paar Tagen und habe die letzten vier Version auch immer eingespielt.
Irgendwie läuft das nicht so ganz verlässig. Mit der 0.92 werden mir die Mac-Adressen direkt angezeigt. Mit der 0.93dev18 kommt nichts an.

Eigentlich habe ich an dem Scan an sich nichts Dramatisches geändert. Bis zum ersten Batteriescan, d. h. bis 2 Minuten nach dem Start sollte alles wie vorher sein. Da ich aber den Code etwas umstrukturiert habe, könnte es evtl. doch ein Problem geben. Das halte ich aber nicht für sehr wahrscheinlich.

Nachtrag 3:
Ich lasse gerade den Debug-Modus laufen. In der Liste der "Known Devices" sind alle Mac-Adressen enthalten. Ist diese Info wichtig?

Der Debug-Modus ist definitiv hilfreich, und noch mehr die Known Devices.

Da sind aber die Details wichtig. Hinter jedem Gerät werden zwei "ages" angegeben: Die Zeit in Sekunden seit dem letzten und vorletzten empfangenen Beacon. Beide Zeiten müssen unterhalb der in FHEM eingestellten Schwelle sein (z. B. 60s). Bei meinen G-Tags sind die immer beide unter 5s. Wenn Du die Ausgabe mal postest, kann ich es mir mal ansehen.

Was steht denn in den PRESENCE-Instanzen in FHEM wenn das Problem auftritt? absent oder disconnected?

Patrick

[FunkOdyssey]

Irgendetwas passt bei mir nicht.
Ich bin mir nicht mehr sicher, ob du meine Worte oben Glauben schenken kannst.
Auch mit 0.92 hatte ich gerade das Problem, dass die Gtags nicht mehr online gingen.

Die Presence-Devices stehen dann immer auf DISCONNECTED.

Code Auswählen Erweitern



Known devices (27):
...
mac: 7c:2f:80:c3:xx:xx, ages:  2/ 4, rssi: -67, name: Gigaset G-tag, battery: unknown
mac: 7c:2f:80:c3:xx:xx, ages:  0/ 0, rssi: -76, name: Gigaset G-tag, battery: unknown

Received beacons (hcitool/hcidump): 67931/67795, difference: 136


[PatrickR]

Hi!

Irgendetwas passt bei mir nicht.
Ich bin mir nicht mehr sicher, ob du meine Worte oben Glauben schenken kannst.

Warum sollte ich Dir nicht glauben. Das hätte sich weiter oben viel mehr gelohnt, wo es bei keinem funktioniert hat außer bei mir

Auch mit 0.92 hatte ich gerade das Problem, dass die Gtags nicht mehr online gingen.
Die Presence-Devices stehen dann immer auf DISCONNECTED.

Aha!
DISCONNECTED bedeutet, dass die PRESENCE-Instanz in FHEM nicht mit lepresenced verbunden ist. Das erklärt auch, warum die Geräte bei lepresenced bekannt sind. Wenn Du lepresenced neu startest bricht die Verbindung von FHEM ab, erholt sich aber irgendwann(!) wieder - je nach Timing früher oder später. Wenn Du darauf nicht warten willst einfach in der PRESENCE-Instanz in FHEM auf "DEF" klicken und dann auf direkt auf den "modify $GERÄTENAME" Button. Dann baut er sofort eine neue Verbindung auf. Wenn das passiert ist, geht der Status in FHEM entweder auf present oder absent.

Code Auswählen Erweitern


Known devices (27):
...
mac: 7c:2f:80:c3:xx:xx, ages:  2/ 4, rssi: -67, name: Gigaset G-tag, battery: unknown
mac: 7c:2f:80:c3:xx:xx, ages:  0/ 0, rssi: -76, name: Gigaset G-tag, battery: unknown

Received beacons (hcitool/hcidump): 67931/67795, difference: 136


Besser gehts nicht. Alles prima. Die Batteriewerte kommen dann auch wenn Du direkt nach dem Start die Verbindung aus FHEM herstellst (s. o.).

Grüße
Patrick

[FunkOdyssey]

DISCONNECTED bedeutet, dass die PRESENCE-Instanz in FHEM nicht mit lepresenced verbunden ist. Das erklärt auch, warum die Geräte bei lepresenced bekannt sind. Wenn Du lepresenced neu startest bricht die Verbindung von FHEM ab, erholt sich aber irgendwann(!) wieder - je nach Timing früher oder später. Wenn Du darauf nicht warten willst einfach in der PRESENCE-Instanz in FHEM auf "DEF" klicken und dann auf direkt auf den "modify $GERÄTENAME" Button. Dann baut er sofort eine neue Verbindung auf. Wenn das passiert ist, geht der Status in FHEM entweder auf present oder absent.

Ab und zu kann ich mit dem DEF-Button die Geräte in FHEM zum Leben erwecken. Aber es scheint, als könnte ich immer nur ein Gerät anzeigen lassen.

Ich habe in FHEM zwei PRESENCE-Devices, die seit Jahren fehlerfrei gearbeitet haben.

Gerade habe ich auf der Bash einen LEScan gemacht. Ich musste aber zuvor, das HCI-Device freischalten.

Code Auswählen Erweitern

hciconfig hci0 down
hciconfig hci0 up

Im LEScan werden mir natürlich auch alle Geräte angezeigt.

Nur bekomme ich scheinbar nie beide PRESENCE-Geräte online.

Nachtrag: Es ist wirklich so. Ich habe gerade die Mac-Adressen in FHEM gefälscht und direkt danach kam das zweite Geräte online (nach DEF-Button). Aber immer nur eines.

[FunkOdyssey]

STOP. Kommando zurück für alles.

Ich habe ein DNS-Problem in meinem Netzwerk.
Ich habe die PRESENCE-Devices auf IP umgestellt und schon ist alles wieder wie zuvor.

Es tut mir leid, dass ich dich damit beschäftigt habe.

[dkreutz]

Version dev18 nach 24h:
1. Reboot tut gut
2. ein Tag funktioniert prima inkl. battery_level
3. beim anderen Tag funktioniert zwar presence, battery_level wird aber nicht aktualisiert, Reading Timestamp von vorgestern

[PatrickR]

Version dev18 nach 24h:
1. Reboot tut gut
2. ein Tag funktioniert prima inkl. battery_level
3. beim anderen Tag funktioniert zwar presence, battery_level wird aber nicht aktualisiert, Reading Timestamp von vorgestern

Ihre Stimme wurde gezählt.
Im Ernst: Ohne Log mit LOG_DEBUG kommen wir nicht weiter.

Patrick

[Jamo]

Hallo dkreutz,
mach mal probehalber einen Batteriewechsel bei deinem G-Tag, und warte mal 24h. Ich hatte das gleiche bei einem meiner G-Tags (presence erkannt, battery_level nicht), Nach dem Batteriewechsel war alles gut.