battery / batteryLevel / ... -> Vereinheitlichen

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

Vorheriges Thema - Nächstes Thema

Amenophis86

Ich bin gerade dabei ein Modul zu entwickeln, welches automatisch einen Wechsel der Batterien erkennen soll. Dabei prüfe ich verschiedene Module auf das Reading battery / batteryLevel etc. Mir ist aufgefallen, dass es hier keine einheitliche Struktur gibt. Bisher habe ich folgende Readings gefunden:
- battery (viele Module)
- batteryLevel (viele Module)
- battery_level ([Xiaomi Smart Home] Das Modul)
- battery-level (GardenaSmartDevice)
- batteryPercent (HOMBOT)
- (Zahl.)BATTERY_STATE (HMCCUDEV)

Weiterhin verstecken sich in den Readings selbst wieder verschiedene Werte. Gleiche Werte können in verschiedenen Readings stecken. Ich habe gefunden:
- ok
- low
- critical
- Prozentwerte (mit % und ohne)
- Voltwerte

Ich würde daher gerne folgendes vorschlagen, damit es einheitlich ist:
- battery: ok / low / critical, wenn keine besseren Angaben vorhanden sind, oder gerne in Zusammenspiel mit den anderen beiden
- batteryLevel: Voltwert, wenn dieser vorhanden ist
- batteryPercent: Prozentwert der Batterie, wenn dieser vorhanden ist
- Keine Angabe von irgendwelchen Einheiten, wie % oder ähnliches in den Readings

Ist jetzt natürlich nichts, was FHEM extrem weiterbringt, oder besonderen Einfluss hat. Ich finde jedoch, dass es einfach ein weiterer Punkt ist, welcher ein Vereinheitlichung in FHEM bringt.

Edit:
Weitere Readingsnamen und das entsprechende Modul hinzugefügt
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...

Dr. Boris Neubert

Ich bin ein großer Fan der Vereinheitlichung und gleiches gleich zu benennen.

Ich befürchte aber, dass wir in der Minderheit sind. Umbenennen ist ein breaking change.

Kannst Du bitte eine Liste aller Module posten nebst Maintainern, wo das vorkommt?
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Loredo

Ich vermute, dass du mit deinem Vorhaben keinen Erfolg haben wirst. Ein Grund dafür wäre allein schon, dass die im Feld befindlichen Module ihre interne Logik nicht ändern können, ohne dass bestehende Konfigurationen von Usern beeinträchtigt würden und diese wiederum ihre eigenen Automationslogiken abändern müssten.


Die Lösung dafür wäre wohl eine Zwischenschicht einzuführen. Unter anderem sollte das auch von Unit.pm übernommen werden: Konvertierungen zwischen Einheiten sind da genauso vorgesehen wie die Abstraktion zur Anzeige. Auch die Umwandlung zwischen Zahlenwerten und Logikwerten ist vorgesehen.


Siehe auch:
https://forum.fhem.de/index.php/topic,60285.0.html


Ich habe aber bei der Entwicklung nicht sonderlich viel Zuspruch oder Unterstützung erfahren, weshalb sich da seit einer ganzen Weile auch nichts mehr bewegt hat. Rudi sieht generell wenig Sinn in solchen pedantisch wirkenden Verbesserungen.  :-\


Vielleicht möchtest du den Ball hier wieder aufnehmen, ich diskutiere da gerne mit und erläutere auch bei echtem Interesse gerne nochmals meine bisherigen Gedanken und den aktuellen Entwicklungsstand. Aber es sollte schon nicht alles für die Katz sein...
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Dr. Boris Neubert

Danke. Jetzt fühle ich mich nicht mehr ganz so einsam.

Das Konzept heißt Interfaces, und wurde vor Jahren von mir vorgestellt, fand gewissen Zuspruch, aber umgesetzt haben wir es nie. Im Wiki könnte die Idee noch als Leiche liegen.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Sidey

Hi,

ich finde die Idee auch gut.
Würde mich mit meinen Teilen auch beteiligen.

Es müssten halt noch ein paar mehr Guidelines her. z.B. senden ja viele Sensoren nur OK oder nicht ok.
Das müsste man dann auch einheitlich zuordnen, sonst ist es bei dem einen critical oder eben auch nicht.

