battery / batteryLevel / ... -> Vereinheitlichen

[Markus M.]

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

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.

Könnte man versuchen zu dokumentieren.

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

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.

Irgendwo muss mal jemand anfangen, diesen Thread hier empfand ich als einen guten und sinnvollen Ansatz.
Und deshalb habe ich meine Module auch angepasst.

[martinp876]

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

Kö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.

Irgendwo 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?

[Amenophis86]

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.

[martinp876]

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.

[martinp876]

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.

[justme1968]

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.

[justme1968]

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. 

[Amenophis86]

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.

[martinp876]

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!

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

fü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

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

aber wenn es schon mit so etwas einfachem wie einer batterie warnung nicht funktioniert

Sehe ich auch problematisch

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

kann 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,...

[KernSani]

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

[rudolfkoenig]

Hat irgendwer eine gute Idee, wie man die Umstellung anwenderfreundlich hinbekommt?

Auf featurelevel pruefen, und es in UPGRADE + Ankuendigungen dokumentieren.

[papa]

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.

[KernSani]

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

[KernSani]

Um meinen Worten Taten folgen zu lassen... Nur mal als Vorschlag zur Diskussion.
Nutzung wäre analog zu AttrRenameMap:

Code Auswählen Erweitern


    $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

[Sidey]

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.

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.