Standardisierte Battery Readings in 10_CUL_HM?

martinp876 · 25 Dezember 2018, 09:17:07

Also erst einmal implementieren wir Homematic nach FHEM und nicht umgekehrt. Ich bin ein Freund von Vereinheitlichungen...
nun die "abers" - welche mich zaudern lassen
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.

p.s.: Ich werde diesen Beitrag auch zur Diskussion der BAttery kopieren - wo es hin gehört.
Ich denke es sind erst einmal die key-Personen wie Rudi/Boris/... gefragt, hier präzise Regeln festzulegen

CoolTux · 25 Dezember 2018, 09:20:50

Zu Deinem 1.
https://wiki.fhem.de/wiki/DevelopmentGuidelinesReadings

CoolTux · 25 Dezember 2018, 09:25:04

Zitat von: martinp876 am 25 Dezember 2018, 09:17:07
=> 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".

Hier stimme ich Dir voll und ganz zu. Ich denke auch das es ein Kernteam (FHEM e.V. ??) sein sollte welches so grundlegende Dinge beschließt.

Grüße

frank · 25 Dezember 2018, 12:06:05

ZitatBatterie-Readings
Basierend auf dieser Diskussion haben sich die Entwickler für Readings, welche in Zusammenhang mit Batterien stehen auf folgendes geeinigt: Es gibt nur diese drei Readings für den Batteriestatus:

batteryState
batteryPercent
batteryVoltage
Wertebereich:

batteryState: ok|low
batteryPercent: \d{1,2}|100
batteryVoltage: \d+.\d+
Wichtig: 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.

nach dieser regel sehe ich keine möglichkeit einen batteriestatus=critical als reading zu presentieren.

1. weitere battery readings werden ausgeschlossen.
2. die wertebereiche der 3 nutzbaren readings verhindern die übergabe des wertes.

frage:
warum wurde eigentlich der wertebereich von batteryState auf low/ok begrenzt?

es wird wert darauf gelegt, dass "nur" gesendete werte in den readings erscheinen. aber warum wird kein wert darauf gelegt, alle gesendeten werte in den readings auf nehmen zu können?

betateilchen · 25 Dezember 2018, 12:44:28

Zitat von: frank am 25 Dezember 2018, 12:06:05
warum wurde eigentlich der wertebereich von batteryState auf low/ok begrenzt?

<Vermutung>
Weil immer wieder die gleichen Leute nach dem Rauchen irgendwelcher bewußtseinserweiternder Substanzen mit solchen sinnfreien Ideen um die Ecke kommen, überall alles zum Kochen bringen und dann die Ideen nicht bis zum Ende fertigdenken. Vermutlich weil die Wirkung der Substanzen bis dahin schon nachgelassen hat.
</Vermutung>

Und auch in einem "Kernteam" würde es vermutlich nicht nur Nichtraucher geben.

Die Argumentation von martin kann ich zu 100% unterstützen.

martinp876 · 25 Dezember 2018, 13:31:24

ok, vielen dank für den Link. Ich werde es also umsetzen - wie gesagt in der ersten januarwoche. So haben alle eine Vorwarnzeit (wenn sie diesen Threat finden

)
Ausser Batterie ist offensichtlich kein Reading definiert. Eigentlich schade.

martinp876 · 25 Dezember 2018, 14:43:16

Für alle, die einen Quicky für den Übergang brauchen:
mit UserReadings kann man sich behelfen. Allerdings "critical" ist ein Problem. Hier würde ich den kritischeren Fall voraussetzen und alle "neuen 'low'" auf "alte 'critical'" mappen.
Automatisch kann man das mit den Kommando

Code Auswählen

{foreach( devspec2array("TYPE=CUL_HM:FILTER=battery=..*:FILTER=userReadings!=.*batteryLevel.*")){$attr{$_}{userReadings}=(defined $attr{$_}{userReadings}?$attr{$_}{userReadings}.", ":"")."batteryLevel {ReadingsVal(\$NAME,\"batteryVoltage\",0)}, battery {ReadingsVal(\$NAME,\"batteryState\",0)eq\"ok\"?\"ok\":\"critical\"}"}}

erreichen - für User die hier eine solche Hilfe brauchen und suchen.

Für grundsätzliche Diskussionen zu den Batterie-readings bitte an die "Kerngruppe" wenden und dies im Wiki dokumentieren. Dann werde ich nachziehen - logisch.

Thorsten Pferdekaemper · 25 Dezember 2018, 14:59:49

Hi,
wenn es bei dieser Standardisierung nur darum geht, neue Readings einzuführen und die alten so bleiben, wie sie sind, dann bin ich auch dafür.
Allerdings wundere ich mich ein bisschen, dass der neue Standard anscheinend etwas an CUL_HM vorbeigeht. CUL_HM ist in FHEM das am meisten benutzte Modul (wenn man mal von Hilfsmodulen absieht). Daher hätte ich erwartet, dass jeder neue Standard ziemlich gut auf CUL_HM passt. (Außer es gibt gute Argumente dagegen.)
Kann man nach der Änderung das "critical" irgendwie zurück bekommen?
Gruß,
Thorsten