Denkbar wäre natürlich auch, dass critical gesetzt wird wenn z.B. 1 Tag lang nichts mehr empfangen wurde.


Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Markus M.

#5
Zitat von: Amenophis86 am 06 Mai 2018, 19:37:18
- battery: ok / low / critical, wenn keine besseren Angaben vorhanden sind, oder gerne in Zusammenspiel mit den anderen beiden
Das sollten die meisten Module mit ok/low haben, teilweise intern berechnet (welche Module verwenden überhaupt critical?)

Zitat- batteryLevel: Voltwert, wenn dieser vorhanden ist
Eher nein, da das wahrscheinlich bei den meisten Modulen die Prozentanzeige ist - zumindest bei meinen (und ich keine Lust habe das umzubenennen :)

Zitat- batteryPercent: Prozentwert der Batterie, wenn dieser vorhanden ist
batteryVoltage stattdessen (s.o.), was aber sofern zusätzlich zum Level vorhanden eigentlich relativ sinnlos ist, da die Spannung ohne komplexe Berechnungsorgien je Gerät nicht viel aussagt.
Welche Einheit? mV? V?

Zitat- Keine Angabe von irgendwelchen Einheiten, wie % oder ähnliches in den Readings
Das sollte eigentlich für alle Readings gelten, immer.


Zitat von: Loredo am 06 Mai 2018, 20:13:30Ein Grund dafür wäre allein schon, dass die im Feld befindlichen Module ihre interne Logik nicht ändern können, ohne dass bestehende Konfigurationen von Usern beeinträchtigt würden und diese wiederum ihre eigenen Automationslogiken abändern müssten.
Das kommt ganz auf die Skrupel der Entwickler an ;)

Zitat von: Sidey am 06 Mai 2018, 20:47:12
Denkbar wäre natürlich auch, dass critical gesetzt wird wenn z.B. 1 Tag lang nichts mehr empfangen wurde.
Sehe ich in einem anderen Reading, z.B. active = dead
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

betateilchen

Und dann gibt es da noch Homematic devices, bei denen sowohl ein Reading "battery" (mit "ok") als auch "batteryLevel" (mit einer Spannungsangabe) gleichzeitig vorhanden sein können...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Markus M.

Zitat von: betateilchen am 06 Mai 2018, 21:24:18
Und dann gibt es da noch Homematic devices, bei denen sowohl ein Reading "battery" (mit "ok") als auch "batteryLevel" (mit einer Spannungsangabe) gleichzeitig vorhanden sein können...
Ah, Homematic war das.
Da landet der Akkustand zumindest beim Akku Device des HM-Sec-Win auch einfach nur im state Reading.


Im Prinzip brauchen wir also 3 Readings:
- battery mit ok/low
- eines für die Prozentangabe 0..100
- eines für die Spannung in Volt

Ich sag jetzt einfach mal:
Wenn ihr es schafft was festzulegen was dann für alle verbindlich ist, passe ich meine Module gerne daran an.
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: Dr. Boris Neubert am 06 Mai 2018, 20:07:33
Kannst Du bitte eine Liste aller Module posten nebst Maintainern, wo das vorkommt?

AMAD:
powerLevel - state of battery in %

CUL_HM:
battery:[critical|low|ok]
batteryLevel $bat V

CUL_TCM97001:
battery: The battery state: low or ok (if available)

