battery / batteryLevel / ... -> Vereinheitlichen

[martinp876]

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

[KernSani]

@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

[martinp876]

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