battery / batteryLevel / ... -> Vereinheitlichen

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

Vorheriges Thema - Nächstes Thema

CoolTux

Vielleicht kann man für sie kommenden Developer und natürlich auch für die bestehenden einfach mal eine Vereinheitlichung im Wiki Developer EMPFEHLEN
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

Markus M.

Wie wäre es erst mal mit dem kleinsten gemeinsamen Nenner?!

Ein Reading battery mit zwei Zuständen ok und low
Sobald ein Gerät Batterie- oder Akkustand zurückgibt, wird das entweder gemappt oder das Reading wird im Modul berechnet.
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

zap

Ein einheitliches Battery Reading kann man sich ja heute auch schon mit userReading bauen. Ist zwar Aufand, aber ein Workaround bis zur großen Vereinheitlichung.

Und auch das Ermitteln aller Devices mit niedrigem Batteriestand ist mit Bordmitteln bereits möglich.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

CoolTux

Zitat von: Markus M. am 08 Mai 2018, 22:22:12
Wie wäre es erst mal mit dem kleinsten gemeinsamen Nenner?!

Ein Reading battery mit zwei Zuständen ok und low
Sobald ein Gerät Batterie- oder Akkustand zurückgibt, wird das entweder gemappt oder das Reading wird im Modul berechnet.

Ich würde 2 kleinste gemeinsame Nenner nehmen
battery mit ok und low sowie batteryLevel in Prozent.
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

Amenophis86

Ich bin für jede Richtung offen, welche in Vereinheitlichung läuft. Geber aber zu bedenken, dass mit der Idee erst Mal alles auf battery ok / low zu mappen / berechnen mit mehr Arbeit verbunden ist, als erst Mal nur die Readings auf einheitliche Namen zu bringen. Daher wäre mein Vorschlag wie folgt:

1. Einigung ob batteryLevel für Prozent oder Voltage steht
2. Namentliche Vereinheitlichung der Readings battery / batteryLevel / battery[Voltage|Percent]
3. Mapping und Berechnung auf battery ok / low für alle Module

Schritt 1 und 2 können meiner Meinung nach zeitnah entstehen. Schritt 3 kann mit einigem Vorlauf erstellt werden.
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

Folgende Nachricht habe ich gerade von loescher erhalten, der hier nicht schreiben darf:

ZitatHi!

Ich darf leider im Dev.-Forum nichts schreiben, daher per PM.

Ich fände es auch sehr gut, das zu vereinheitlichen.

Evtl. könnte man neue, zusätzliche, standardisierte Readings einführen, die mit einem Präfix (z.B. STD) beginnen.
Das würde verhindern, dass bestehende FHEM Installationen davon betroffen sind.
Also z.B.:

- STDbattery: ok / low / [critical / dead] , wenn keine besseren Angaben vorhanden sind, oder gerne in Zusammenspiel mit den anderen beiden
- STDbatteryLevel: Voltwert, wenn dieser vorhanden ist
- STDbatteryPercent: Prozentwert der Batterie, wenn dieser vorhanden ist

LG,
Stephan.

gloob hat mir auch geschrieben, dass er es begrüßen würde, hier aber nicht schreiben kann. Er hatte eine Umfrage vorgeschlagen. Wobe ich persönlich bei Umfragen in nem Forum mich immer frage wie hoch man die Messlatte setzte, da bei vielen Usern erfahrungsgemäß wenige teilnehmen.

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

Vereinheitlichung finde ich gut, solange der Modulentwickler nicht gezwungen wird, was Falsches zu bauen.

Beispiel ZWave: Geraete mit der BATTERY Klasse liefern ein Byte (manche freiwillig, manche auf Anfrage), wo 0xff als "low" zu interpretieren ist, alles andere als Prozent Ladung. Laut vorherigen Vorschlag muesste ich zwei Readings anbieten:
- battery: ok falls Byte != 0xff, sonst low
- batteryPercent: Byte, falls != 0xff, N/A falls Byte==0xff
N/A war bisher nicht definiert, sollte eingefuehrt werden.

Vorschlag fuer die aktuelle Diskussion (und ich habe dabei nur meine Module im Blick, d.h. Ergaenzung ist erwuenscht):
batteryState: ok|low|N/A
batteryPercent: \d{1,2}|100|N/A
batteryVoltage: [-]\d+.\d+|N/A
Jeder dieser Readings ist optional.

Amenophis86

Ich glaube ich finde deinen Vorschlag gut. Allerdings habe ich nicht ganz verstanden was du mit N/A meinst? Soll heißen das Reading kann auch ohne Wert vorhanden sein?

Und wenn ich die Regex richtig lese dann Percent von 0-100 und Voltage mit einer Nachkommastelle und auch der Option, dass es negativ sein 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

ZitatSoll heißen das Reading kann auch ohne Wert vorhanden sein?
Nein, es kann den Wert N/A (drei Zeichen) aufnehmen, wenn man nicht weiss, was man gerade reinschreiben soll, aber man dieses Reading vorher mit einem sinnvollen Wert gefuellt hat. Kommt aus meinem ZWave-Beispiel.

ZitatPercent von 0-100 und Voltage mit einer Nachkommastelle und auch der Option, dass es negativ sein kann?
Ja, ja, ja. Das mit negativ sollten wir streichen, ist mein Denkfehler, der Gedanke an evtl. Akku laden hat mich verwirrt.

Amenophis86

Ah jetzt. Verstehe deine Denke mit N/A frage mich jedoch, ob es nicht sinnvoller ist Prozent dann eher auf 0 zu setzen, als N/A? Sonst hätten wir wieder, dass in einem Reading für Nummern ein String steht, der in bestimmten Fällen Probleme bereiten könnte. Bin aber für beide Vorschläge offen, solange es einheitlich 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...

rudolfkoenig

Zitatfrage mich jedoch, ob es nicht sinnvoller ist Prozent dann eher auf 0 zu setzen, als N/A?
Hier faengt das an, was ich mit "was Falsches bauen" bezeichne.
Ich weiss es ja nicht, ob es 0 ist, alles was ich weiss, dass der Firmware es als "low" ansieht.

Dr. Boris Neubert

Zitat von: rudolfkoenig am 10 Mai 2018, 18:30:33
Hier faengt das an, was ich mit "was Falsches bauen" bezeichne.
Ich weiss es ja nicht, ob es 0 ist, alles was ich weiss, dass der Firmware es als "low" ansieht.

Denke auch, dass es ein Reading nicht geben sollte, wenn sein Wert nie bestimmt werden kann. Damit muss dann der Verwender umgehen.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Amenophis86

Wie gesagt, stehe der Sache offen gegenüber. Mir wäre es nur wichtig, dass wir uns auf eine Sache einigen. Und wenn ich es richtig raus lese, dann geht es in die von dir vorgeschlagene Richtung.
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...

Markus M.

Mit batteryState kann ich leben.
Weniger jedoch mit dem N/A, besonders nicht bei Percentage und Voltage.

Die beiden Readings sollten immer numerisch sein. Wenn Sie nicht definiert sind, dann setzt man eben beim Daten Update einfach keinen neuen Wert oder alternativ die 0.
Hier Strings mit reinzuwerfen, erhöht die Fehleranfälligkeit um ein vielfaches.


batteryCurrent könnte dann beim Laden übrigens negativ sein, wenn irgendein Gerät tatsächlich den Entladestrom zurück gibt ;)
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

Wuppi68

als Alternative für N/A würde ich folgendes vorschlagen:

Voltage = 0
Percentage = 111

sind beides Werte die "niemals" vorkommen und noch 1 Byte
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