EnOcean:
battery: unknown|low|ok
battery: full|ok|low|empty
battery: U/V (Range: U = 0 V ... 3.3 V
battery: ok|low|empty|-  => Room Control Panels

GardenaSmartDevice
battery-level - load percentage of the Battery

Homebot:
batteryPercent - Battery status in percent %

Hideki
battery (ok or low)

KOSTALPIKO
Battery.StateOfCharge - State of charge for the battery in percent
Battery.Voltage - the voltage of the battery

LaCrosse
battery[] ok or low

Level
voltage - Measured battery voltage

MAX
battery ??

NUKIDevice
batteryCritical - Is the battery in a critical state? True, false
battery - battery status, ok / low

MiPow Playbulb
powerLevel - percentage of batterylevel

Weather Sensors various protocols
battery: (low or ok)

SMAInverter
BAT_UDC / bat_udc : Battery Voltage
BAT_IDC / bat_idc : Battery Current

TRX_SECURITY
battery: low / ok

Tesla Powerwall 2 AC
batteryLevel - battery level in percent
batteryPower - battery capacity in kWh

WMBUS - Wireless M-Bus
battery contains ok or low.

Xiaomi BTLE Sensor
battery - current battery state dependent on batteryLevel.
batteryLevel - current battery level in percent.

Xiaomi Flower Monitor
battery - current battery state dependent on batteryLevel.
batteryLevel - current battery level in percent.

ZWave
battery - return the charge of the battery in %, as battery:value % or battery:low
Class BATTERY - battery:chargelevel %

pilight_temp
battery - present the battery state of the senor (if sensor support it)

withings
battery
batteryLevel

[Xiaomi Smart Home] Das Modul
battery_level

HMCCUDEV
(Zahl.)BATTERY_STATE
--------------------------------------

Das sind jetzt mal alle Daten aus der CommandRef, oder aus dem Forum was ich zu battery gefunden habe. Wie ihr seht alles durcheinander. Mir persönlich ist es egal, ob wir batteryLevel für Voltwerte nehmen und dann batteryPercent, oder ob wir batteryLevel für Prozent und batteryPower für Voltwerte nehmen. Aber ich denke auf drei Readings sollten wir uns einigen. Auch sollte meiner Meinung nach in battery maximal ok / low stehen. Dead und cirtical sehe ich dort eigentlich nicht, aber das ist nur meine Meinung. Daher hier nochmal mein Ursprungsvorschlag:

1. Drei Readings
- battery: ok / low / [critical / dead] , wenn keine besseren Angaben vorhanden sind, oder gerne in Zusammenspiel mit den anderen beiden
- batteryLevel: Voltwert, wenn dieser vorhanden ist
- batteryPercent: Prozentwert der Batterie, wenn dieser vorhanden ist

2.
- Keine Angabe von irgendwelchen Einheiten, wie % oder ähnliches in den Readings

3. (Mir nicht wichtig, aber eine Idee)
- Das Modul kann battery gerne selbst berechnen und ok / low / critical / dead angeben
- Wenn möglich sollte das Modul Prozentwerte oder Voltwerte im entsprechenden Reading angeben, damit der User entsprechend reagieren kann


Zitat von: Loredo am 06 Mai 2018, 20:13:30
Ich vermute, dass du mit deinem Vorhaben keinen Erfolg haben wirst. Ein Grund dafür wäre allein schon, dass die im Feld befindlichen Module ihre interne Logik nicht ändern können, ohne dass bestehende Konfigurationen von Usern beeinträchtigt würden und diese wiederum ihre eigenen Automationslogiken abändern müssten.
Das kann in meinen Augen kein Argument sein, dann müsste FHEM immer auf einem Stand bleiben. Man kann ja gerne mit einer Übergangsfrist arbeiten, aber ich denke auf lange Sicht ist es nur hilfreich, wenn alles gleich ist. Und an die Internelogik will ich ja eigentlich nicht komplett ran.

Zitat von: Sidey am 06 Mai 2018, 20:47:12
Es müssten halt noch ein paar mehr Guidelines her. z.B. senden ja viele Sensoren nur OK oder nicht ok.
Das müsste man dann auch einheitlich zuordnen, sonst ist es bei dem einen critical oder eben auch nicht.

Denkbar wäre natürlich auch, dass critical gesetzt wird wenn z.B. 1 Tag lang nichts mehr empfangen wurde.
Glaube das ist auch sehr Geräte abhängig, was genau übermittelt wird. Das würde ich dann dem User überlassen, ob er bei low direkt die Batterie wechseln muss, oder noch wartet. Zum Beispiel soll in meinem Modul dem User die entsprechende Möglichkeit gegeben werden für die Device die Wartezeit per Attr anzupassen.


Zitat von: betateilchen am 06 Mai 2018, 21:24:18
Und dann gibt es da noch Homematic devices, bei denen sowohl ein Reading "battery" (mit "ok") als auch "batteryLevel" (mit einer Spannungsangabe) gleichzeitig vorhanden sein können...
Das finde ich persönlich ok, wobei mir immer die Detailangabe in Form von Prozent oder Voltage lieber wäre, aber manch einer schaut vielleicht nur auf battery und nicht die Details.
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...

betateilchen

#9
Zitat von: Amenophis86 am 07 Mai 2018, 15:52:36
CUL_HM:
battery:[critical|low|ok]
batteryLevel $bat V

Wenn ich mich recht erinnere, gibts da noch ein paar mehr.

Grundsätzlich bin ich auch dagegen, an dieser Stelle etwas ändern zu wollen. Es wird mit ziemlicher Sicherheit keine Lösung zu finden sein, die


  • alle Eventualitäten abdeckt
  • abwärtskompatibel zu bestehenden Installationen ist
  • in Anbetracht der vielen Threads, WIKI-Einträge und anderen Veröffentlichungen, in denen es um Batteriewerte in FHEM geht, sinnvoll wäre, ohne eine Unmenge von "aber das steht doch da und da..." hervorzurufen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

CoolTux

Ich wäre auch für eine Vereinheitlichung. Muss dann halt nur im Developerbereich im Wiki feststehen.
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 kann dich verstehen betateilchen, aber wenn man mal ehrlich ist, dann haben die ganzen Wikieinträge etc. bis heute gar nicht alles erfasst was battery bezogen ist. Können sie ja auch gar nicht bei dem Chaos. So ziemlich alle Beispiele arbeiten alleine mit dem battery Reading und dann auch fast immer nur mit ok / low. Der Änderungsaufwand an sich sollte nicht ein Hinderungsgrund sein. Ich finde nur, wenn wir Anfangen nach und nach Standards festzulegen wird FHEM nicht wie Kraut und Rüben weiter wachsen, sondern struktuiert.
An vieles, wie zB die Sache mit battery, hat man zu Beginn sicher nicht gedacht. Jetzt kann man es so lassen und sagen, "joa dann ist es halt so", oder man macht einmal ein Schnitt und sagt bitte ändert es. Und ehrlich gesagt ist es gar nicht so viel was geändert werden muss. Oft muss nur der Readingname angepasst werden. Wenn vorher batteryLevel für Volt stand, dann ändert man es nun auf batteryVoltage analog für Prozent, für was man sich am Ende halt entscheidet. Die Berechnung im Hintergrund auf ok / low zB kann ja bestehen bleiben.
Gleiches sehe ich mit den Gruppen für Attribute. Ich bekomme bei manchen Modulen einen Anfall, wenn ich ewig nach dem Attr suchen muss, weil es zB nicht in Gruppen sortiert ist, oder einen Prefix hat. Aber das ist ein anderes Thema, welches hier ja schon aufgegriffen wurde.

Gleiches gilt für das Argument abwärts Kompatibel. Nicht jede Änderung sollte immer den Anspruch haben abwärts Kompatibel zu sein. (Meiner Meinung nach) Von mir aus können wir es auch auf das nächste Major Release verschieben, aber nach und nach sollten wir solche Punkte anpacken. Sonst blickt irgendwann keiner mehr durch (überspitzt gesprochen).

Und für die Eventualitäten sehe ich es eigentlich so, dass fast alle Readings auf das gleiche hinaus laufen nur das Reading anders benennen.
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...

betateilchen

ich geh mal Popcorn machen ...

Und ich bleibe bei meinem DAGEGEN
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Amenophis86

Zitat von: betateilchen am 07 Mai 2018, 20:44:34
ich geh mal Popcorn machen ...

Und damit die Diskussion beendet?
Kommt für mich dann auch die Frage auf, wie ist der Entscheidungsprozess in so einem Fall? Gibt es eine Abstimmung, Entscheidet Rudi, muss sich eine Gewisse Anzahl dafür / dagegen entscheiden?
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

auf kurze Sicht bin ich dagegen ...

auf lange Sicht ein ganz klares DAFÜR

die Sonderbehandlungen werden weniger und auch für den Einsteiger einfacher zu verstehen :-)
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