Pfriemler · 25 Dezember 2018, 16:49:49

Zitat von: Thorsten Pferdekaemper am 25 Dezember 2018, 14:59:49
wenn es bei dieser Standardisierung nur darum geht, neue Readings einzuführen und die alten so bleiben, wie sie sind, dann bin ich auch dafür.

Martins erste Idee war ja, von heute auf morgen die alten abzuschalten und die neuen einzuführen. Das allerdings erst, sobald dies als Standard festgeschrieben ist.
Ob das zum jetzigen Zeitpunkt so ist, da halte ich mich raus.

ZitatAllerdings wundere ich mich ein bisschen, dass der neue Standard anscheinend etwas an CUL_HM vorbeigeht. CUL_HM ist in FHEM das am meisten benutzte Modul (wenn man mal von Hilfsmodulen absieht). Daher hätte ich erwartet, dass jeder neue Standard ziemlich gut auf CUL_HM passt. (Außer es gibt gute Argumente dagegen.)

Wenn ich den Verlauf der Diskussion so lese, waren sowohl das "critical" als auch "empty" etc. bei EnOcean sehr schnell unter den Tisch gefallen, als es um einen "kleinsten gemeinsamen Nenner" ging. Der bezog sich aber aus meiner Interpretation mehr auf die Anzahl und Benennung der Readings und nicht den Wertebereich. Dass man dann künftig hilfreiche und vorhandene Informationen ignoriert, war ja nie Gegenstand der Diskussion.

ZitatKann man nach der Änderung das "critical" irgendwie zurück bekommen?

Ich würde wie einige meiner Vorredner dringend dafür plädieren, den "Standard" nachzubessern. Es ist richtig, keine Readings zu "erfinden" (bzw. zu interpetieren aus anderen Infos), die das Gerät nicht liefert, aber wenn die Geräte - egal welchen Moduls - definitiv mehr Informationen liefern, macht es keinen Sinn, sie aus "Standardisierungsgründen" zu verwerfen. Selbst die von Amenophis86 geplante zentrale Batterieüberwachung dürfte davon profitieren. Und wie ich schon sagte: Wer partout für seine Zwecke nur zwei Zustände braucht, nämlich "ok" und "nicht ok", bekommt das problemlos auch mit größeren Wertebereichen hin, weil low, critical, empty und dead eben alles andere als "ok" sind.

Würde ich "critical" nutzen, käme bei einer modulbasierten Ignoranz CUL_HM künftig ins exclude und ich würde es nur noch händisch updaten. Das kann aber auch nicht Sinn der Übung sein.

Pfriemler · 25 Dezember 2018, 16:53:54

Zitat von: martinp876 am 25 Dezember 2018, 09:17:07
... p.s.: Ich werde diesen Beitrag auch zur Diskussion der BAttery kopieren - wo es hin gehört.

Ja, mach mal. Ist bisher nicht passiert.

frank · 26 Dezember 2018, 17:07:12

offensichtlich sind die entwickler von fhem überfordert mit kritischen batteriezuständen um zu gehen. scheinbar ist hier eine unüberwindbare grenze erreicht. wirklich schade.

seltsamer weise werden nun infos über systemkritische zustände kurzer hand einfach verworfen, als würden sie gar nicht existieren. und ich meine nicht nur batteryState=critical. es wird ja alles verworfen, was nicht low/ok ist. damit werden sogar alle zukünftig erfassbaren zustände bereits jetzt ausgeschlossen. zb eine früherkennung, um explodierende batterien zu verhindern.

diese tatsache finde ich immer unglaublicher, je länger ich darüber nachdenke. so krass sich betateilchens vermutung auch anhört, aber dem kern seiner aussage muss ich zustimmen: die derzeitig gültige regel kann nicht zu ende gedacht sein.

wäre diese regel auch entstanden, wenn zwave criticalBat senden würde?

@martin
wenn du dich diesem irsinn schon anschliesst, würde ich dich bitten bei critical kein fake-low zu erzeugen. lieber gar nichts aktualisieren, dann könnte ich vielleicht über ausbleibende low/ok events auf critical rückschliessen.

oder schenke mir ein reading deviceError=criticalBat.

Frank_Huber · 26 Dezember 2018, 18:23:05

Ich hab das nicht bis in jeden Post verfolgt,
Aber IMHO ging es bei der Vereinheitlichung hauptsächlich um die Namen der Readings und weniger um den Inhalt.

Wenn es für den Batterie Zustand 15 verschieden benannte Readings gibt ist ja auch keinem geholfen.
Geht ja schon los mit "Battery", "battery", "Batterie" oder "Batterie"......

Über gültige Wertebereiche kann man ja dann abstimmen.
Einem ok/low auch ein critical zu spendieren sollte ja das kleinste Problem sein.

Ich denke wir wollen hier alle FHEM vorwärts bringen, das geht aber nur wenn auch alle an einem Strang ziehen und sich nicht hier zerfleischen. [emoji6]

Gesendet von meinem Doogee S60 mit Tapatalk

