lepresenced: Neue Testversion (lepresenced0.93dev21)

[PatrickR]

Mahlzeit!

Für die Mutigen unter Euch gibt es jetzt eine neue Vorabversion zu testen: lepresenced0.93dev13.

Neues Feature: Batterieabfrage.

Neues Kommandozeilenargument: --batteryinterval  - Intervall in Stunden, in denen die anwesenden Geräte nach ihrem Batteriestand gefragt werden.

Der Batteriestand landet dann im Reading battery_level. In battery_level_age steht dann das Alter der Messung in Stunden.

Wichtig: Beim Upgrade einer Version 0.92 oder niedriger bitte das Paket

Code Auswählen Erweitern


libreadonly-perl

installieren.

Grüße
Patrick

[dkreutz]

Zur besseren räumlichen Abdeckung laufen bei mir zwei lepresenced-Instanzen, die dann mit collectored von der FHEM-Instanz "eingesammelt" werden.

Ich stehe gerade auf dem Schlauch: wie kann ich hier das neue "--batteryinterval" integrieren...?

[PatrickR]

Hi!

Ich stehe gerade auf dem Schlauch: wie kann ich hier das neue "--batteryinterval" integrieren...?

Den Parameter musst Du beim Aufruf angeben. Das geht leichter, wenn ich das Paket aktualisiert habe. Aber Du kannst ihn auch komplett weglassen, dann wird nach zwei Minuten und dann alle 6 Stunden abgefragt. Collectord setze ich nicht selbst ein. Daher wäre interessant, ob der die Batteriewerte durchreicht.

Patrick

[dkreutz]

lepresenced0.93dev13 installiert... battery_level wird über collectored übertragen!

Langzeittest steht aus.

p.s. es wird anscheinend jetzt Readonly.pm als Abhängigkeit benötigt?

[PatrickR]

Hi!

p.s. es wird anscheinend jetzt Readonly.pm als Abhängigkeit benötigt?

Stimmt. Ich war mit dem großen Besen durch den Code gegangen und hatte bei der Gelegenheit ein paar PBPs umgesetzt.

Patrick

[PatrickR]

Neue Version im Startposting.

[Jamo]

Hallo Patrick,
doofe frage, aber muss ich dann nur den alten lepresenced unter /usr/sbin/lepresenced durch den neuen lepresenced aus diesem Startpost ersetzen? Und dann den service neu starten? Oder ist sonst noch was zu machen?

