lepresenced: Neue Testversion (lepresenced0.93dev21)

[PatrickR]

Hi!

Meine Frage bezog sich auch weniger auf lepresenced sondern auf den Wert an sich.

Das hatte ich auch so verstanden. Habe gerade mal einen G-Tag ans Labornetzteil gehängt. Bis 3,1V meldet der Tag 100% (Auch in einer iOS-App), bei 3,0V springt der Wert dann auf 94%, was lepresenced auch richtig anzeigen würde, wenn ich nicht einen dämlichen Fehler gemacht hätte.

Neue Version im Startposting:
lepresenced0.93dev20: Unter bestimmten Umständen wurden Werte nicht angezeigt.

Grüße
Patrick

[Jamo]

Hi Patrick, runtergeladen und installiert. Läuft bisher problemlos! Alle battery_level readings wurden schon aktualisiert, alles prima. Danke!

[TL]

Moin!

Bei mir geht die Batterieabfrage jetzt auch. Was habe ich geändert? Bei meinem telnet-Device habe ich im Attribut allowfrom die Adresse 127.0.0.1 zusätzlich mit eingetragen. Kann es daran gelegen haben?

Viele Grüße
   TL

[betateilchen]

Kann es daran gelegen haben?

da die readings per Telnet gesetzt werden, gibt es eine hohe Wahrscheinlichkeit dafür.

[betateilchen]

Interessant... mit dev20 werden Batteriewerte schneller geliefert, dafür wird das G-Tag selbst nicht mehr als "present" erkannt.

Das heißt, ich bekomme für ein "absent" device immerhin einen Batteriewert Das war ein Irrtum meinerseits.

Genaugenommen: es wird keines meiner drei Tags (2 * Gtag 1*iTag) mehr als present gemeldet.

Dummerweise habe ich dev19 bereits gelöscht und kann die Verifizierung der Versionsabhängigkeit nicht weiter durchführen.



Edit:

Vermutlich bin ich wieder daran gescheitert, dass keine PRESENCE Instanz mit lepresenced verbunden war.
Offenbar ist also gar nicht lepresenced die Ursache für das Problem mit den Verzögerungen (im debug Modus werden alle Werte korrekt ermittelt), sondern PRESENCE selbst.

[Jamo]

Interessant das Du das sagst - Ich habe auch den Eindruck das die Batteriewerte mit dev20 wesentlich schneller kommen. Prima!

[PatrickR]

da die readings per Telnet gesetzt werden, gibt es eine hohe Wahrscheinlichkeit dafür.

Eigentlich nicht. Das war bei den Batterieskripten so. Aber bei lepresenced kommen die Batteriewerte auf dem gleichen Weg wie present/absent, d. h. über ausgehende Verbindungen.

[PatrickR]

@betateilchen:
Was ist denn der letzte Stand mit dev20? Klappt present/absent? Die Änderung auf dev20 ist wirklich minimal.

[betateilchen]

Es funktioniert "teilweise".

ich habe zwei Gtag - eines davon liefert presence und battery Werte. Das zweite, heute später zum laufenden FHEM hinzugekommen (also schon länger definiert, aber heute zum ersten Mal wieder "present") liefert nur presence, aber keine Batterie. Meine Vermutung: Ein Gtag, das später als 3 Minuten nach lepresenced-Start erstmalig present wird, fällt in das 6-Stunden-Raster. Die 6 Stunden sind aber noch nicht um, um das genau verifizieren zu könne.

Auch interessant: ausgerechnet das Gtag, das seit Jahren problemlos in FHEM funktionierte, wird aktuell gar nicht mehr present gefunden, obwohl es sich an der gleichen Stelle befindet wie vorher. Diesem Phänomen muss ich noch nachgehen.

[betateilchen]

Code Auswählen Erweitern


[tid:0] main::get_battery_level: gatttool (mac: 7c:2f:80:..., address type: 'public'): 'connect error: Function not implemented (38)'
[tid:0] main::battery_task: Battery level for mac 7c:2f:80:... is unknown.
[tid:0] main::get_battery_level: gatttool (mac: ff:ff:60:..., address type: 'public'): 'connect error: Connection refused (111)'
[tid:0] main::battery_task: Battery level for mac ff:ff:60:... is unknown (timeout).
[tid:0] main::get_battery_level: gatttool (mac: 7c:2f:80:..., address type: 'public'): 'connect error: Function not implemented (38)'
[tid:0] main::battery_task: Battery level for mac 7c:2f:80... is unknown.


Offenbar liefern beide gtags (7c:2f...) gar keine Batteriewerte mehr?
(Das ff:ff:... ist ein iTag, das ist normal.)



Edit: ich habe mal die Aktualisierung der Batteriewerte auf 300 Sekunden eingestellt.

Ergebnis: zwischendurch funktioniert der Abruf der Werte, meistens aber nicht.

Code Auswählen Erweitern


