FHEM Forum

FHEM - Entwicklung => FHEM Development => Thema gestartet von: Amenophis86 am 06 Mai 2018, 19:37:18

Titel: battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 06 Mai 2018, 19:37:18
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
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Dr. Boris Neubert am 06 Mai 2018, 20:07:33
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?
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag 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.


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 (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...
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Dr. Boris Neubert am 06 Mai 2018, 20:42:29
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Sidey am 06 Mai 2018, 20:47:12
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
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Markus M. am 06 Mai 2018, 20:51:30
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
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag 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...
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Markus M. am 06 Mai 2018, 23:04:49
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 07 Mai 2018, 15:52:36
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: betateilchen am 07 Mai 2018, 16:58:24
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


Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: CoolTux am 07 Mai 2018, 17:22:45
Ich wäre auch für eine Vereinheitlichung. Muss dann halt nur im Developerbereich im Wiki feststehen.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 07 Mai 2018, 19:50:51
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: betateilchen am 07 Mai 2018, 20:44:34
ich geh mal Popcorn machen ...

Und ich bleibe bei meinem DAGEGEN
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 08 Mai 2018, 18:32:26
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?
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Wuppi68 am 08 Mai 2018, 20:29:16
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 :-)
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: CoolTux am 08 Mai 2018, 22:06:43
Vielleicht kann man für sie kommenden Developer und natürlich auch für die bestehenden einfach mal eine Vereinheitlichung im Wiki Developer EMPFEHLEN
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag 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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: zap am 09 Mai 2018, 07:41:15
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: CoolTux am 09 Mai 2018, 07:59:49
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 09 Mai 2018, 08:57:01
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 10 Mai 2018, 10:29:40
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.

Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: rudolfkoenig am 10 Mai 2018, 12:59:07
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 10 Mai 2018, 17:51:59
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?
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: rudolfkoenig am 10 Mai 2018, 18:01:53
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 10 Mai 2018, 18:24:20
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 :)
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: rudolfkoenig am 10 Mai 2018, 18:30:33
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Dr. Boris Neubert am 10 Mai 2018, 18:33:07
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 10 Mai 2018, 18:44:38
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Markus M. am 10 Mai 2018, 19:23:44
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 ;)
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Wuppi68 am 10 Mai 2018, 21:59:58
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
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Dr. Boris Neubert am 10 Mai 2018, 22:20:23
Zitat von: Wuppi68 am 10 Mai 2018, 21:59:58
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

goto https://forum.fhem.de/index.php/topic,87575.msg801052.html#msg801052 (https://forum.fhem.de/index.php/topic,87575.msg801052.html#msg801052)
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 16 Mai 2018, 10:26:55
Gut, neuer Vorschlag. Anstelle von N/A setzen wir -1 und schreiben in die Dokumentation, dass -1 für unbekannt steht. Wir haben keinen String, jeder normale User dürfte bei -1 merken, dass es etwas nicht stimmt und mit etwas nachdenken, oder suchen finden für was es steht. Und ob nun N/A oder -1 im Forum angefragt wird dürfte auf das gleiche hinauslaufen denke ich.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Dr. Boris Neubert am 16 Mai 2018, 11:28:18
Hallo,

ich bin der Meinung, dass Readings vereinheitlicht werden sollten. Wenn die Lösung über Interfaces kein Interesse findet, dann eben über eine identische Benennung und Befüllung in gleicher Systematik über verschiedene Module hinweg. Ich bin aber dagegen, zusätzliche Readings einzuführen und diese mit Dummy-Werten zu belegen für Messgrößen, die ein Modul nicht zur Verfügung stellt. Der Verwender muss damit umgehen können, dass ein Reading nicht existiert, und das ist m.E. nicht aufwendiger zu implementieren als auf einen Dummy-Wert in einem Reading zu reagieren.

@Amenophis86: oder habe ich jetzt auf eine Fragestellung reagiert, die gar nicht die Deine war?

Viele Grüße
Boris
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: CoolTux am 16 Mai 2018, 11:41:39
Es gibt doch schon eine Vereinheitlichung im Mediabereich. Findet man sogar im Wiki. Warum nicht einfach sowas auch für battery fest vorgeben? Man muss nur wissen wie es aussehen soll  ;D
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 16 Mai 2018, 12:13:22
Zitat von: Dr. Boris Neubert am 16 Mai 2018, 11:28:18
@Amenophis86: oder habe ich jetzt auf eine Fragestellung reagiert, die gar nicht die Deine war?

Fast. Also ich fasse es nochmal zusammen. Wir sind uns einig, dass es nur noch 3 battery Readings geben soll. Bei den Namen gibt es noch keine 100% Einigkeit, aber der Vorschlag von Rude trifft es aus meiner Sicht am Besten:
ZitatbatteryState
batteryPercent
batteryVoltage

Nun besteht die Frage nach den Werten, welche die Readings annehmen können. Rudi hat zurecht eingeworfen, dass manche Geräte (in seinem Fall Z-Wave) zwar für battery ok / low senden und auch eine Zeitlang einen batteryPercent Wert. Nur sobald battery low annimmt der Percent werde nicht weiter gesendet wird und damit defakto unbekannt ist. Nun ist die Frage was passiert mit dem vorhandenen Reading batteryPercent, sobald dieses nicht mehr den wirklichen Wert, sondern quasi nur den letzten Wert anzeigt. Vorgeschlagen wurde:
- Reading auf N/A setzen => Problem String in einem Nummerischen Reading
- Reading auf 0 oder anderen Wert setzen => Problem, dass der Wert ja defacto falsch ist.


Damit haben wir aktuell "eigentlich" uns auf eine vereinheitlichung (nur noch drei Readings und deren Namen) geeinigt. Nun bleibt die Frage nach den Werten der Readings, die angenommen werden können und damit die von mir oben nochmal skizzierten Probleme. Daher mein Vorschlag anstelle eines Strings (N/A) oder eines falschen Werts (0 bei zB noch 10% was wir ja nicht wissen) einfach -1 zu nehmen. Daran sollte jeder erkennen, dass der Wert entweder nicht mehr übermittelt wird, oder inzwischen unbekannt ist. Und dies soll auch nur genommen werden, wenn das Reading bereits vorhanden ist. Geräte, welche nur ok / low übermitteln, müssen ja jetzt nicht extra batteryPercent oder batteryVoltage bekommen, wenn dies gar nicht abgefragt werden kann.
Titel: battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: justme1968 am 16 Mai 2018, 13:49:02
nur kurz:

readings die es (aktuell) nicht gibt sollte man löschen -> problem: die frontends bekommen das nicht mit und zeigen weiter den alten wert an. sollte generell gelöst werden

readings die es zwar prinzipiell gibt, die aber aktuell einen undefinierten wert haben sind etwas anders. hier sollte es unknown oder ähnlich geben. nicht einen künstlichen wert außerhalb des bereiches. auch für -1 oder 111 müsste ein frontend angepasst werden wenn es einem gültigen prozent wert erwartet aber dann etwas außerhalb bekommt. also lieber gleich richtig.

manchmal ist es nicht ganz eindeutig welcher der beiden fälle passt.

es wäre schön wenn die diskussion nicht wieder im sande verläuft und in einem zweiten durchgang das ganze auch auf andere readings ausgefegt wird. und danach die units dran kommen :).

bei dieser art diskussion ist es übrigens oft hilfreich wenn man sich das ganze auch aus dem blickwinkel alternativer frontends wie z.b. sprach steuerung und sprachausgabe sowie der automatischen und device unabhängigen verarbeitung vorstellt.

also z.b.: was brauche ich um auf eine gesprochene anfrage den batterie status aller geräte auf deutsch anzusagen. oder nur der kritischen.

ohne sonderbehandlung für bestimmte geräte.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Markus M. am 16 Mai 2018, 17:20:01
Zitat von: justme1968 am 16 Mai 2018, 13:49:02readings die es zwar prinzipiell gibt, die aber aktuell einen undefinierten wert haben sind etwas anders. hier sollte es unknown oder ähnlich geben.

Die Readings sind ja nicht unbedingt undefiniert, sie werden nur nicht übertragen.
Was spricht dagegen, in dem Fall einfach nur kein Update zu machen?
Oder in dem konkreten Beispiel von Rudi einfach aus dem Modul eine 0 zu setzen.

Wenn ein Device beispielsweise nur Percentage oder Spannung meldet, muss das battery Reading eben vom Modul intern berechnet werden.

