battery / batteryLevel / ... -> Vereinheitlichen

Begonnen von Amenophis86, 06 Mai 2018, 19:37:18

Vorheriges Thema - Nächstes Thema

Dr. Boris Neubert

Okay, jetzt habe ich es verstanden. M.E. ist die saubere Lösung hier, die zwei Sachverhalte "FHEM-konform" (aus de-facto-Sicht bzgl. aktueller Implementierungen, der Mehrheit zumindestens nach) zu trennen:
- Batteriestand bleibt auf 15% stehen (stale)
- Batteriewarnung geht von ok auf low.

Der Batteriestand sollte aber nicht weggenommen werden (Reading weg), wenn die Batteriewarnung auf low geht. M.E. sollte jedes Modul zusichern, dass ein Reading bleibt, wenn es einmal da ist (außer von dem Sonderfall eines Modulupgrades).
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Amenophis86

Ich könnte mit der Lösung leben, weil es nun mal vom Gerät so vorgegeben wird und damit für mich ok. Wie bereits angegeben ist am Timestamp ja zu erkennen, dass sich nichts mehr verändert hat am Reading. Bleibt die Frage, ob Rudi und der Rest damit leben kann? :)
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

rudolfkoenig

   
Ich fasse zusammen
- es gibt die drei Readings batteryState, batteryPercent, batteryVoltage
- Wertebereich:
batteryState: ok|low
batteryPercent: \d{1,2}|100
batteryVoltage: \d+.\d+
- 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.


Im Fall von ZWave wird bei einer Prozentangabe batteryState:ok gesetzt, weil das implizit der Fall ist. 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

Dr. Boris Neubert

Perfekt für mich.

Und zur Sicherheit, weil's diskutiert wurde:
- mit Ausnahme des unwahrscheinlichen Falls einer Änderung des Moduls werden Readings nicht gelöscht, die schon mal mit einem Wert belegt wurden.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

HCS

Zitat von: rudolfkoenig am 17 Mai 2018, 08:39:10
Ich fasse zusammen
- es gibt die drei Readings batteryState, batteryPercent, batteryVoltage
Bedeutet das, dass in den aktuellen Modulen die momentan vorhandenen Readings umbenannt werden sollen?
Also z.B. bei 36_LaCrosse das Reading "battery", das aktuell ok/low liefert, in batteryState umbenennen?
Mit allen Konsquenzen dieses breaking change?
Oder nur für zukünftige neue Module?

CoolTux

Erstmal ist das ganze kein muss sondern eine Empfehlung um einheitlich zu werden.
zweitens kann das alte Reading bleiben aber neue Module sollten Empfehlenswerter Weise mit den neuen Readings versehen werden.

Ich persönlich finde es gut und werde es auch in meinen vorhandenen Modulen ersetzen. Das alte Reading kommt weg und die Vereinheitlichung rein.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

HCS

Zitat von: CoolTux am 17 Mai 2018, 09:48:01
Erstmal ist das ganze kein muss sondern eine Empfehlung um einheitlich zu werden.
Ja, genau das war ja die Frage, was der "offizielle" Plan ist.

Zitat von: CoolTux am 17 Mai 2018, 09:48:01
zweitens kann das alte Reading bleiben aber neue Module sollten Empfehlenswerter Weise mit den neuen Readings versehen werden.
Was dann nicht zu einer Vereinheitlichung führt sondern die Vielfalt der Readings erhöht.
Aktuell finde ich kein Modul mit einem batteryState Reading, es wird dann also Module mit battery (die bisherigen) und mit batteryState (die zukünftigen) geben.

justme1968

ich würde versuchen das etwas strenger zu handhaben und nach einer übergangszeit das einchecken von updates nur noch erlauben wenn solche regeln beachtet werden.

ja. manches (vielleicht sogar vieles) kann man nicht automatisch prüfen. aber manches schon. und selbst wenn nicht sollte man die regel trozdem aufstellen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

CoolTux

Das mit dem bleiben bezog sich auf alte Module, nicht auf neue.

Ich persönlich würde aber empfehlen einfach grade durch allles sauber zu richten in den modulen und gut ist. Wenn man den Usern etwas vorlauf gibt und ansständig informiert ist das voll ok.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Benni

Zitat von: CoolTux am 17 Mai 2018, 09:48:01
Erstmal ist das ganze kein muss sondern eine Empfehlung um einheitlich zu werden.

Na ja, dann wird's ja nie einheitlich.
"Erstmal" ok, aber mittelfristig würde ich solche Regeln schon als Verpflichtung auch für bestehende Module "erzwingen", denn sonst erzeugt man nur noch mehr Sonderlocken, die letztendlich auch niemandem nützen und für noch mehr Uneinheitlichkeit sorgen und noch mehr Verwirrung stiften.

