Ableitung von batteryState

[krikan]

Hallo Rudi!

In https://forum.fhem.de/index.php/topic,87575.0.html hatten die Developer eine Standardiserung der Readings für den Batteriestatus beschlossen. Zusammenfassung gibt es dazu in https://wiki.fhem.de/wiki/DevelopmentGuidelinesReadings. Ich hadere mit der 10_ZWave.pm-Umsetzung.

Das Thermostat Eurotronic Spirit meldet nie den Status low per Class BATTERY. Die fehlendes "low" Meldung ist mMn auch durch die Specs gedeckt. Es wird nur der Batteriestatus in % übermittelt. Der %-Wert geht bis auf 0 % herunter; das ist dann quasi das letzte Lebenszeichen des Gerätes vor "Tod". Dennoch wird batteryState als "ok" gemeldet/gesetzt. Das ist verwirrend.

Meiner Meinung nach dürfte batteryState bei 0% keinesfalls mehr als ok interpretiert werden. Die Frage ist nur ab, welchem Wert ist "low"; erst bei 0 %!?. Das Spirit meldet zwischen 10% und 15% per Class ALARM den Hinweis "Replace battery now, notificationIsOn". Ob man das verallgemeinern kann, steht in den Sternen.

Alternativ könnte man auf die "ok"-Interpretation verzichten und batteryState nur mit dem Wert "low" setzen, da nur das gemeldet wird und nie "ok". Auswertung erfordert dann aber auch Aufmerksamkeit.

Fazit: Momentan gefällt es mir nicht, habe aber keinen wirklich zufriedenstellenden Lösungsansatz. 

Gruß, Christian

Spirit battery-Readings bei 0%:

Code Auswählen Erweitern

battery               0 %            2020-02-07 00:31:27
batteryPercent    0                 2020-02-07 00:31:27
batteryState       ok               2020-02-07 00:31:27

[rudolfkoenig]

Ich erinnere mich an diese Diskussion, lustigerweise habe ich damals hier deine Beobachtung vorausgesagt:

Falls ein ZWave-Firmware-implementierer aber nicht daran denkt, den Wert low jeweils zu senden, dan wird das vom Modul auch nie gesetzt, dann steht dann halt auch fuer Percent:0 batteryState:ok

Ich bleibe dabei: als Modulmaintainer moechte ungern anfangen, einzelne Geraete/Batterie/Tauschgewohnheits-Kombinationen auszuwerten, um passende Low-Meldungen generieren, und ueberlasse das gerne dem Geraetehersteller oder dem Benutzer.

[krikan]

Jetzt habe ich eine Meinung.

Im gleichen, verlinkten Beitrag schreibst Du zuvor:

- das jeweilige Modul setzt _nur_ die Readings, die es aus den aktuellen Daten vom Geraet bestimmen kann. Konkret: niemand kann sich darauf  verlassen, welche der drei battery Readings vorhanden sind (es gibt nicht ueberall ein batteryState). Wenn das Geraet frueher ein Percent gemeldet hat, aber in der letzten Nachricht nur state, dann wird das Percent Reading nicht angefasst.

Man kann aus dem gemeldeten Prozentwert nicht den batteryState "ok" bestimmen. Der batteryState "ok" ist in der Command Class nicht definiert. batteryState "ok" ist alleine die Entwickler-Interpretation aus der Annahme, dass "low" vom Gerät gesendet werden _muss_ und wenn "low" nicht gesendet wird, sondern ein %-Wert der batteryState "ok" ist. Dem ist aber nicht so. Es gibt keine Pflicht per Command Class Battery "low" zu melden; selbst wenn einige Geräte das machen. Es ist nur definiert, dass der Batteriestand beim Senden von "low" niedrig sein muss.

Wenn man -was ich aus obigem Zitat interpretiere- nicht interpretieren will, dann darf es in ZWave kein batteryState "ok" geben, sondern nur "low". Das führt aber vermutlich beim Anwender zu erheblichen
Irritationen.
Wenn man aber schon anfängt "ok" zu interpretieren, dann sollte man auch immer interpretieren. Da wir keine allgemeingültige Schwelle zu Interpretation von "low" bezüglich des Prozentwertes kennen, bleibt nur die vorsichtigste Variante: 0% ist "low".
Denn 0% ist in den Specs so definiert:

The percentage level of 0% represents the lowest operational voltage of the device.

Das ist für mich definitiv "low".

Ich bleibe dabei: als Modulmaintainer moechte ungern anfangen, einzelne Geraete/Batterie/Tauschgewohnheits-Kombinationen auszuwerten, um passende Low-Meldungen generieren, und ueberlasse das gerne dem Geraetehersteller oder dem Benutzer.

Dann darf der Modulmaintainer auch nicht anfangen ihm passende ok-Meldungen zu generieren und sollte das dem Geratehersteller oder Benutzer überlassen. 

Fazit: Ich würde bei 0% den batteryState als "low" setzen/melden.

Gruß, Christian

PS: Standardisierung ist schwierig. Denn ohne Standardisierung würde das Problem gar nicht auftreten, denn wir hätten nur ein battery-Reading und nicht zusätzlich einen (teilweise) interpretierten batteryState

[rudolfkoenig]

Wenn man ZWave-Doku _und_ FHEM-Standard befolgt, dann wird entweder batteryPercent:X oder batteryState:low gesetzt, batteryState:ok gibt es nicht.

Ich kann aber gerne folgende Variante einbauen, damit ich nicht weiter diskutieren muss
batteryPercent: (X == 255) ? 0 : X
batteryState: (X == 0 && X == 255) ? low : ok

Widerspruch?

[krikan]

Ich kann aber gerne folgende Variante einbauen, damit ich nicht weiter diskutieren muss

Lieber wäre mir natürlich Du bist überzeugt von der Variante .
Ich sehe diese Variante als beste Kompromiss-Lösung, aber Du bleibst der Maintainer und ich komme (nachdem ich es jetzt weiß) auch mit der derzeitigen Fassung klar.

[rudolfkoenig]

Habe die Aenderung eingecheckt, aber nicht getestet: bitte um Feedback.

[krikan]

Habe mit Deiner Telegrammsimulationsvariante aus https://forum.fhem.de/index.php/topic,39270.msg314126.html#msg314126 getestet und habe noch einen Änderungswunsch    :
Ich würde bei batteryPercent zurück zur vorherigen Variante gehen

push @ret, "batteryPercent:".hex($val) if($val ne "ff");

batteryState aber so lassen wie jetzt im svn.

Manche Sensoren liefern wechselnd neben "low" auch noch (abnehmende) %-Werte abweichend von 0.

[rudolfkoenig]

Ich würde bei batteryPercent zurück zur vorherigen Variante gehen

Habs geaendert und eingecheckt.