Meinem Verständnis nach geht es hier nämlich eben nicht darum, nur Device Readings 1:1 abzubilden, sondern global identisch definierte Readings samt gültiger Werte zu haben. Und N/A sehe ich definitiv nicht als solchen Wert, das ist im Zweifelsfall nur ein verschwendeter Event auf den man nicht sinnvoll reagieren kann.


Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 16 Mai 2018, 19:34:01
Mir ging es in erste Linie darum, dass die Readings Device übergreifend zumindest gleich benannt sind. Das zweite wäre, wenn sie auch noch gleiche Wertebereich hätten. Ich finde auch, dass battery kein Reading ist, was berechnet werden muss. Wenn ein Gerät nur Voltage oder Percent übergibt, dann muss es auch kein battery Reading geben in meinen Augen. Dann arbeitet doch jeder lieber mit dem genaueren Wert und wenn nötig erstellt man sich ein userreading.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Dr. Boris Neubert am 16 Mai 2018, 20:03:38
Zitat von: Amenophis86 am 16 Mai 2018, 12:13:22
Nun ist die Frage was passiert mit dem vorhandenen Reading batteryPercent, sobald dieses nicht mehr den wirklichen Wert, sondern quasi nur den letzten Wert anzeigt.

Hmm. Das Übliche ist es doch, dass ein Reading den zuletzt übermittelten Wert beibehält. Wann ist ein Reading veraltet (stale), also was ist genau das Kriterium? Ich habe ja immer noch den Timestamp, der mir sagt, wielange schon keine Aktualisierung mehr kam. Wenn ich eine Batteriüberwachung machen würde, würde ich zusätzlich anzeigen/auswerten, wielange das Batterie-Reading nicht mehr aktualisiert wurde.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: justme1968 am 16 Mai 2018, 20:09:34
ich denke hier muss man unterscheiden oben ein reading nur 'alt' ist weil kein neuer wert kommt oder ob es tatsächlich nicht mehr gültig ist wie im batterie beispiel von oben.

wichtig ist das ganze nicht nur im batterie kontext zu sehen sondern allgemein. z.b. readings für jeden verpassten anruf auf einem anrufbeantworter. wenn einige oder alle anrufe abgehört wurden müssen die alten readings verschwinden und die übrigen aufrücken. sonst lässt sich das automatisch nicht vernünftig darstellen und auswerten.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Dr. Boris Neubert am 16 Mai 2018, 20:14:18
Zitat von: justme1968 am 16 Mai 2018, 20:09:34
wichtig ist das ganze nicht nur im batterie kontext zu sehen sondern allgemein. z.b. readings für jeden verpassten anruf auf einem anrufbeantworter. wenn einige oder alle anrufe abgehört wurden müssen die alten readings verschwinden und die übrigen aufrücken. sonst lässt sich das automatisch nicht vernünftig darstellen und auswerten.

Völlig d'accord, Andre.

An dieser Stelle läuft die Diskussion Gefahr, weiter in unspezifiziertes Terrain vorzudringen. Gibt es eine Stelle im Wiki, wo wir alle offenen konzeptionellen Punkte in FHEM parken können?
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 16 Mai 2018, 20:28:08
Und wie soll dann weiter entschieden werden? Verstehe nicht ganz was du damit meinst Boris.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Dr. Boris Neubert am 16 Mai 2018, 20:32:52
Zitat von: Amenophis86 am 16 Mai 2018, 20:28:08
Und wie soll dann weiter entschieden werden? Verstehe nicht ganz was du damit meinst Boris.

Ich meine, dass wir uns in diesem Thema auf die Batterien konzentrieren und die weiteren grundsätzlichen Fragestellungen parken.

Was ich noch nicht verstanden habe: wie kann ein Reading vorübergehend einen undefinierten Stand haben?

(davon hängt meine weitere Argumentation ab, dass ein Reading m.E. entweder grundsätzlich da ist oder nicht)
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 16 Mai 2018, 21:11:26
Ah, Jop da bin ich bei dir. Denke das macht Sinn.

Edit:
Zu deiner Frage. Wenn ich Rudi richtig verstanden habe, dann meldet Z-Wave zB bis zum Wert 15%, den genauen Prozent Wert. Ab dann wird nur noch ein bestimmter Bit übermittelt, aber nicht mehr der Prozentwert der Batterie. Daher wir bei ihm battery immer auf ok gelassen und ab dem Bit kommt dann Battery auf low aber der Wirkliche Prozentwert, ist nicht mehr bekannt. Der kann ja zwischen 0-15% sein. Und da will er nicht einfach etwas ausgeben, was nicht stimmen könnt, somit will er den Prozentwert auf N/A setzen.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Markus M. am 16 Mai 2018, 21:24:10
Zitat von: Dr. Boris Neubert am 16 Mai 2018, 20:32:52Was ich noch nicht verstanden habe: wie kann ein Reading vorübergehend einen undefinierten Stand haben?

Siehe Beispiel von Rudi oben: in einem Byte wird entweder der Batteriestand in Prozent übertragen, oder der Zustand "Batteriewarnung".

Die Argumentation war, dass der Batteriestand dann irgendwo zwischen dem letzten Wert und 0 ist, wir ihn aber nicht kennen - und sein Vorschlag war, dann stattdessen N/A zu setzen.

Ich bin anderer Meinung, mir ist es aber egal ob in diesem Fall dann im Modul die 0 gesetzt wird oder der alte Wert stehen bleibt. Hauptsache nicht N/A, um das Reading in jedem Fall numerisch zu halten.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Dr. Boris Neubert am 16 Mai 2018, 22:10:15
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).
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 17 Mai 2018, 06:52:20
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? :)
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag 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.


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
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Dr. Boris Neubert am 17 Mai 2018, 09:13:27
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: HCS am 17 Mai 2018, 09:41:55
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?
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: CoolTux am 17 Mai 2018, 09:48:01
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: HCS am 17 Mai 2018, 10:14:46
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: justme1968 am 17 Mai 2018, 10:17:12
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: CoolTux am 17 Mai 2018, 10:17:27
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Benni am 17 Mai 2018, 10:22:06
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 (https://wiki.fhem.de/wiki/DevelopmentInterfaces)) 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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Markus M. am 17 Mai 2018, 10:37:25
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: justme1968 am 17 Mai 2018, 10:40:27
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Dr. Boris Neubert am 17 Mai 2018, 12:49:10
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?
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Markus M. am 17 Mai 2018, 13:40:13
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 17 Mai 2018, 13:46:36
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

Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Markus M. am 17 Mai 2018, 15:00:34
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?
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 18 Mai 2018, 14:04:50
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: justme1968 am 18 Mai 2018, 14:35:35
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Wuppi68 am 18 Mai 2018, 16:37:34
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
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 18 Mai 2018, 19:16:11
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag 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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 18 Mai 2018, 19:36:25
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 ;)
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Wuppi68 am 18 Mai 2018, 20:39:11
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
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Markus M. am 19 Mai 2018, 00:02:09
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Markus M. am 21 Mai 2018, 14:50:20
Ich fange jetzt einfach mal an. Ab morgen im Update:
32_withings: batteryState, batteryPercent
38_netatmo: batteryState, batteryPercent, batteryVoltage
72_XiaomiDevice: batteryState, batteryPercent
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 21 Mai 2018, 15:05:46
Top Markus, vielen Dank
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 23 Mai 2018, 14:11:16
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?
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag 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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: papa am 23 Mai 2018, 14:22:13
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 23 Mai 2018, 14:26:18
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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 29 Mai 2018, 19:52:40
Wollte nochmal fragen, was wir mache müssten, dass ihr anderen Entwickler Markus M. folgt und eure Readings umbenennt :) ?
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: CoolTux am 29 Mai 2018, 20:27:27
Zeit geben.
Gibt es schon was im Wiki?



Grüße
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 29 Mai 2018, 21:22:15
An der Zeit soll es nicht liegen ;) bin mir nur nicht sicher, ob der Rest mitziehen wollte. Daher gibt es von meiner Seite auch noch nichts der gleichen im Wiki. Kann ich aber gerne machen.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: CoolTux am 29 Mai 2018, 21:38:53
Eine Art Richtschnur wäre schon nett. Sonst muss ich alles hier noch mal lesen um nun zu wissen was wie genau genommen wurde.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: rudolfkoenig am 29 Mai 2018, 21:44:10
Ich habe meine "battery" Module (FBDECT, HMS, ZWAVE) nachgezogen. Wenn ich etwas mit battery vergessen haben sollte, bitte melden.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: torte am 30 Mai 2018, 13:54:09
[Xiaomi Smart Home] Das Modul

... ist in Arbeit ....
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: kaihs am 30 Mai 2018, 20:32:15
WMBus ist schon seit ein paar Tagen umgestellt.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Sidey am 31 Mai 2018, 00:58:34
Sorry, blöde Frage, aber was für eine Einheit ist denn batteryState?
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Benni am 31 Mai 2018, 06:58:26
Zitat von: Sidey am 31 Mai 2018, 00:58:34
Sorry, blöde Frage, aber was für eine Einheit ist denn batteryState?

Ich denke, das ist der aktuelle Konsens: https://forum.fhem.de/index.php/topic,87575.msg802997.html#msg802997
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Markus M. am 31 Mai 2018, 23:04:39
Was machen wir eigentlich, wenn es auch noch eine Ladeanzeige gibt?
Die Winmatic hat z.B. trickleCharge, charge, dischargeund unknown und bei anderen Geräten gibt es teilweise ähnliche Readings.

