battery / batteryLevel / ... -> Vereinheitlichen

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

Vorheriges Thema - Nächstes Thema

Markus M.

Wenn es Percent oder Voltage gibt und das Gerät sonst nichts meldet, sollte State trotzdem immer intern berechnet werden.
Wie und bei welchen Werten ist der Kreativität des Modulautors überlassen, aber ich sehe das als das wichtigste Reading der drei an, auf dessen Vorhandensein sich die User verlassen können sollten, sobald ein Gerät Infos zur Batterie meldet.

Was machen wir eigentlich mit den Geräten, die bisher 3 Zustände als ok/low/critical zurückgeben?
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

Ich stimme dir eigentlich zu, wollte aber nicht jedem Modulautor auch noch aufzwingen, dass batteryState berechnet werden muss. Denke das könnte man auch dem User mittels Userreading überlassen?

Bezüglich critical frage ich mich, ob das vom Author selbst gewählt würde, oder ob das ein Gerät überträgt. Für mich würde ok / low reichen. Wäre aber für mich kein Problem, wenn critical auf mit aufgenommen wird.
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...

justme1968

wäre es nicht schön wenn solche berechnungen die readings aus anderen ableiten zentral gesammelt werden? etwas in der art von ReadingsExtentsion analog zu den SetExtentions. dewpoint fällt mir hier als beispiel ein. es gab für die LaCrosse sensoren den wünsch die berechnung direkt im modul zu machen statt über das dewpoint modul. ich glaube es gibt noch andere sensoren die das lokal berechnen. den code nur an einer stelle zu haben wäre aber besser.

das wäre vielleicht auch etwas für die interfaces. wenn es bestimmte readings gibt kann das modul (oder der anwende) anmelden das davon abgeleitete readings automatisch berechnet werden.

für die batterie könnte es einen zentrale routine geben der man device abhängig den schwellwert konfiguriert um von Spannung oder Prozent auf Status zu kommen.


zu critical: das ein gerät zusätzliche besser aufgelöste informationen liefert als im 'standart' vorgesehen wird  immer wieder passieren. die frage ist wie geht man damit um. die werte einfach zu zu lassen widerspricht der vereinheitlichung und erschwert eine automatisch auswertung.

entweder steckt man diese zusätzlichen werte in ein internal oder ein eigenes device spezifisches reading. z.b. zusätzlich zu batteryState mit low und ok hätte diese device dann noch ein batteryStateRaw mit dem zusätzlich möglichen critical.

auch wenn es hier erst mal nur um den batterie stand geht solle das gesamt bild nicht aus den äugen verloren werden.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

Wuppi68

eine Idee zum state von Battery

batteryState: ok|low|special

wobei Special ein Platzhalter für irgendeinen Sonderzustand ist

und dann müsste der Sonderzustand vom Modul in einem anderen Reading dargestellt werden, damit der Anwender dieses auswerten kann

siehe
state = critical
@Boris: state = stale
Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

Amenophis86

Die Berechnung für alles war ja der Ursprung der ganzen Diskussion. Wollte bzw. war dabei ein Modul zu schreiben, welches alle Batterie Werte sammelt und auch mit Geräten, welche nur mit ok / low arbeiten eine Art Skala zu bauen wie lange low schon läuft und wie lange die Batterie vermutlich noch hält.

Finde den Vorschlag von Wuppi gut, aber mir sagt der von justme mit batteryRaw mehr zu. So würde es einheitlich bleiben. Und denke batteryRaw passt von der Bezeichnung auch ganz gut.
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...

justme1968

da fällt mir noch was ein: um leere batterien zu erkennen reicht es nicht auf einen staus low zu reagieren. manchmal (gar nicht so sehr selten) passiert es auch, das ein device einfach weg ist weil es noch nicht mal mehr zum senden des low reicht. das müsste man eigentlich auch berücksichtige. hat dann aber ziemliche überschneidungen mit anderen modulen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

Amenophis86

Ja, habe auch schon überlegte das auch einzubauen. Aber nach und nach, wird mein erstes Modul. Wenn wir alle Readings gleich benannt haben ist das erste Problem gelöst und dann geht es weiter ;)
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...

Wuppi68

Zitat von: justme1968 am 18 Mai 2018, 19:25:11
da fällt mir noch was ein: um leere batterien zu erkennen reicht es nicht auf einen staus low zu reagieren. manchmal (gar nicht so sehr selten) passiert es auch, das ein device einfach weg ist weil es noch nicht mal mehr zum senden des low reicht. das müsste man eigentlich auch berücksichtige. hat dann aber ziemliche überschneidungen mit anderen modulen.

die Kombi aus justme68 und wuppi68 :-)

batteryState: ok|low|special

und batteryRaw MUSS bei special gesetzt sein ansonsten ist es optional
Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

Markus M.

Zitat von: Wuppi68 am 18 Mai 2018, 20:39:11batteryState: ok|low|special
Beliebige zusätzliche Readings gerne, aber kein Wert wie special, der alles mögliche bedeuten kann.
Das macht die Sache unnötig komplex und ist wieder genau das was wir vermeiden wollen.
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

Markus M.

Ich fange jetzt einfach mal an. Ab morgen im Update:
32_withings: batteryState, batteryPercent
38_netatmo: batteryState, batteryPercent, batteryVoltage
72_XiaomiDevice: batteryState, batteryPercent
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

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

Amenophis86

Wie sieht es mit den anderen und ihren Modulen aus? Soll eine Frist gesetzt werden? Denke die endgültige Entscheidung musst du treffen Rudi, oder?
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

Ein Frist wuerde ich nicht setzen (was machen wir, wenn die Frist abgelaufen ist? wie pruefen wir, dass die Regeln nicht eingehalten wurden?), aber ich werde meine Module ASAP aendern.

papa

Kann man denn den Zugriff auf "alte" Readings irgendwie erkennen und loggen ?

Warning: Notify MYBATMON uses obsolete reading battery

Vielleicht auch mit Stacktrace. Damit wird die Migration von bestehendem Code einfacher.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Amenophis86

Zitat von: rudolfkoenig am 23 Mai 2018, 14:17:01
Ein Frist wuerde ich nicht setzen (was machen wir, wenn die Frist abgelaufen ist? wie pruefen wir, dass die Regeln nicht eingehalten wurden?), aber ich werde meine Module ASAP aendern.

Dafür kenne ich die "Regeln" der Community zu wenig, wie das gehandhabt wird :) Aber zumindest sollte es eine Ankündigung geben mit der Bitte der Umstellung. Die Idee von papa finde ich auch gut, wenn so etwas möglich ist.
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...