Grundsätzlich finde ich übrigens in dem Zuge den Interface-Ansatz, den Boris weiter oben schon erwähnt (vmtl. Wiki-Link) hat auch sehr reizvoll, denn der ist letztdendlich für die "Erzwingung" wichtig, sprich will/soll ein Modul ein bestimmtes Interface liefern, dann müssen eben bestimmte Dinge (Readings/Werte/Einheiten/Getter/Setter) Interface-Konform verfügbar sein.
Das lässt sich bei einer konsequenten Vereinheitlichung der genannten Dinge vorab aber auch noch nachträglich drüberstülpen.

Wie gesagt, wenn es hier letztendlich nur bei einer Empfehlung bleibt, dann kann man sich die Mühe m.E. auch getrost sparen.

Und zum Konkreten Fall der Batterizustände, ist doch eigentlich nur relevant zu wissen, welchen Zustand hat meine Batterie (Bspw.: empty/critical/ok/unknown). Denn ich muss doch eigentlich nur ermitteln können, ob und ggf. wann (demnächst) ich die Batterie wechseln muss. Ob ein Modul vom echten Gerät dazu die Batteriespannung erhält und Auswertet, oder ob ein Porzentwert geschätzt wird oder evtl. sogar übertragen wird ist doch dabei unerheblich. Vereinheitlicht weden müsste doch nur, das was das Modul zur Auswertung für den konkreten Use-case bereitstellt.
Die tatsächliche Batteriespannung oder ein Prozentwert oder was auch immer sind zwar "nice to have" aber nicht das was man für die Batterieüberwachung braucht.

Das waren meine 2Ct.

Gruß Benni.

Markus M.

Zitat von: Dr. Boris Neubert am 17 Mai 2018, 09:13:27- mit Ausnahme des unwahrscheinlichen Falls einer Änderung des Moduls werden Readings nicht gelöscht, die schon mal mit einem Wert belegt wurden.

Mache ich aktuell an mehreren Stellen:
Der Xiaomi Staubsauger hat eine History der Reinigungsvorgänge.
Die lege ich in einzelnen Readings history_0, history_1 usw. ab. Wenn sie nicht mehr existieren, werden sie gelöscht.

Einige Geräte haben auch 0-n interne Timer.
Auch hier wird über mehrere Readings durchnummeriert mit timer_1_days, timer_1_hour und so weiter. Dabei wird dann sogar noch die Setlist entsprechend der gerade vorhandenen Readings aktualisiert.

Beides ist eigentlich nur dazu gedacht, via FHEMWEB die Settings möglichst bequem nachzubilden. Nicht zur Weiterverwendung.

Was mache ich damit? Jemand ne Idee?
Stehen lassen kann ich die einzelnen Readings nicht, sie zusammenzufassen wäre so unübersichtlich dass ich sie dann lieber ganz weglassen würde.
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7590/7580/546E

HM Aktor/Sensor/Winmatic/Keymatic/Thermostat, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony, Siro ERB15LE
https://paypal.me/mm0

justme1968

ich denke wir brauchen auch einen (besseren) ansatz zum löschen (und umsortieren) der readings. für dein beispiel, für das anrufbeantworter beispiel von weiter oben und bestimmt noch andere.

wichtig ist das frontends davon etwas mitbekommen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Dr. Boris Neubert

Readings löschen....

Ich bezog mich auf die Batterie. Die grundsätzliche konzeptionelle Frage würde ich gerne parken. Gibt es einen Platz im Wiki dafür oder soll ich den anlegen?
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Markus M.

Zitat von: Dr. Boris Neubert am 17 Mai 2018, 12:49:10
Readings löschen....
Ich bezog mich auf die Batterie
Hatte ich falsch verstanden, dann ist erst mal alles gut :)
Namen und gültige Werte sollten ins Wiki.
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7590/7580/546E

HM Aktor/Sensor/Winmatic/Keymatic/Thermostat, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony, Siro ERB15LE
https://paypal.me/mm0

Amenophis86

Zitat von: rudolfkoenig am 17 Mai 2018, 08:39:10
Ich fasse zusammen
- es gibt die drei Readings batteryState, batteryPercent, batteryVoltage
- Wertebereich:
batteryState: ok|low
batteryPercent: \d{1,2}|100
batteryVoltage: \d+.\d+
- 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.

Korrekt. Würde es wie folgt Ergänzen:
- Es gibt keine Pflicht für das Reading batteryState, wäre aber wünschenswert es zu haben, wenn etwas von der battery gemeldet wird und intern berechnet wird
- Bis zum 01.08 (Datum ist ein Vorschlag) können alte Readings bestehen bleiben und auch schon die neuen Readings vorhanden sein, ab dann nur noch die oben genannten drei
- Bezüglich des Interface und Readings löschen gehen wir in eine neue Diskussion bzw. parken es, wie von Boris vorgeschlagen

Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...