Alless zusammen könnte so aussehen:
batteryState: ok|low
batteryCharge: charging|discharging|charged
batteryPercent: \d{1,2}|100 [%]
batteryVoltage: \d+.\d+ [V]
batteryCurrent: -?\d+.\d+ [A]


Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Sidey am 31 Mai 2018, 23:28:37
Zitat von: Benni am 31 Mai 2018, 06:58:26
Ich denke, das ist der aktuelle Konsens: https://forum.fhem.de/index.php/topic,87575.msg802997.html#msg802997
Danke, das beantwortet leider nicht die Frage nach den Einheiten (Units).

Bei BatteryPercent oder BatteryVoltage ist mir die Einheit klar, da im Namen.
Bei BatteryState war nich mir nicht sicher, ob state eine Einheit in FHEM ist. Wäre gut, wenn wir das festlegen könnten (wenn nicht schon geschehen).


Durch unsere Anpassung, müssten solche Artikel wie dieser z.B. nun auch überarbeitet werden:
https://wiki.fhem.de/wiki/ReadingsGroup#Auswahl_.C3.BCber_Reading-Namen.2C_Status_als_Symbol_dargestellt

Das bringt mich hier aber an einen generellen Punkt, dass ich hier im Forum immer mal wieder lese, dass sich dies oder jenes der Anwender doch selbst einstellen kann. (Auch in diesem Thread).

Ich wäre doch stark dafür, dass wir uns grundsätzlich darauf einigen, dass dem Anwender möglichst viele Standardfälle oob ermöglicht werden und er nur in Ausnahmefällen noch eigene userreadings etc. einbinden muss.

Den verlinkten (es gibt bestimmt noch mehrere Beispiele für eine Batterieüberwachung) jetzt anpassen ist nicht so die Herausforderung.
Das bekommt der normale FHEM Anwender aber nicht mit und eigentlich will er doch für so eine Standardfunktion auch nichts selbst konfigurieren müssen.
Das passt auch ein bisschen in Richtung Interfaces, aber der Batteriestatus könnte doch leicht in ein eigenes Modul ausgelagert werden (War das vielleicht auch der Auslöser dieser Unterhaltung?).
Nur das einzige Interface zwischen den Modulen ist aktuell das Reading, richtig? Ich fände es aber nicht verkehrt, wenn Definitionen sich über Eigenschaften beschreiben.

Man müsste da auch nicht bei 0 anfangen, dazu gibt es bereits Ansätze:
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8334820



Grüße Sidey
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Markus M. am 01 Juni 2018, 00:23:36
Die Units habe ich doch gerade mit dazu geschrieben.
batteryState hat keine Einheit, um deine Frage konkret zu beantworten.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: CoolTux am 01 Juni 2018, 08:48:27
Nuki und BTLESense sind angepasst. AMAD mache ich heute Abend und pushe dann alles hoch.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: fhainz am 01 Juni 2018, 13:55:15
Zitat von: Markus M. am 31 Mai 2018, 23:04:39

...
batteryPower: -?\d+.\d+ [A]


Bei Power würde ich persönlich eher die Einheit Watt erwarten.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Benni am 01 Juni 2018, 16:52:43
Zitat von: fhainz am 01 Juni 2018, 13:55:15
Bei Power würde ich persönlich eher die Einheit Watt erwarten.

Wenn's um Elektrizität geht, steht der englische Begriff Power durchaus auch für den Strom, bzw. die Stomstärke und die darf man schon in [A]mpere erwarten ;)

gb#

Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: fhainz am 01 Juni 2018, 17:02:37
Wobei man die (Elektrische) Leistung ebenso mit power übersetzen kann. Ich will hier aber wirklich keine Diskussionen über EN->DE Übersetzungen starten, so gut ist mein Englisch bei weiten nicht. ;D
Viele Module haben ein power Reading mit der Einhat Watt. Daher kommt meine voreigenommene Meinung  8)
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Markus M. am 01 Juni 2018, 17:08:52
Zitat von: fhainz am 01 Juni 2018, 17:02:37
Viele Module haben ein power Reading mit der Einhat Watt. Daher kommt meine voreigenommene Meinung  8)
Du hast natürlich Recht: batteryCurrent in A wollte ich schreiben ;)
Bei batteryPower wären es in der Tat W, wenn man auch noch batteryCapacity braucht dann wohl in Ah
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: CoolTux am 01 Juni 2018, 22:36:40
Ich sehe immer noch kein Wikieintrag. Der Thread ist zwar schön und gut aber nicht jeder Entwickler kann/will hier nach lesen. Es sollte im Developerbereich des Wikis einen Eintrag geben.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 02 Juni 2018, 12:57:15
Ich bin dran Leon, sry bei mir ist gerade sau viel los privat.

Edit:
Hier der erste Vorschlag fürs Wiki: https://wiki.fhem.de/wiki/DevelopmentGuidelines#BatteryReadings
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: HCS am 03 Juni 2018, 10:01:26
Ich habe noch eine Frage zur Umbaustrategie:

Da sehe ich im Repo zwei Varianten:
74_NUKIDevice.pm: batteryState zusätzlich zu battery ergänzt
36_WMBUS.pm: battery durch batteryState ersetzt

Wie soll denn mit Modulen, die bereits ein battery-reading haben, verfahren werden?

Wiki sagt:
ZitatEs gibt nur diese drei Readings für den Batteriestatus:
    batteryState
    batteryPercent
    batteryVoltage
...

Aus dem "nur" leite ich ab, dass es battery nicht mehr geben sollte.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Sidey am 03 Juni 2018, 11:05:43
Ich implementier die Reading erst mal zusätzlich, damit Anwender die Chance haben, ihre Trigger anzupassen.

Grüße Sidey
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 03 Juni 2018, 11:07:12
Denke auch für einen Übergang kann es battery weiterhin geben. Außerdem sollte es einen Ankündigungsthread geben. Kann das jemand machen?
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 04 Juni 2018, 18:59:06
Nach Hinweis von krikan habe ich folgenden neuen Artikel im Wiki erstellt: https://wiki.fhem.de/wiki/DevelopmentGuidelinesReadings Wäre nett, wenn jemand mal drüber schauen könnte. Insbesondere über den Englischen Teil. Danke
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: rudolfkoenig am 04 Juni 2018, 22:47:47
Vielen Dankl!

Ich wuerde den letzten Absatz so formulieren:

Important: The FHEM module will only report the values received from the device, i.e. not each module reports a batteryState reading. Additionally, if the device sent a batteryPercent value earlier but the last message from the device only contained a 'battery: low', the batteryPercent reading wont be changed. 
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Sidey am 04 Juni 2018, 22:55:04
Zitat von: Amenophis86 am 04 Juni 2018, 18:59:06
Nach Hinweis von krikan habe ich folgenden neuen Artikel im Wiki erstellt: https://wiki.fhem.de/wiki/DevelopmentGuidelinesReadings Wäre nett, wenn jemand mal drüber schauen könnte. Insbesondere über den Englischen Teil. Danke

Ich habe es gelesen und den Text gleich etwas geändert.

Wo ich noch nicht so sicher bin ist folgender Satz:

ZitatWichtig: das jeweilige Modul setzt nur die Readings, die es aus den aktuellen Daten vom Gerät bestimmen kann. Konkret: niemand kann sich darauf verlassen, welche der drei battery Readings vorhanden sind (es gibt nicht überall ein batteryState). Wenn das Gerät früher ein Percent gemeldet hat, aber in der letzten Nachricht nur state, dann wird das Percent Reading nicht angefasst.

Ist es nicht möglich, batteryState zu bestimmen, wenn eines der anderen beiden vorhanden ist.
Haben wir einen Grund, weshalb wir das nicht errechnen, wenn ja, dann sollte dieser Grund in die Doku.


Grüße Sidey
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: rudolfkoenig am 04 Juni 2018, 23:04:04
ZitatIst es nicht möglich, batteryState zu bestimmen, wenn eines der anderen beiden vorhanden ist..
Vermutlich. Aber in manchen Faellen kommen die Geraete, die das gleiche Protokoll sprechen, von unterschiedlichen Herstellern. Ich moechte als Modul-Maintainer nicht fuer jedes Geraet eine Messreihe starten (am besten mit unterschiedlichen Batterietypen und Temperaturbereichen), um zu sagen, wann low erreicht ist.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 05 Juni 2018, 08:45:35
Danke Sidey für die Korrektur und danke Rudolf für den Vorschlag. Habe diesen auch eingebaut.

Wie Rudolf sagte, wollten wir dem Modulentwickler nicht aufhalsen, dass er für jedes Gerät messen muss. Natürlich steht es ihm aber frei dies zu tun und batteryState entsprechend auf low zu setzen.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 07 Juni 2018, 16:21:48
Zitat von: sledgeHi,

