battery / batteryLevel / ... -> Vereinheitlichen

[rudolfkoenig]

Hab den Patch von sledge fuer MAX eingecheckt.
Habe nicht damit gerechnet, dass man batteryState an 4 verschiedenen Stellen erstellen muss.

[HCS]

Wie wäre es denn, die Umstellung auf die neuen Readings (also den rename) an featurelevel 5.9 zu binden?

[Sidey]

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

[betateilchen]

zumindest bei 41_OREGON.pm scheint es ein Problem zu geben.

https://forum.fhem.de/index.php/topic,89120.0.html

[Amenophis86]

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

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.

[zap]

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:

Code Auswählen Erweitern


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


[martinp876]

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

[Amenophis86]

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

[martinp876]

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.

[rudolfkoenig]

nun, 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:

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

[CoolTux]

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.

[Amenophis86]

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.

[martinp876]

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.

[Markus M.]

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.

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

[martinp876]

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.

Kurz: ich werde nicht mit Konsequenzen drohen,

Warum auch. Wenn es pflicht ist, baue ich es ein und erwarte, dass es überlegt ist.

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.

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)

Ich 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

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