[tid:0] main::battery_task: Starting battery task, 2 reachable device(s) to query...
[tid:0] main::set_thread_command: Setting thread command of thread 'bluetooth_dump_thread' to 'THREAD_COMMAND_STOP'.
[tid:0] main::set_thread_command: Setting thread command of thread 'bluetooth_scan_thread' to 'THREAD_COMMAND_STOP'.
[tid:2] main::bluetooth_dump_thread: hcidump was stopped.
[tid:1] main::bluetooth_scan_thread: hcitool was stopped.
[tid:0] main::get_battery_level: gatttool (mac: 7c:2f:80:ad:...., address type: 'public'): 'connect error: Function not implemented (38)'
[tid:0] main::battery_task: Battery level for mac 7c:2f:80:ad:....3 is unknown.
[tid:0] main::get_battery_level: gatttool (mac: 7c:2f:80:a1:...., address type: 'public'): 'connect error: Transport endpoint is not connected (107)'
[tid:0] main::battery_task: Battery level for mac 7c:2f:80:a1:.... is unknown.
[tid:0] main::set_thread_command: Setting thread command of thread 'bluetooth_scan_thread' to 'THREAD_COMMAND_RUN'.
[tid:0] main::set_thread_command: Setting thread command of thread 'bluetooth_dump_thread' to 'THREAD_COMMAND_RUN'.
[tid:0] main::battery_task: Battery task completed.


Code Auswählen Erweitern


tid:0] main::battery_task: Starting battery task, 2 reachable device(s) to query...
[tid:0] main::set_thread_command: Setting thread command of thread 'bluetooth_dump_thread' to 'THREAD_COMMAND_STOP'.
[tid:0] main::set_thread_command: Setting thread command of thread 'bluetooth_scan_thread' to 'THREAD_COMMAND_STOP'.
[tid:2] main::bluetooth_dump_thread: hcidump was stopped.
[tid:1] main::bluetooth_scan_thread: hcitool was stopped.
[tid:0] main::get_battery_level: gatttool (mac: 7c:2f:80:ad, address type: 'public'): 'connect error: Function not implemented (38)'
[tid:0] main::battery_task: Battery level for mac 7c:2f:80:ad is unknown.
[tid:0] main::get_battery_level: gatttool (mac: 7c:2f:80:a1, address type: 'public'): 'handle: 0x001b      value: 64 '
[tid:0] main::battery_task: Battery level for mac 7c:2f:80:a1 is 100.
[tid:0] main::set_thread_command: Setting thread command of thread 'bluetooth_scan_thread' to 'THREAD_COMMAND_RUN'.
[tid:0] main::set_thread_command: Setting thread command of thread 'bluetooth_dump_thread' to 'THREAD_COMMAND_RUN'.
[tid:0] main::battery_task: Battery task completed.
[tid:0] main: Sending update for mac address 7c:2f:80:ad, ages: 39/39, max age: 60, rssi: -90, battery level: 94 (age: 0), result: present.
[tid:0] main: Sending update for mac address ff:ff:60:05, max age: 10, result: absence.
Known devices (8):
        mac: , ages: 805/806, rssi: -92, name: (unknown), battery: unknown
        mac: , ages: 712/713, rssi: -94, name: (unknown), battery: unknown
        mac: , ages: 41/45, rssi: -96, name: (unknown), battery: unknown
        mac: , ages: 40/40, rssi: -95, name: (unknown), battery: unknown
        mac: 7c:2f:80:a1, ages: 51/51, rssi: -94, name: Gigaset G-tag, battery: 100 (age: 2s)
        mac: 7c:2f:80:ad, ages: 39/39, rssi: -90, name: Gigaset G-tag, battery: 94 (age: 662s)
        mac: , ages: 41/41, rssi: -93, name: (unknown), battery: unknown
        mac: , ages: 807/890, rssi: -95, name: iTAG            , battery: unknown


[PatrickR]

@betateilchen:
Siehst Du im Log irgendwelche Gemeinsamkeiten der Gruppen ,,funktioniert" und ,,funktioniert nicht". Interessant könnten z. B. Fälle sein, in denen die Batteriechecks gestartet werden bevor scan/dump gestoppt wurden. Du kannst auch testweise mal die zwei SETTLE_SLEEPS oben im Code hochsetzen.

[betateilchen]

Nein, es gibt keine erkennbaren Systematiken.
Die Batteriechecks erfolgen immer, nachdem scan/dum gestoppt wurden.

Irgendwann sind die Batteriewerte in beiden Gtags vorhanden, aber es ist im Moment noch nicht vorhersehbar, wann das der Fall ist.
Da diese Werte aber für mich auch nicht zeitkritisch sind, sehe ich das Ganze nicht als dramatisches Problem an, das Verhalten ist einfach nur "merkwürdig".

[Jamo]

Hast Du mal einen Batteriewechsel probiert? Ich weiss das die ein Jahr halten, aber man weiss halt nicht wie gut die noch sind. Das kann auch ein Grund sein.

[PatrickR]

Hi!

Da diese Werte aber für mich auch nicht zeitkritisch sind, sehe ich das Ganze nicht als dramatisches Problem an, das Verhalten ist einfach nur "merkwürdig".

Merkwürdig mag ich irgendwie nicht. Ich fürchte dann immer, dass da noch was dahinter ist. Vielleicht hast du ja irgendwann mal Zeit, mit den SETTLE_SLEEPS zu experimentieren.

Grüße
Patrick

[PatrickR]

Hi!

Hast Du mal einen Batteriewechsel probiert? Ich weiss das die ein Jahr halten, aber man weiss halt nicht wie gut die noch sind. Das kann auch ein Grund sein.

Das mit dem Batteriewechsel könnte vielleicht *räusper* gar nicht nötig gewesen sein. Das war evtl. ein Bug, der mit dev20 gefixt wurde.

Patrick