ich habe keine Rechte in Developer zu posten, daher als PM: Es gibt einige Module, die sind ja "orphaned"  - beispielsweise MAX!. Dennoch wäre die Implementierung zumindest des batteryState-Readings dort idR trivial, da das bisherige Reading "battery" bereits (ok|low) ausgibt - meist nur ein zwei Zeilen Code an den relevanten Stellen.

Code: [Auswählen]
      readingsBulkUpdate($shash, "mode", $ctrl_modes[$mode] );
      readingsBulkUpdate($shash, "battery", $batterylow ? "low" : "ok");
      readingsBulkUpdate($shash, "displayActualTemperature", ($displayActualTemperature) ? 1 : 0);


Wenn ich das richtig sehe, gehört hier ja "nur" eine weitere Zeile

Code:
      readingsBulkUpdate($shash, "batteryState", $batterylow ? "low" : "ok");

dazu?

Ich habe jetzt kein Problem, Patches für solche Trivialfälle zu erstellen, frage mich aber, ob man sowas nicht ggfs zumindest für die orphans zentral anstoßen möchte?

Gruß,

Tom

Er würde die Änderung für MAX übernehmen, aber nicht das Modul offiziell betreuen wollen.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: rudolfkoenig am 07 Juni 2018, 21:57:22
Um es einfach zu halten: ich habe die Zeile hinzugefuegt, Syntax-Getestet, und 10_MAX.pm eingecheckt.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: CoolTux am 08 Juni 2018, 09:55:56
Zitat von: rudolfkoenig am 07 Juni 2018, 21:57:22
Um es einfach zu halten: ich habe die Zeile hinzugefuegt, Syntax-Getestet, und 10_MAX.pm eingecheckt.

Dazu gibt es aktuell einen Thread
https://forum.fhem.de/index.php/topic,88507.0/topicseen.html
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: rudolfkoenig am 08 Juni 2018, 17:45:59
Hab den Patch von sledge fuer MAX eingecheckt.
Habe nicht damit gerechnet, dass man batteryState an 4 verschiedenen Stellen erstellen muss.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: HCS am 10 Juni 2018, 16:16:41
Wie wäre es denn, die Umstellung auf die neuen Readings (also den rename) an featurelevel 5.9 zu binden?
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Sidey am 02 Juli 2018, 22:24:21
Hi,

ich habe soeben die folgenden Module an die neuen Reading Konvention angepasst:

14_Hideki.pm
14_SD_WS.pm
14_SD_WS07.pm
14_SD_WS09.pm
41_OREGON.pm


Grüße Sidey
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: betateilchen am 04 Juli 2018, 15:36:47
zumindest bei 41_OREGON.pm scheint es ein Problem zu geben.

https://forum.fhem.de/index.php/topic,89120.0.html
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 29 Oktober 2018, 21:44:16
Ich wollte das Thema nochmal pushen, in der Hoffnung, dass noch weitere Modulautoren folgen. Insbesondere für Homematic (CUL_HM) würde ich mir die Änderung wünschen :)

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.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: zap am 04 November 2018, 13:28:16
Für HMCCUDEV und HMCCUCHN kann sich das jeder selbst einstellen. Um es für alle per HMCCU angebundenen Devices zu definieren, genügt es folgende Attribute im I/O Device einmalig zu setzen:


attr ccudef-readingname ^(.+\.)?LOW_?BAT$:batteryState
attr ccudef-substitute LOWBAT,LOW_BAT!(0|false):ok,(1|true):low

Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: martinp876 am 26 Dezember 2018, 17:09:03
Hi,

Wir haben in culhm eine diskussion zu diesem thema- und es sorgt - nicht unbegründet - für unruhe.
Wer ist bei diesem thema der Lead? Wann ist ein Beschluss gefasst und wurden die Konsequenzen für Gegenwart, Vergangenheit und Zukunft abgewogen? Für alle, insbesondere die weit verbreiteten Anwender und Anwendungen?
Sind die Nachteile betrachtet? Vom jemandem der so etwas kann?
Hier meine Kommentare aus culhm.

1) zur Festlegung der Standardisierungen sehe ich kein Dokument (bspw wiki,...). Ein Threat kann eigentlich per definition keine Grundlage zur Änderung der Readings sein. Der kann sich jederzeit verändern
2) Vorstöße etwas zu standardisieren kommen immer wieder von einzelen und werden in einem belibigen Rahmen diskutiert (nicht geschlossen, aber man muss es erst  einmal finden. Da gab es schon einige - und nicht alle sind sinnvoll.
3) Vereinheitlichungen müssen hinreichend felxibel und zukunftssicher sein sowie kompatibel und semantisch passend zum System
4) Berücksichtig werden muss nicht nur die syntaktische Korrektheit und der semantische Anspruch der aktuellen Diskussionsgruppe. Auch die Verbreitung der aktuellen Implementierungen. "battery" ist wohl schon seit Anbeginn von FHEM vorhanden. Dies zu ändern zu "batteryState" ist nicht lustig - und schöner reicht nicht als Argument.

=> Es Bedarf eines Kernteams welches die FHEM Philosophie, Notwendigkeit und zukunftsträchtigkeit eines Standardisierungsvorschlags betrachtet. Das Ergebnis MUSS in einem Dokument (wiki?) niedergeschrieben werden - NACH Review und Genehmigung der "Kerngruppe".

Das schränkt natürlich ein - aber es gibt nun einmal keine andere Möglichkeit Ruhe ud Systematik in die Readings zu bekommen.

Ich selbst habe weder die Zeit noch den Überblick solche (nicht einfachen) Fragen zu beantworten. Ich werden also auf das Dokument warten (und hoffe informiert zu werden , wenn dieser Teil definiert ist).
=> Planänderung: keine Änderung vor Freigabe des Dokuments zum Reading

Und weiter: natürlich ist es m.E. möglich, die aktuellen Anforderungen unter einen Hut zu bekommen. So könnte bspw zum primary-state des Readings batteryState (oder battery) einen secondary-state addieren. Neben 'low|ok' kann es einen parsable state 'low_critical' geben
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 26 Dezember 2018, 19:54:51
1. Nichts ist in Stein gemeißelt aus meiner Sicht
2. Habe ich kein Problem, die erkannten Probleme anzugehen und die Idee der standardisierten Readings anzupassen.
3. Es gibt auch einen Wiki Eintrag dazu
4. Die Frage zu einem Team oder ähnlichem, welches sich über solche Fragen Gedanken machen gehört aus meiner Sicht nicht in diesen, sondern einen eigenen Post
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: martinp876 am 28 Dezember 2018, 07:59:29
nun, nachdem mir Rudi mitgeteilt hat, dass es quasi in FHEM keine Festlegungen sondern zur Vorschläge gibt und auch die Wiki Beiträge in Development nicht reviewed sondern schlicht einfache Vorschläge eines oder mehrerer Entwickler sind gibt es schlicht keinen Standard sondern eben nur Vorschläge.

Den Batterie-Vorschlag muss ich unter diesen Umständen für CUL_HM ablehnen, da
a) die CUL_HM Implementierung schon seit quasi anbeginn so stehen
b) die Verbreitung von CUL_HM erheblich ist und JEDE Änderung ein Problem darstellt
c) die Namensänderung nur Semantisch sind und sogar den Wert "critical" nicht mehr unterstützen
d) ich ohne einen FHEM Standard ich die zukunftsweisende Ausrichtung dieser Änderung nicht erkennen kann
e) der Meinung bin, der Standard sollte sich lieber an den vorhandenen Quasi-standards orientieren (bspw CUL_HM)

sorry, so kann ich as Bestandschutzgründen nicht mitmachen.
Doppelte Readings lehne ich ab. Dafür müssen die Gründe auch erheblich sein.

Wenn es also je einen FHEM standard gibt oder ich etwas neues mache, gerne. Bestand, nein.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: rudolfkoenig am 28 Dezember 2018, 10:35:20
Zitatnun, nachdem mir Rudi mitgeteilt hat, dass es quasi in FHEM keine Festlegungen sondern zur Vorschläge gibt...
Ich interpretiere das, was ich geschrieben habe anders:
Zitat"FHEM Development" sollte jeder FHEM-Entwickler abonnieren, relevante Themen lesen, und bei Bedarf sich dazu aeussern. Das steht so in der "Standard Belehrung", was man beim Erteilen der SVN-Schreibrechte kriegt.

Wenn man irgendetwas nicht so macht, wie diskutiert, dann funktioniert ein Modul nicht oder nicht perfekt mit anderen Modulen zusammen.  Das ist mAn keine Katastrophe, aber unschoen, und sollte, soweit machbar, vermieden werden.
Kurz: ich werde nicht mit Konsequenzen drohen, wenn Du den Beschluss aus diesem Thread in CUL_HM nicht uebernimmst, schade finde ich es trotzdem.

Ich habe kein Problem mit doppelten Readings, insb. wenn der Inhalt nicht exakt gleich ist, und eine sinnvolle Begruendung vorliegt.
Alternativ koennte man nach Abfrage von "attr global featurelevel" jeweils nur einen setzen: Falls > 5.9, dann neues Verhalten, sonst wie bisher. Wenn man das im commandref, ein Thema und UPGRADE dokumentiert, dann sollten alle Benutzer genuegend gewarnt sein.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: CoolTux am 28 Dezember 2018, 10:45:06
Danke Rudi.