Dann würde ich deine Version gerne ausprobieren wollen. Ich habe acht ( lepresence devices (Siemens G-Tags) die ich auf 4 verschiedenen Raspi / NUC abfrage, und dann alle über einen collectord aufsammele. Im moment mache ich die Batterieabfrage getrennt über das BLETagBattery modul, das könnte ich mir dann sparen.

Danke!

[PatrickR]

Hi!

doofe frage, aber muss ich dann nur den alten lepresenced unter /usr/sbin/lepresenced durch den neuen lepresenced aus diesem Startpost ersetzen? Und dann den service neu starten? Oder ist sonst noch was zu machen?

Ja, so sollte es sein. Ggf. musst Du noch libreadonly-perl nachinstallieren (danke dkreutz für die Info).

Dass Du collectord benutzt ist auf jeden Fall auch gut, da ich ihn nicht benutze. Ich könnte mir vorstellen, dass es hier zu Phänomenen kommt, dass der der zuletzt übermittelte battery_level angezeigt wird (z. B. lepresenced1 fragt erfolgreich die Batterie ab und übermittelt 100%, lepresenced2 aktualisiert etwas später, kennt aber die Batterie nicht und schickt dann unknown.)

/Edit:
Es ist eigentlich noch schlimmer:

• lepresenced1 fragt erfolgreich die Batterie des Tags ab, meldet 100% aber erreicht den Tag über Wochen nicht zur Batterieabfrage
• lepresenced2 fragt den Tag mehrfach erfolgreich ab und der Batteriestand wird immer weniger 99%, 95% usw.

Die Folge wäre, dass in FHEM abwechselnd 100% und 95% erscheint.
Workaround: lepresenced-Instanzen zusätzlich direkt in FHEM anlegen.

Patrick

[Jamo]

Gut, mach ich heute Abend und beobachte dann das Verhalten.

Aber das ist doch alles ok so wie von Dir beschrieben, das Verhalten mit 100%/unknown/etc lässt sich alles über die sub abfangen, wo man den batterie-level über ein notify checked. Solange ein lepresenced den sinkenden richtigen batterie-level reported, weiss man das die Batterie ge-wechselt werden muss.

OK, wenn man dann nachguckt, denkt die Batterie ist leer und der level ist dann wieder auf 100%, das wäre komisch.
In dem Fall, wenn ein lepresenced den G-Tag über Tage gar nicht mehr erreicht (oder auch nur einmal nicht erreicht), kann man das dann nicht so implementieren, das der batterie-level erst gar nicht zum collectord durchgereicht wird (also quasi altes Verhalten des lepresenced ohne batterie-level)? Damit würden nur gültige batterielevel an den collectord durchgereicht.

Im Moment ist es ja so, das das BLETagModule auf einem Raspberry irgendwo in der Ecke sitzt, und ich Glueck habe wenn der einmal pro Woche bei allen GTags die batterieabfrage hinkriegt. Deswegen ist die verteilte batterieabfrage mit collectord/le-presenced ein echter Gewinn. Danke!

[PatrickR]

Hi!

OK, wenn man dann nachguckt, denkt die Batterie ist leer und der level ist dann wieder auf 100%, das wäre komisch.
In dem Fall, wenn ein lepresenced den G-Tag über Tage gar nicht mehr erreicht (oder auch nur einmal nicht erreicht), kann man das dann nicht so implementieren, das der batterie-level erst gar nicht zum collectord durchgereicht wird (also quasi altes Verhalten des lepresenced ohne batterie-level)? Damit würden nur gültige batterielevel an den collectord durchgereicht.

Man könnte natürlich ein Maximalalter angeben, bei dessen Überschreibung der lepresenced die Klappe hält. Das ist natürlich eine Krücke.

Was Du übrigens jetzt schon tun kannst: Neben dem Reading battery_level wird auch battery_level_age gesetzt, das das Alter des Levels in Stunden angibt. D. h. Du könntest in Deinem notify filtern.

Patrick

[dkreutz]

Kurzes Feedback:
V0.93dev13 hat nicht so richtig funktioniert, immer wieder absent obwohl die Tags an der gleichen Stelle liegen wie sonst auch. Battery_level war immer "unknown"

Gerade eben V0.93dev14 installiert: bisher ähnliches Verhalten wie dev13, d.h. immer wieder "absent", immerhin wurde jetzt der battery_level übertragen. Ob der Wert "100" stimmt ist fraglich, BLEtagbattery hat zuletzt "95" ermittelt.

Werde das weiter beobachten und berichten...

[PatrickR]

Hi!

Kurzes Feedback:
V0.93dev13 hat nicht so richtig funktioniert, immer wieder absent obwohl die Tags an der gleichen Stelle liegen wie sonst auch. Battery_level war immer "unknown"

Gerade eben V0.93dev14 installiert: bisher ähnliches Verhalten wie dev13, d.h. immer wieder "absent", immerhin wurde jetzt der battery_level übertragen. Ob der Wert "100" stimmt ist fraglich, BLEtagbattery hat zuletzt "95" ermittelt.

Werde das weiter beobachten und berichten...

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

Schick mir mal bitte ein log mit LOG_DEBUG.
Welche BLE-Tags setzt Du ein?
Wie hoch ist das check-interval der PRESENCE-Instanzen in FHEM? (Hintergrund: Bei der aktuellen Implementierung ist lepresenced für den Zeitpunkt der Batteriechecks blind, d. h. die Timer laufen potenziell ab. Da die Abfragen aber sehr schnell gehen und ich nur - Ungenauigkeiten ausgenommen - erreichbare Geräte scanne, sollte das aber eigentlich vernachlässigbar sein.)

Patrick

/Edit:
Mumpitz benutzt in bletagbattery im Grunde das gleiche Verfahren wie ich, sowohl beim Abholen der Werte als auch beim Umrechnen. Er hat noch Zusatzfunktionalität, um auch bei Geräten mit random Adressschema eine Antwort zu bekommen. Unterschiedliche Werte sollten also nicht angezeigt werden.

[Jamo]

Hallo Patrick,
Gerade eben V0.93dev14 auf 2 meiner 4 Einplatinenrechner (1xIntel NUC - Schlafzimmer, 1x Raspi - Wohnzimmer) installiert
Hier das gleiche Verhalten wie beim Vorredner.
- battery_level wird übertragen (bei Mumpitz heisst es aber "batteryLevel")
- der battery_level stimmt mit dem vom Mumpitz überein also das neue battery_level = dem alten batteryLevel
- battery_level_age sehe ich auch, ist überall '0'

Aber die 2 Räume mit dem neuen lepresenced (Schlaf/Wohn) die der Collectord abholt, sind ständig absent. Die anderen beiden Räume mit dem alten lepresenced (Flur/Kueche) waren weiterhin immer present. Ich habe sogar einmal ein ''disconnect'' für den collectord bekommen.

- Siemens G-Tags
- Intervall 60 60 (also defmod Presence_GTag_collect PRESENCE lan-bluetooth AA:BB:CC:DD:EE:FF 127.0.0.1:5222 60 60)
   ja der collectord läuft auf Port 5222, lepresenced auf 5333
- die funktionierende Version ist 0.92, also lepresenced-0.92-1.deb


Ich habe jetzt erstmal zurückgeswitched.

[PatrickR]

Hi!

Ich habe jetzt erstmal zurückgeswitched.

Danke für die Fehlerbeschreibung. Das Zurückswitchen kommt für meinen Geschmack aber 5 Minuten zu früh. Ich brauche dringend ein Log mit LOG_DEBUG zum Zeitpunkt des absent.

Patrick

[PatrickR]

@Jamo:
Das Syslog bekommst Du am besten mit folgendem Befehl:
grep lepresenced /var/log/syslog

Patrick