CoolTux · 26 Dezember 2018, 18:35:23

Ich finde diese ganze Diskussion sowas von ...
Was bitte schön ist daran so schwer einfach im Developer Forum ein critical zur Diskussion zu stellen. Ich behaupte Mal das niemand was dagegen hätte. Aber anscheinend ist es für ein paar Leute einfacher sich darüber tagelang das ... zu zerreißen wie Kurzsichtig aus deren Sicht gedacht wurde. Ja es würde hier eine gewisse Kurzsichtigkeit entdeckt, dann stellt es einfach zur Diskussion. Fehler sind dazu da um aus ihnen zu lernen. Und die jenigen die sich jetzt hier aufspielen hatten damals die Möglichkeit das auf zu machen welches sie sich aktuell zerreißen. Keine Meinung zu haben ist schlimmer wie eine Meinung zu haben und noch schlimmer ist es sich später darüber auf zu regen. Ist ja wie in der Politik hier, die Leute gehen bestimmt auch nicht wählen und Beschwerden sich im Nachhinein darüber wie Schei...e die Regierung ist.

Pfriemler · 26 Dezember 2018, 19:04:30

Zitat von: CoolTux am 26 Dezember 2018, 18:35:23
Ich finde diese ganze Diskussion sowas von ...
Was bitte schön ist daran so schwer einfach im Developer Forum ein critical zur Diskussion zu stellen.

Ich sag's zum dritten Mal: Ich habe dort keine Schreibrechte, weil ich kein Developer bin

Bist Du bitte so gut und fügst nach martins Statement von heute 17:xx nochmal etwas deutlicher an was unser (bisher einziges) Problem hier ist, etwa:
"Einige Homematic-Geräte liefern zusätzlich zu "low" einen weiteren Batteriestatus "critical". Dies drückt aus, dass die Batterien unmittelbar gewechselt werden müssen, weil die Funktionsfähigkeit des Gerätes sonst nicht mehr gegeben ist. Es ist nicht hinzunehmen, dass diese wichtige Warnung der angedachten Reduzierung des Wertebereichs auf "ok|low" zum Opfer fällt. Hier sollte nachgebessert werden."
und eventuell
BTW: Wenn in einer Auswertung unbedingt nur zwei Zustände anzunehmen sind, könnte man statt "low" auch auf 'ne "ok"' triggern."

Ich täte es selbst, aber wie gesagt, ich darf es nicht.

Davon abgesehen war ich überrascht zu sehen, dass meine Batterieüberwachung bei den FHT-Fenstersensoren bereits batteryState erwartet ...

CoolTux · 26 Dezember 2018, 19:29:16

Zitat von: Pfriemler am 26 Dezember 2018, 19:04:30
Ich sag's zum dritten Mal: Ich habe dort keine Schreibrechte, weil ich kein Developer bin

Bist Du bitte so gut und fügst nach martins Statement von heute 17:xx nochmal etwas deutlicher an was unser (bisher einziges) Problem hier ist, etwa:
"Einige Homematic-Geräte liefern zusätzlich zu "low" einen weiteren Batteriestatus "critical". Dies drückt aus, dass die Batterien unmittelbar gewechselt werden müssen, weil die Funktionsfähigkeit des Gerätes sonst nicht mehr gegeben ist. Es ist nicht hinzunehmen, dass diese wichtige Warnung der angedachten Reduzierung des Wertebereichs auf "ok|low" zum Opfer fällt. Hier sollte nachgebessert werden."
und eventuell
BTW: Wenn in einer Auswertung unbedingt nur zwei Zustände anzunehmen sind, könnte man statt "low" auch auf 'ne "ok"' triggern."

Ich täte es selbst, aber wie gesagt, ich darf es nicht.

Davon abgesehen war ich überrascht zu sehen, dass meine Batterieüberwachung bei den FHT-Fenstersensoren bereits batteryState erwartet ...

Aber warum soll ich Martin entmündigen. Ist er nicht alt genug für sich und sein Modul entsprechend zu argumentieren.
Die wichtigen Punkte welche ein ordentliches Gewicht in die Waagschale werfen wurden doch genannt. Alter des Moduls und User. Das berechtigt auf alle Fälle eine Diskussion und ich stimme persönlich für die Erweiterung. Und ja man kann später auch über eine Zustandsmeldung nach denken oder dafür ein eigenes Reading nehmen.
Aber es muss darüber erstmal geredet werden. Als Developer hat man nicht nur das Recht Module zu entwickeln und sie offiziell zu machen sondern auch die Pflicht sofern man Teil der Entwicklung sein will an Entwicklungsdiskussionen teil zu nehmen. Tut man dies nicht und meckert Monate später über die Entscheidung wirft das in meinen Augen kein gutes Licht.
Ich nehme mich persönlich im übrigen nicht aus. Auch ich hatte ein zweimal kein großes Interesse an einer solchen Diskussion über eine Entscheidung Teil zu nehmen. Halte mich dann aber auch mit Kritik später über die Entscheidung zurück und lebe damit. Immer hin habe ich selbst nichts dazu bei getragen.