@Martin
Soweit ich das ganze jetzt noch überblicke geht es doch nur um den Readings Wert. Der Readingnamen ist dir nicht so schlimm, oder?
Wieso störst Du Dich so sehr daran da jetzt ein critical ein zu setzen. Dann würde es halt erweitert. Entweder nur für das Modul oder wir sagen super ist auch gut für andere und setzen das auch ins Wiki als kann es auch geben.
Ich verstehe immer noch nicht das Problem. Tut mir leid.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 28 Dezember 2018, 11:06:08
Ich sehe auch kein Problem den Wert der möglichen Readings zu erweitern, solange wir uns wenigstens auf einheitliche Namen einigen können. Das war mein Hauptbestreben.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: martinp876 am 28 Dezember 2018, 11:23:50
Ich persönlich kann mit allem leben.
Aktuell muss battery nach batteryState geändert werden und der value critical soll entfallen. Der Wertebereich ist exakt beschrieben.
Weiter ist batteryLevel durch batteryVoltage zu ersetzen, inhalt identisch.

Mehr ist es schon nicht. Auswirkung ist klar:
User müssen notifies anpassen, Graphen ändern, Database logging filter ebenso. Sicher noch das Eine oder Andere.
Bevor also hier weiter pholosophiert wird sollte eine Recherche durchgeführt werden, was unter battery so alles getriggert wird. Einfach einmal ein grep über der code. Scheinbar noch nicht geschehen. Das gehört m.E. zur vorarbeit, bevor ich einen fundierten vorschlag mache.  Vielleicht gibt es noch weitere readings. Vielleicht sogar sinnvolle.

BatteryVoltage und batteryLevel kann man auch einfach gleichsetzen.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Markus M. am 28 Dezember 2018, 12:55:45
Zitat von: martinp876 am 28 Dezember 2018, 11:23:50
Aktuell muss battery nach batteryState geändert werden und der value critical soll entfallen. Der Wertebereich ist exakt beschrieben.
Muss nicht. Wenn critical Sinn macht, nimm es mit rein und aktualisiere das Wiki.
Dann solltest du aber auch beschreiben, was wann passiert.
Wenn immer erst low und dann critical kommt, wäre das zum Beispiel überhaupt kein Problem.

ZitatWeiter ist batteryLevel durch batteryVoltage zu ersetzen, inhalt identisch.
Ja, ich sehe das Problem nicht.
batteryCharge war zum Beispiel hier noch gar nicht definiert, das darfst du gerne übernehmen.

Ich habe mir die Namen meiner Readings bisher etweder aus den Fingern gesogen oder bei anderen Modulen abgekupfert.
Wenn jemand einen Standard definieren möchte und sinnvolle Vorschläge hat, hätte ich mit Änderungen kein Problem.
Es geht darum die Readings in möglichst vielen Modulen gleichzuziehen, so dass User es möglichst einfach haben.
Dazu gehört meiner Meinung nach zum Beispiel auch, ein sinnvolles Reading batteryState auszugeben, sofern das Gerät das nicht gesondert ausgibt, es aber aus anderen Readings extrapoliert werden kann.

Wie dem auch sei, niemand wird dich dazu zwingen etwas zu ändern.
Wäre nur Schade für die Plattform.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: martinp876 am 28 Dezember 2018, 14:28:47
Hm. Ich verstehe das hier nicht so ganz. Wäre schön, wenn sich jemand, wie bei den systemen auch, für gebiete verantwortlich fühlt oder gemacht wird. Dem könnte ich dann vorschläge machen.
ZitatKurz: ich werde nicht mit Konsequenzen drohen,
Warum auch. Wenn es pflicht ist, baue ich es ein und erwarte, dass es überlegt ist.

ZitatWenn critical Sinn macht, nimm es mit rein und aktualisiere das Wiki.
Dann solltest du aber auch beschreiben, was wann passiert.
Wenn immer erst low und dann critical kommt, wäre das zum Beispiel überhaupt kein Problem.
Natürlich nicht. Ich habe weder die hm fw geschrieben noch die hw designed, spezifiziert oder reviewed. Bei manchen der hm devices gibt es ein critical welches unspezifiziert ist. Es sollte nach low kommen. Auch möglich, dass low nicht kommt. Manche devices haben kein critical. Dann gibt es nur low.
Was dann passiert? Hm. Der akku explodier? Sorry, musste sein. Ernsthaft: wahrscheinlich ist er bald leer. Im unterschied zu low ist das möglicherweise früher der fall. Was für vorteile der user hat es auszuwerten? Er muss schneller laufen.
Wieder ernsthaft: ich reagiere auf low... manchmal. Ein taster hat seit jahren low und die knopfzelle hält. Aber manche haben andere devices, kennen diese und wissen, wie schnell sie reagieren wollen. Ihre notifies und push nachrichten haben sie ihren bedürfnissen angepasst (fhem vorteil!)

Würde ich es in die hand nehmen, etwas zu standardisieren würde es ganz anders aussehen. Schon zu beginn hat mir das battery low nicht gereicht. Daher habe ich den actiondetector eingebaut. Auch hier gab es (mir unverständlichen) widerstand. User waren der meinung, ein batlow reicht. Einige hat es dann kalt erwischt. Der trigger ging verloren, das device ist die meldung nicht mehr los geworden. Ein lowbat ohne ein dead ist für mich sinnlos.
Ich würde so etwas wie (teile aus) hminfo einbauen. Hminfo bietet
A) ein alarm interface. Man wird alarmiert, wenn ein device lowbat anzeigt oder gar tot ist. Weiter werden motorprobleme angezeigt usw. Kann der user erweitern. Man hat EIN interface für system warnings und errors.
B) protokol überwachung: zusammenfassung von übertragungsproblemen zu devices.
C) config check: hat der anwender einstellungen vorgenommen welche fragwürdig sind?  Oder fehlen welche? Dblog bietet hier eine coole abfrage.

Wenn jemand ein (EIN) solches modul baut würde ich mich gerne anbinden. Quasi das hm-maintenance-modul. Kritische ereignisse werden von hm-interface modulen gemeldet und gesammelt. Kompakt, einfach und ohne schnickschnack. Der user kann sich anbinden wie er will. Fehler kann man ablöschen, wenn nicht mehr relevant ( im hm und hminfo sind das die clear kommandos)

ZitatIch habe mir die Namen meiner Readings bisher etweder aus den Fingern gesogen oder bei anderen Modulen abgekupfert.
Schade. Das mit den anderen modulen wäre m.E. sinnvoll gewesen

ZitatWäre nur Schade für die Plattform
Eine platform ist es erst, wenn sich jemand die mühe macht, über alle module zu schauen und einen entsprechenden ansatz präsentiert. Nach mehr frage ich ja auch garnicht. Alles andere sind punktuelle ideen, nicht zu ende gedacht.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Markus M. am 29 Dezember 2018, 01:42:16
Zitat von: martinp876 am 28 Dezember 2018, 14:28:47
Hm. Ich verstehe das hier nicht so ganz. Wäre schön, wenn sich jemand, wie bei den systemen auch, für gebiete verantwortlich fühlt oder gemacht wird. Dem könnte ich dann vorschläge machen. Warum auch. Wenn es pflicht ist, baue ich es ein und erwarte, dass es überlegt ist.

Bei der Sache mit dem Überlegen könntest du dich aber auch selbst berufen fühlen :)

ZitatNatürlich nicht. Ich habe weder die hm fw geschrieben noch die hw designed, spezifiziert oder reviewed. Bei manchen der hm devices gibt es ein critical welches unspezifiziert ist. Es sollte nach low kommen. Auch möglich, dass low nicht kommt. Manche devices haben kein critical. Dann gibt es nur low.
Könnte man versuchen zu dokumentieren.

ZitatSchade. Das mit den anderen modulen wäre m.E. sinnvoll gewesen
Habe ich ja soweit wie möglich getan. Ich habe aber auch genügend Readings die es nirgendwo sonst gibt und die auch namenlos ankommen.

ZitatEine platform ist es erst, wenn sich jemand die mühe macht, über alle module zu schauen und einen entsprechenden ansatz präsentiert. Nach mehr frage ich ja auch garnicht. Alles andere sind punktuelle ideen, nicht zu ende gedacht.
Irgendwo muss mal jemand anfangen, diesen Thread hier empfand ich als einen guten und sinnvollen Ansatz.
Und deshalb habe ich meine Module auch angepasst.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: martinp876 am 29 Dezember 2018, 16:49:06
ZitatBei der Sache mit dem Überlegen könntest du dich aber auch selbst berufen fühlen
klar. Mir passt es aber ohne Änderung. Zu Wort hat sich ein Anderer.
ZitatKönnte man versuchen zu dokumentieren.
Ich nicht. warum? Jedes Device hat seine eigene HW, eigene Level. Es gibt Batterien und Akkus. Ein Endloses Feld. dann die Toleranzen und die Bugs in HW und FW. Die von ELV genauten Devices weichen dann auch noch einmal ab. Und schliesslich FW updates. Viel Spass.
Es ist doch ganz einfach: wenn Bat low, Nerven behalten oder tauschen.  Wenn das Device auch Critical melden kann, kann man weiter warten. Jeder wie er will.
ZitatIrgendwo muss mal jemand anfangen, diesen Thread hier empfand ich als einen guten und sinnvollen Ansatz.
Und deshalb habe ich meine Module auch angepasst.
kann man. Wie schon x-mal wiederholt: werde ich auch, wenn der Convident-level hinreichen ist oder es zum fixen Standard erklärt wird.

Ich haben nun einmal schnell durchgesucht: "battery" wird sehr oft genutzt - batteryState scheint ein Exot gewesen zu sein.
Als Reading hierzu finde ich neben ok und low auch unknown. Scheint sinnvoll.
Auch batteryLevel habe ich gefunden, batteryVoltage allerdings nicht.
=> warum wurden also neue Readigns eingeführt welche noch nicht existierten?
Das hat mich jetzt 10 min research gekostet.
=> ich habe immer versucht, existierende Readings zu nutzen. Namen und Werte. Jetzt machen wir halt einmal etwas Neues?
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 29 Dezember 2018, 17:25:18
Ich gebe dir Recht Martin, dass man vermutlich mehr Arbeit in die Lösung hätte stecken können als getan wurde. Das allerdings dabei Arbeit hintenraus kommt war klar. Wichtig ist mir, dass ein gewisser Standard dabei entsteht. Warum? Es kann aus meiner Sicht nicht sein, dass es so viele verschiedene Readings Namen gibt. Ich finde jedoch, dass der Weg welcher gewählt wurde nicht komplett falsch war. Warum?

Ich hatte erkannt, dass viele Module verschiedene Namen für battery nutzen. Habe versucht alle Werte zu finden und aufzulisten (Post #8). Daraufhin habe ich dies mitgeteilt und eine Vereinheitlichung angestoßen. Die Werte und Namen wurden in einer Diskussion ausgearbeitet von verschiedenen Nutzern. Am Ende hat Rudi entschieden, was für mich vollkommen ok ist. Die hat zu dem aktuellen Stand geführt. Wenn du nun der Meinung bist, dass dieser Stand verbessert / verändert werden sollte, dann mach doch einfach einen konstruktiven direkten Vorschlag was wie besser heißen könnte?

Bisher habe ich rausgehört, dass weitere Informationen, wie "critical" nicht unter den Tisch fallen sollten. Die Idee finde ich gut. Das heißt das Reading "batterState" wird aufgebohrt und muss mindestens "ok|low" als Wert haben, kann aber zusätzlich auch "critical" und "dead" sein. Wäre das ein Vorschlag? Dann stellen wir dies zur Diskussion.

Bezüglich der Namen der Readings erkenne ich noch nicht wo deine Reise hingehen soll, sehe aber auch hier nicht das größte Problem. Die von der Gruppe ausgewählten Namen sind selbsterklärend und für mich logisch. Solltest du andere Ideen haben, dann komm auch hier mit einem direkten Vorschlag.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: martinp876 am 29 Dezember 2018, 17:32:21
so, habe einmal einen Absatz gemacht. Eigentlich haben ich hier ein grundsätzliches Problem beim Vorgehen, der Standartisierung und den Zentralen Modulen. FHEM ist sicher schon reif genug, an einigen Stellen harte Standarts zu setzen (würde ich von Rudi und/oder dem Kern-team erwarten)

Ein zentrales Modul sollte die "System-gesundheit" für Anfänger bereitstellen. hm- ich komme vom 100ertsten ins 1000senste.
FHEM ist eine offene und leicht zu modufizierende Platform. Cool. Jeder der mag kann überall eingreifen. Dennoch sollten zentrale Module den einfachen Anwendern einen default service bieten. Was meine ich damit?
Zu aller Erst sehe ich die HW Verwaltung. FHEM kann (auch sehr cool) unterschiedliche HW Familien und sonstige Devices (stereo, Fernseher) verwalten. FHEM sollte hier ein Modul anbieten, welches jede beliebige HW "verwaltet". Hier ist m.E. ein Maintenance interface notwendig. Das Maintenance Modul bietet folgende Services
- Device Gesundheit: Es wird angezeigt (aufgelistet) welche Devices eine Maintenance-meldung haben
- Meldungen müssen unterschieden werden nach Info, Warning, Error, Critical
- Ein ConfigCheck sollte angeboten werden (das könnte nun auch die SW- Entities betreffen...)
- Presents erkennung und Alarmierung bei Fehlen
- ablöschen von gelesenen fehlern (confirm)

Um das zu erreichen sollte FHEM von jedem HW-Modul ein entsprechendes Interface verlangen.
Da haben wir schon das erste Problem der flachen Architektur von FHEM. Bsp: CUL_HM (da kenne ich mich nun einmal aus). Es gibt eine entity "CUL_HM" sondern nur entites VON CUL_HM. Ich habe mir hierzu behelfsweise HMinfo gebaut.
Das Zentralmodul sollte die Module nach den Informationen zu den benötigten Infos "befragen".  Möglich auch alle einzelnen Devices - halte ich aber für Unfug.
Dem Zentralmodul müssen neben Batterie noch viel wichtiger die "dead" devices angezeigt werden. Dead könnte man auch in den BatteryState einbauen. Es ist typisch die konsequenre Fortsetzung des Lebens einer alternden Batterie.
Ach ja, wichtig: Das Maschinen interface Modul<->Maintenance modul ist leicht änderbar (kein User-Impact!)

Grundsätzliches
Man muss eindeutig unterscheiden zwischen den unterschiedlichen User-interfaces.
- Operational
- Administration
- Maintenance
- Provisioning

Was man ebenso deutlich unterschieden muss sind internal und external events. Ein Battery-Status ist ein internal event. Sache des SysAdmin. Ein Temperatur-alarm ist external. Bitte Fenster schliessen.

Es gibt noch etliche Details
Ich komme auch ohne das Modul zurecht - weil ich mit HMInfo eines habe was meine relevanten Devices abdeckt und mir genau diese Informationen und Funktionen bietet

Wie sehe ich nun die Batterie in diesem Kontext.
BatteryLevel ist Administration level. Die Info kann für Graphen oder private Auswertungen genutzt werden, mehr nicht. Es ist unklar, wie lange das Device noch arbeitet, die Level,...
Battery(State) ist klar Maintenance Level. Hier sind Aktionen den SysAdmin notwendig (Batterie kaufen). Wenn das zukuftssicher eingebaut werden soll und wir schon unknown|ok|low|critical kennen könnte man z.B. 6 level definieren
0: unknown
1: ok
2:future use
3:Device mit 3 Leveln melden "low" mit 3
4:future use
5:schlechtester Level des Device. Wenn das Device nur low meldet, ist es low
geht natürlich auch anders. Allerdings sollte für alle der schlechteste Level immer der gleiche Wert sein.
Das Maschinen Interface zwischen den Module und dem Maintenance Modul könnte Abstrakt sein, also nur Zahlen.

Ach so: Charge ist natürlich nichts für Batterien - das muss dann schon ein Akku sein (Semantik). Und die Meldung ist dann natürlich nur Info.


Eine leicht wirre und unvollständige Sammlung meiner Gedanken zu System-Maintenance(Modul) und Interface Standardisierung. Battery ist da nur ein Detail - mit dem man nicht anfangen muss.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: martinp876 am 29 Dezember 2018, 18:01:22
Hi Amenophis86. Ich glaube es nun zum letzten Mal zu wiederholen: Wenn Rudi dies als Standard definiert baue ich es ein. Period.
Es geht mir überhaupt nicht um die Arbeit. Ich habe es mittlerweile schon einmal bei mir ein und wieder ausgebaut. Es geht ausschliesslich um die User - welche schwer zu benachrichtigen und zu warnen sind.
Und Standartisierung immer. Wenn es FESTGELEGT ist. Rudi hat es als "Vorschlag" verkauft.

Ah, Post 8. Gute Arbeit. Warum man sich entschieden hat nur neue Readings zu nutzen werde ich nicht verstehen. M.E. macht man so etwas in einem laufenden System nicht, wenn man eine entsprechende Verbreitung hat.  Muss ich sicher nicht verstehen. Vor 5 Jahren, ok. Jetzt...??? Unruhe, Missmut,...

In deiner Auswertung sehe ich bspw bei EnOcean neben ok auch noch full - und Empty. Damit bin ich bei dem abstrakten Status in bsp 5 Leveln.

BatteryLevel hätte man für % lasse können.

So mal auf die Schnelle ist die einfache Lösung mit wenig User Auswirkungen
battery: full|ok|low|empty ok und low sind die verbreitetsten. also sollten sie max und min darstellen. Somit sind für die mittleren Werte Namen zu finden. Bspw (zukunftssicher mit nummer) discharge1, discharge2. Somit würden bei CUL_HM Devices mit "critical" nun ok|dischange1|low einzug halten.
batteryLevel: kann man für Prozent einfach lassen. Kein Grund zu ändern
batteryVoltage: wenn die Spannung ausgegeben wird. CUL_HM müsste ändern.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: justme1968 am 29 Dezember 2018, 21:12:09
sorry. dem kann ich nicht folgen.

ja. ein standard sollte versuchen so weit möglich alle fälle abzudecken. aber ein standard wird nicht besser wenn er einfach alles erlaubt. und es kann auch besser sind mit einem kleinen standard anzufangen und bei tatsächlichem bedarf zu erweitern als zu versuchen von anfang an alles zu berücksichtigen.

für battery 5 ziemlich willkürliche zustände zu erlauben die weder eine übergreifende sinnvolle bedeutung haben noch irgendwie genauer spezifiziert sind ist sinnlos.

es geht doch darum so viel geräte wie möglich auf die gleiche art zu überwachen. das ist mit ok/low möglich. mit jedem zusätzlichen zustand der nicht allgemein gültig ist geht die allgemeine überwachung den bach runter. ich kann mir vorstellen das ein dritter zustand nützlich sein könnte, aber ich sehe nicht das er zwingend nötig ist.

full und empty muss man denn eben nach ok und low ändern
critical wenn es sein muss
dischargeX ist nicht sinnvoll.


da niemand garantiert das ein low oder sogar critical signal tatsächlich gesendet wird bevor ein sensor stirbt muss eine solche überwachung doch auf jeden fall schauen wann das letze event gekommen ist und wann es hätte kommen müssen. die meisten schauen bei low ob noch batterien im schrank sind und tauschen bei tod. je nach vorsicht und/oder sensor wichtigkeit tauscht man vielleicht auch schon bei low. was gewinnt man wirkich durch zusätzliche zustände?

wenn es genauer sein soll gibt es noch % und voltage. wenn ein sensor das nicht liefert ein modul kann ganz willkürlich die > 2 diskret zustände auf sinnvolle % werte mappen. das ganze doch sowieso zu einem teil kaffeesatz leserei und. ein besonders kalter oder warmer tag ändert von ok nach low bzw. umgekehrt.von unterschiedlichen entlade verhalten der verschiedenen batterie und akku sorten ganz zu schweigen.

und wenn sich jemand weiter verkünsteln möchte steht es ihm frei zusätzlich zu den zwei (oder drei) fest definierten zuständen in einem anderen reading seiner wortfindungs wut freien lauf zu lassen. aber bitte zusätzlich zum standard.

unabhängig davon: vielleicht gibt es wichtigeres festzulegen. z.b. reading namen, schreibweisen, ... aber wenn es schon mit so etwas einfachem wie einer batterie warnung nicht funktioniert sehe ich nicht wie wir das schaffen ohne etwas am prozess zu ändern.


so... genug frust abgelassen...

die ideen zu einem 'maintainance modul' finde ich gut. aber um irgendwann dahin zu kommen sollten wir klein anfangen und dran bleiben. sonst wird es (mal wieder) nichts.

was bei finden solcher standards/abstraktionsebenen/kleinsten gemeinsamen nenners sehr hilfreich ist: sich vorzustellen wie man das ganze mit alternativen frontends bedient ohne etwas zu sehen. z.b. sprachsteuerung und sprachausgabe. z.b. 'hey fhem, sind alle batterien ok?' oder  'hey fhem, bei wieviel geräten sind die batterien bald leer?' um das zu automatisieren ist dischargeX nicht hilfreich. auch die zweideutigkeit von full/ok oder unterschiedliche schreibweisen sind hinderlich.

Titel: Antw:battery / batteryLevel / ... -&gt; Vereinheitlichen
Beitrag von: justme1968 am 30 Dezember 2018, 11:29:06
kann es sein das die emotionen teilweise so hoch kochen weil die semantik nicht klar ist. bzw. weil geräte und anwender unterschiedliche dinge abbilden und erwarten.

beispiel critical: scheinbar bedeutet es 'der batterie zustand reicht noch zum senden, aber nicht mehr um die eigentliche funktion auszuführen'. z.b. einen stellmotor anzutreiben.

ich kann verstehen das es fatal wäre wenn diese information verloren geht. das ist aber nur dann verständlich wenn man den kontext kennt und die bedeutung erklärt.

aber: vielleicht gehört das eher in ein device health reading. nicht in ein reines batterie reading.

dort könnte man auch einen eventuellen dead zustand bei nicht melden aus einer überwachung  unterbringen. 
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Amenophis86 am 30 Dezember 2018, 11:53:33
Denke die Idee eines zusätzlichen Readings finde ich sogar noch besser, als es im "Standard" unterzubringen
Dann hätte man etwas was überall gleich ist und alles was davon abweicht geht nicht verloren.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: martinp876 am 30 Dezember 2018, 14:44:50
Also das mit den Emotions sehe ich gelassen. Ich habe eine Meinung und tue diese kund. Sollte es anders entschieden werden und als standart definiert werden implementieren ich es (ich wiederhole mich schon wieder). Das ist aktuell nicht der Fall, nach Rudi. Also mache ich es JETZT noch nicht.
Ich will keinen Beleidigen, alles cool bei mir. Bei euch hoffe ich auch!

Zitatund es kann auch besser sind mit einem kleinen standard anzufangen und bei tatsächlichem bedarf zu erweitern
halte ich für ziemlich schlecht. Die Auswertungen in FHEM sind string basierend. Wenn die Werte erweitert werden hat jeder seine eigenen Auswertung welche nach beleiben schief geht. Und im schlimmsten Fall wird es nicht bemerkt.

Zitatfür battery 5 ziemlich willkürliche zustände
Wenn du dem Anwender klar darlegst, was noch kommen kann/könnte ist alles grün. Wenn er sich darauf nicht einstellt und die Erweiterung kommt ist es sein Problem. Wenn du ihn aber überraschst (nicht jeder hat Zeit und Muse kontinuierlich mitzulesen) ist es unterirdisch

Zitatfull und empty muss man denn eben nach ok und low ändern
hatten wir schon. Devices welche full,ok,low,empty zu verfügung stellen werden auf ok/low reduziert.
Ansonsten habe ich noch keine wirklichen Vorschläge.
Allerdings könnte man es ganz anders machen. Im Hinblick auf das fehlende Zentral-Modul zur Alarm/Status erfassung udn präsentation wäre es m.E. hinreichend ein Reading
batteryAlarm 'on|off'
definieren. So 2min überlegt ist das m.E. der richtige Weg. Eigentlich sollte man es
alarmBattery
nennen um dann erweitern zu können
alarmKommunkation 'on|off' (mir gefällt alarmProtocol besser, aber semantisch inkorrekt)
alarmAvailable  'on|off'  # Device dead,...
alarmMotor  'on|off' # melden HM devices mit Motoren (Heizungsregelung...)
alarmTemperatur 'on|off' # natürlich nicht aussen temperatur oder zu warm in Zimmer sondern die Übertemperatur eines dimmers

Der Sysadmin sieht die Probleme in der Alarmzentrale, sieht die betroffenen Devices und kann drauf clicken um die Fehler zu untersuchen. Alle weiteren details sind im Device selbst.
Zitat
aber wenn es schon mit so etwas einfachem wie einer batterie warnung nicht funktioniert
Sehe ich auch problematisch

Zitatdie ideen zu einem 'maintainance modul' finde ich gut. aber um irgendwann dahin zu kommen sollten wir klein anfangen und dran bleiben.
Sehe ich überhaupt nicht so. jemand mit Übersicht (ich habe zu weing unterschiedliche Modulfamilien) - und bitte! ein standardisierer mit gutem Überblick und weitsicht ist sollte es einfach beginnen. Es dauert sicher eine Zeit, bis es den Status erreicht, den ich mir Vorstellen. Man kann mal mit Batterie anfangen. Nicht wie ein Batterie-Modul mit allen details zu Batterien bitteschön. Das Kernteam (oder nur Rudi?) sollten es in die Hand nehmen oder unterstützen.
Welche Funktionen (nicht die Implementierung, die Features) ich mir Vorstelle kann man in HMInfo einsehen.

Zitatkann es sein das die emotionen teilweise so hoch kochen weil die semantik nicht klar ist.
So hoch kocht es doch garnicht. Und: es liegt nicht an der Semantik. Es liegt an den mir fehlenden Zielen (Standartisierung ist kein Selbstzweck) und die (unklare) Änderung bestehender Readings.
Ist das Ziel bekannt wäre ein Reading wie alarmBattery zielführender.

Ach, noch eine Idee.
Alarme sollten mehrere Level haben. Also ist 'on|off' evtl nicht sinnvoll. Besser wären - nach 10 min nachdenken - 'no|warning|error|critical'
In einem Alarm-Modul (der Name ist nicht programm) würde ich dann anzeigen
alarmBattery critical # höchster anstehender Alarn
alarmBatteryCnt ok:10,warning:2,error:0,critical:7
#unknown wäre eine warning
und in den Internals werden die problematischen an den Pranger gestellt
warnBat hzWohn,hzKind1,hzKind2,...
errBat hzSchlaf,hzKind3,hzKind4,...
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: KernSani am 30 Dezember 2018, 15:34:40
Ich habe jetzt lange mitgelesen, ohne mich zu äußern...
Ich finde Martins Gedanken der zusätzlichen Readings durchaus reizvoll, möglicherweise könnte man das noch generischer machen (also ein alarm-Reading, das standardisierte Messages, wie BATTERY_LOW oder COMMUNICATION_ERROR o.ä. zur Verfügung stellt) ist aber von mir noch nicht zu Ende gedacht.

Unabhängig davon habe ich TRX_WEATHER und TRX_SECURITY ein zusätzliches Reading "batteryState" verpasst. Aktuell werden sowohl "battery" als auch "batteryState" versorgt.

Irgendwann würde ich aber "battery" abklemmen wollen.
Hat irgendwer eine gute Idee, wie man die Umstellung anwenderfreundlich hinbekommt? Ich denke an sowas wie ReadingsRenameMap, vergleichbar mit AttrRenameMap.

Schönen Sonntag und Guten Rutsch,

Oli
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: rudolfkoenig am 30 Dezember 2018, 21:44:01
ZitatHat irgendwer eine gute Idee, wie man die Umstellung anwenderfreundlich hinbekommt?
Auf featurelevel pruefen, und es in UPGRADE + Ankuendigungen dokumentieren.

Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: papa am 30 Dezember 2018, 22:02:24
Kann man denn Zugriffe auf "deprecated" Readings loggen oder irgendwo anzeigen ? So würden auch User, die hier nicht alles lesen, vielleicht die Chance haben, auf Veränderungen zu reagieren.
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: KernSani am 30 Dezember 2018, 22:49:41
Zitat von: papa am 30 Dezember 2018, 22:02:24
Kann man denn Zugriffe auf "deprecated" Readings loggen oder irgendwo anzeigen ? So würden auch User, die hier nicht alles lesen, vielleicht die Chance haben, auf Veränderungen zu reagieren.
Ich denke eine ReadingRenameMap ähnlich der AttrRenameMap sollte einfach zu implementieren sein. Ich bastle da gerne schnell einen patch, ich kann allerdings nicht beurteilen, was das bezüglich Performance bedeutet...
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: KernSani am 30 Dezember 2018, 23:25:24
Um meinen Worten Taten folgen zu lassen... Nur mal als Vorschlag zur Diskussion.
Nutzung wäre analog zu AttrRenameMap:

    $hash->{ReadingRenameMap} = {
        "battery" => "batteryState"
    };


Berücksichtigt sind die ganzen Reading.* und OldReading.* Funktionen. Die OldReadings fallen natürlich einmal bei der Umstellung auf die Nase. Bei setreading würde ich spontan sagen, macht das nicht so viel Sinn, könnte man aber auch noch einbauen.

Edit: War zu schnell beim copy/paste ;-)
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: Sidey am 31 Dezember 2018, 00:21:13
Ich habe jetzt viel mitgelesen.
Einerseits kann ich das verstehen, dass man Readings nicht ändern sollte. Daher wäre ich dafür, dass man die Readings Zusätzlich bereitstellt. So habe ich es auch erst mal gemacht.

Ich habe jetzt viel mitgelesen.
Einerseits kann ich das verstehen, dass man Readings nicht ändern sollte. Daher wäre ich dafür, dass man die Readings Zusätzlich bereitstellt. So habe ich es auch erst mal gemacht.


Zitat von: martinp876 am 30 Dezember 2018, 14:44:50
definieren. So 2min überlegt ist das m.E. der richtige Weg. Eigentlich sollte man es
alarmBattery
nennen um dann erweitern zu können
alarmKommunkation 'on|off' (mir gefällt alarmProtocol besser, aber semantisch inkorrekt)
alarmAvailable  'on|off'  # Device dead,...
alarmMotor  'on|off' # melden HM devices mit Motoren (Heizungsregelung...)
alarmTemperatur 'on|off' # natürlich nicht aussen temperatur oder zu warm in Zimmer sondern die Übertemperatur eines dimmers

Der Sysadmin sieht die Probleme in der Alarmzentrale, sieht die betroffenen Devices und kann drauf clicken um die Fehler zu untersuchen.

Diese Alarmzentrale finde ich im übrigen ein sehr gute Idee. Das Problem, dass man durch Änderungen (egal ob es jetzt readings, Attribute oder sonst was ist) kann halt leider immer mal vorkommen und wir bekommen die Anwender heute immer erst reaktiv informiert.


Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: martinp876 am 31 Dezember 2018, 12:14:17
Wie gesagt, ich ordne mich unter. Was meine Meinung nicht ändert.
Das zwangs patchen von battery auf batteryState halte ich für einen üblen scherz. Da hat einer nicht aufgepasst.
Neben dem readingsname sind auch die werte betroffen - aber nicht behandelt
Alle user werden nun überrascht.

Wie so oft kann einer das wasser nicht halten. Die diskussion ist zwar nicht beendet aber weil es mal etwas länger dauert ( ist auch kompliziert) macht man halt mal schon etwas. Daher arbeite ich lieber mit profis - und halte mich hier besser raus.

Eins noch: Alarmzentrale: versaut es nicht. Es braucht etwas zeit, sich klar zu machen,  was der featurecontent sein soll. Übrlegt, ob der Begriff alarmzentrale programm ist. Evtl mal einen blick nach hminfo zum ideen sammeln. Das beinhaltet eben zentrale infos wie alarme, configcheck, protocoll events, alarme rücksetzen,.. eine systemInfo würde besser passen. Alarme suggeriert eh einigen dass alarme im allgemeinen betrachtet werden. Ich denke allerdings nur an internal events/ afferes. Externe alarme wie einbruch oder keller unter Wasser sind strikt zu trennen.
Und noch einmal: bei der implementierung dieser zentrale würde ich eine strikte disziplin verlangen. Wer sich anbinden will( also die modul Entwickler) muss sich den ( durchdachten) Anforderungen beugen. Auf keinen fall umgekehrt. Im notfall kann man das interface erweitern. Bitte eine gute professionelle spec des interface.

Sorry, nach den fhem.pl Schnellschuss bin ich ziemlich enttäuscht
Titel: Antw:battery / batteryLevel / ... -&gt; Vereinheitlichen
Beitrag von: KernSani am 31 Dezember 2018, 12:52:18
@Martin: Der Patch ist nur ein Vorschlag, wie man aus meiner Sicht die Problematik behandeln könnte, dass User die battery-Werte mit ReadingsVal etc... abgreifen. Der patch würde in dem Fall den batteryState-Wert zurück liefern und einen Eintrag ins Log schreiben. Analog zur bereits existierenden AttrRenameMap eben... Das wäre aus meiner Sicht besser als zu einem Zeitpunkt x, das Reading einfach nicht mehr zu befüllen. Aber das kann man ja alles diskutieren.


Kurz, weil mobil
Titel: Antw:battery / batteryLevel / ... -> Vereinheitlichen
Beitrag von: martinp876 am 31 Dezember 2018, 15:08:49
Sorry. Wenn es nur ein Vorschlag ist.
Dann nehme ich alles zum Vorgehen zurück und entschuldige mich.
Inhaltlich findet es nicht meine Zustimmung. Es ist Flickwerk. Fhem ist kuntabunt. Die Basis sollte standardisiert sein. Nicht nur einzelne reading, besonders auch das Verhalten. Das ist schwierig, klar. Daher braucht es eine Philosophie.

Was vorgeschlagen ist, kann ein user machen, wenn er will.  Die Basis implementierung sollte es nicht tun.

Ich komme wieder zu meinem systemInfo modul zurück, anderer aspekt. Das modul sollte wie gesagt infos, Checks, Alarme und Warnungen des Systems bereitstellen. Die Module stellen die Interfaces hierfür zu Verfügung. Ich denke in erster Linie an hw module und hier primär an home Automation Steuerung.
Der neue Aspekte ist, das der Modul owner der hüter des Grals ist. Über ihn laufen die Standardisierungen. Will jemand ein Modul anbinden hält er sich an die Interfaces spec oder bittet den lordsiegelbewarer um eine Erweiterung.

Was wäre erreicht? Alle module halten sich an ein interface. Das interface kann ausprobiert werden. Modul Entwickler werden sich um die Einhaltung selbst kümmern und es sukzessive erledigen.
Schwierig ist, den lordsiegelbewarer zu finden. Eine verantwortungsvolle Position mit Notwendigkeit zur ruhe, Übersicht Dokumentation,....
Hier gibt man dann in irgend einer form auch Infos zur Batterie ab