Standardisierte Battery Readings in 10_CUL_HM?

[Pfriemler]

Das hat doch mit "entmündigen" nichts zu tun. Ich wollte nur anmerken, dass sich Martin dort bereits geäußert hat, aus meiner Sicht vielleicht nicht deutlich genug.
Wobei ich die Änderung von "critical" auf "low_critical" nicht mal schlecht fände.

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

Damit kritisierst Du aber nicht DEN Modulautor, sondern mehrere Leute, die sich darüber echauffieren, mich eingeschlossen. Wo aber bitte soll ich mich außern, wenn nicht hier?

Liebe Developer, bitte sorgt dafür dass die Argumente gehört werden. Es ist alles gesagt. Alles weitere liegt nicht mehr in meiner Macht.

[Amenophis86]

Leute Leute, was hier los ist. Ein Problem wurde erkannt und nun geht es daran dies zu lösen. Nicht mehr und nicht weniger. Nix wurde geheim entschieden und niemand vor vollendete Tatsachen gestellt, die sich vor allem nie wieder ändern lassen.

Und @betateilchen: netter Beitrag, vor allem, wenn man bedenkt, dass du im entsprechenden Thread einer der ersten Poster warst. Da verstehe ich deinen Beitrag hier nicht wirklich in dieser Form...

@all: Ich denke die Idee in eine Software wie FHEM gewisse Standards zu bringen ist nicht schlecht und um diese Idee geht es. Daher entspannt euch mal wieder, erkennt den guten Willen und übt konstruktive Kritik. Wir sind nicht bei Logitech und es wurden eben mal aus FHEM alle anderen Systeme spontan ausgesperrt, weil jemand Bock hatte. Und selbst die haben eingelenkt

Außerdem ist noch Weihnachten

[frank]

Ein Problem wurde erkannt und nun geht es daran dies zu lösen.

danke, das ist die erste positive nachricht zu diesem thema.

bis vor 3 stunden sah das aber noch völlig anders aus. 

[zap]

Irgendwie muss ich was verpasst haben. Bisher gab es in FHEM eigentlich nur best practice Standards. Das kann man gut finden oder auch nicht. Hat aber bisher einigermaßen funktioniert. Nun scheint es plötzlich so zu sein, dass einzelne User einen Vorschlag für einen neuen Standard machen. Dann diskutieren ein paar Leute darüber, die zufällig den Thread gelesen haben, werden sich einig und schon ist der neue Standard verabschiedet. Und nur weil es im Wiki steht, das auch jeder ändern kann, macht es auch nicht automatisch zu absoluten Wahrheit.

Ich bin in einem Alter, wo ich solche Vorgehnsweisen vermutlich aufgrund beginnendem Altersstarrsinn erst recht ignoriere.

Ich würde es jedoch akzeptieren, wenn es eine Art Kernteam geben würde, das solche Entscheidungen trifft, wie das in vielen großen OpenSource Projekten der Fall ist. Das sollten dann Leute sein, die die Tragweite ihrer Entscheidungen wirklich überblicken.

[martinp876]

Nun, wie schon mehrfach erwähnt werde ich mich dem fhem-standart unterordnen und ihn implementieren, so er verabschiedet ist. Ich habe parallel bei Rudi angefragt, wie das so mit "veranschieden von Standards" ist und ob in der developer wiki  Ecke jeder einfach einmal einen aufstellen darf.
Das Batterie reading ist nun die Diskussion fast nicht wert, einen workaround gibt es auch. Also alles halb so schlimm.
Dennoch erwarte ich von Rudi und der Kerntruppe ein paar klare Richtlinien welche,  wie gesagt unter Abwägung der aktuellen Verbreitung, dem Risiko, der Kompatibilität über die produktfamilien hinweg und der Zukunftsfähigkeit erstellt werden. Keine leichte Aufgabe. Sollte der Beitrag im wiki dies nicht durchlaufen haben ist er noch nicht reif und wird nicht scharf geschaltet.
Die Freiheit von fhem ist gut und innovativ. Allesdings ist es mittlerweile so gross dass Standards klar definiert werden sollten.
Auf der Oberfläche wünsche ich mir, neben "privaten" neuen ideen auch verlässliche standardmodule zur systemwartung und Übersicht. Ein allgemeines "system-health" modul welches mir kurz einen Hinweis auf probleme gibt. Für hm leistet dies hminfo (zustandsübersicht, alarm sammler einstellbar, battery, dead or alive,...) Um das übergreifend zu sinnvoll implementieren braucht es standards.....

[Damu]

Möchte hier auch was dazu sagen:
Zwei Batteriezustände: "low" und "ok" finde ich echt zu wenig.
Die Ide mit

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.

ist besser.
Es geht mir hier mehr um die 0-5, als um die Begriffe.

Hoffe es findet sich eine Lösung die für alle ok ist.

[Pfriemler]

Nach Martins letztem Statement im Developer-Forum sehe ich mich - anstelle einer PM - genötigt, leise Einwände zu äußern, die ich aber gleichzeitig zur Diskussion stelle - kann ja sein dass ich falsch liege.

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

batteryLevel ist in CUL_HM eine Spanungsangabe ohne Einheit. Hätte in CUL_HM eine Änderung bewirken müssen.
Aber es soll ja sauberer zwischen batteryPercentage und batteryVoltage unterschieden werden.

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

Die wenigsten Devices haben "critical". Bei den hier schon zitierten Geräten "Stellantrieb" und "Außensirene" sind damit wohl kritische Zustände gemeint - ein Gerät mit schwachem Batteriezustand wird noch funktionieren, ein Gerät mit kritischem Energiezustand hat vermutlich noch genug Saft, um mit der Zentrale zu kommunizieren, aber eben nicht mehr für den eigentlichen Betrieb - einen Motor zu bewegen oder den Blitzer/Sirene für eine sichere Alarmierung. Da muss der User nicht schneller laufen  - die Funktion des Gerätes ist nicht mehr vollständig gegeben. Des Benutzers Erfahrung mag ihm mitteilen, dass eine "low" Battery noch eine Weile funktioniert (SCos laufen bei mir mindestens noch einen Monat, ebenso RT-DN, beim Neigungssensor TIS  habe ich erst ein halbes Jahr später die Batterie getauscht, obwohl die Funktion noch gegeben war. ... bei "critical" MUSS der User umgehend handeln.
"dead" hat nur Sinn bei Geräten, die noch kommunizieren können, also etwa in Bezug auf eine Pufferbatterie. Bei reiner Batteriespeisung ist das ganze Gerät "dead" - so wie es der ActionDetector schon jetzt ausweist - hier stimme ich Martin übrigens voll zu, CUL_HM ist hier weit voraus.

Mit "discharge1" etc. kann ich ehrlich GAR NICHTS anfangen. Das assoziiere ich mit der aktuellen Batteriebehandlung durch das Gerät, das ist aber eigentlich kein Thema gewesen. UNd das Mapping von "critical" auf eine andere Wertebezeichnung halte ich schon wieder für eine fragwürdige Interpretation, allenfalls "low_critical" macht für mich Sinn.

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?

1. Neue Readings heben sich dadurch hervor dass sie neu sind. Man kann sehr gut erkennen, ob die neuen Regeln umgesetzt sind.
2. Neue Namen charakterisieren die Werte besser. Ein Level ist eine allgemeine Höhenangabe, der Bezug ist völlig unklar. Eine Spannung ist eine Spannung (voltage) und eine Prozentangabe eine Percentage. Da muss man nicht mehr rätseln, was was ist. Und "battery" ist ein Oberbegriff für einen Energiespeicher. Wenn man umgangssprachlich meint, dass eine Batterie "ok" ist, dann assoziiert man damit allgemein, dass sie noch genug Saft hat - aber man kann auch damit meinen, dass sie technisch sicher ist, für den Einsatzzweck geeignet ist usw, oder dass ihr Gesamtzustand noch brauchbar ist - etwa eine Lebensalterabschätzung durch Innenwiderstandsmessung, wie sie bei der Pufferakkuüberwachung Standard sein sollte. Das wäre aber eher was für "batteryCondition".
batteryState ist übersetzt "Batteriestatus". Das ist zwar auch etwas allgemein, aber zumindest assoziiert "ok" keinen Handlungsbedarf.

=> ich habe immer versucht, existierende Readings zu nutzen. Namen und Werte. Jetzt machen wir halt einmal etwas Neues?

Man mag wirklich darüber streiten, ob es Sinn macht, einen weit etablierten Begriff wie "battery" zu ersetzen. Das meint wohl auch Thorsten, wenn er die Beibehaltung der Vorgaben von eQ3 in der XML fordert. Insofern kann man den Schwarzen Peter aber an eQ3 weiterreichen, denn deren Benamung ist in diesen Punkten eben auch nicht eindeutig und daher verbesserungswürdig. Da wir eQ3 nicht beeinflussen können ...

[Paul]

Ich glaube die 3 Seiten hättet ihr euch sparen können. Da der wiki Beitrag so keinen Bestand hat.

Aufgrund der Aussage

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

Habe ich auch festgestellt, dass meine Batterieüberwachung seit August nicht mehr funktioniert.

Darauf habe ich im SlowRF nachgefragt, weshalb bei den zugehörigen FHT80 keine Änderung vorgenommen wurde.

Mir wurde von höchster Stelle gesagt,dass es sofort nachgezogen wird, aber battery aufgrund der vielen Abhängigkeiten weiterhin bestehen bleibt.

Jetzt haben mein FHT80 einmal battery und BatteryStatus

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

[martinp876]

Hallo Pfriemler,

zu BatteryLevel: Zustimmung. CUL_HM müsste ändern. Hatte ich schon erwähnt

batteryVoltage: wenn die Spannung ausgegeben wird. CUL_HM müsste ändern.

Dead ist immer noch nicht verstanden. Natürlich meldet nicht das device "ich bin tot". Das ist eine überwachung der Zentrale (Action Detector). Bei CUL_HM realisiert auf 2 Methoden: Devices melden sich regelmäßig. Wenn nicht sind sie tot. Manche (eigentlich fast alle Batterie devices) unterstützen das.
Für andere Devices kann man so etwas erzwingen. FHEM sendet einen StatusRequest (wenn vom Device unterstützt). Sollte das nicht beantwortet werden ist das Device tot.
=> stellt sich die Frage. welche Readings mit "tot" überschrieben werden. Battery wäre in jeden Fall sinnvoll.

"dead" hat nur Sinn bei Geräten, die noch kommunizieren können, also etwa in Bezug auf eine Pufferbatterie

=> ist also komplett falsch, da das Verfahren damit GARNICHTS zu tun hat.

Mit "discharge1" etc. kann ich ehrlich GAR NICHTS anfangen

Verstehe ich. Sehe ich wie Paul: Die Level sind wichtig, die Namen noch zu finden. Hierbei sollte man erfassen, welcher Level "ok" ist (full, ok), welche warning (low?) und welche kritisch.

Ich will definitiv nicht betrachten, wie, wie lange und was an einem Device noch funktioniert. Das ist dann Sache den Jeweiligen Entwicklers und seiner User. Battery braucht nur die Platform, so etwas auszudrücken. Grundsätzlich ist hier eine Semantik festzulegen.
- devices werden manchmal 2 level unterstützen, manchmal mehr
- wird FHEM hier nur 2 Level haben? Die Info der Devices ist auf 2 zu reduzieren - period?
- es gibt mehr (5?) level. Sind die üblichen dann 3=ok und 4=low, die Anderen sind weitere Verschärfungen?
- es gibt mehr (5?) level. Sind die üblichen dann 1=ok und 5=low, die anderen sind Zwischenschritte?

So etwas ist m.E. einmal grundsätzlich zu definieren und dann sinngemäß durchzuziehen.

Die aktuelle Änderung halte ich für ... mehr als unschön. Weil sich dafür entschieden wurde, die 90% vorhandenen "battery (ok|low)" zu ändern.

Ich verstehe hier nicht, wie mit den User umgegangen wird. Es gibt Bastler welche immer am Ball bleiben. Andere arbeiten sich ein, bauen sich ein system und... nutzen es dann einfach. Ein Reading zu ändern ist "gemein". Sie müssen erst einmal merken, dass es einen Trigger nicht mehr gibt. Wenn wir Battery gegen batterystate tauschen bleibt battery vorhanden. Der User wiegt sich in Sicherheit... bis es kracht.
=> FHEM ist m.E. in seiner Basis aus der Bastelphase entwachsen." Mal schnell ändern" hat Konsequenzen- und muss also einen Grund haben.

[Pfriemler]

Hallo Martin,
Du hast mich teils missverstanden. Wir sind dennoch in vielen Punkten einer Meinung, auch wenn das vielleicht nicht so rüberkam.
1. Du schriebst in Development:

batteryLevel: kann man für Prozent einfach lassen. Kein Grund zu ändern
batteryVoltage: wenn die Spannung ausgegeben wird. CUL_HM müsste ändern.

Ich wollte damit sagen: CUL_HM müsste so oder so ändern, weil batteryLevel in CUL_HM auch kein % ist.

2. "dead" ist in CUL_HM derzeit ein Zustand des Gerätes, festgestellt vom ActionDetector. "dead" hat mit dem Batteriezustand absolut nichts zu tun, zumal kein mir bekanntes Gerät hier "dead" liefert. Ich halte es nicht für sinnvoll, das von CUL_HM nach "battery[Status]" mappen zu lassen. "dead" werden doch sicher auch alle HM-Geräte automatisch, wenn kein HM-IO mehr funktionsfähig ist (und daher überhaupt keine zyklischen Statusmeldungen mehr in FHEM ankommen) - oder hast Du diesen Fall berücksichtigt? Definitiv fallen Geräte jedenfalls regelmäßig in "dead", wenn es Funkprobleme gibt. Was mit Batterie eben nichts zu tun hat. Punkt.

3. Sind Abstufungen des Batterie(lade)zustandes vorhanden, gehören sie m.M.n. nach "batteryPercent" und nicht nach "battery[State]".
"ok" ist eine Batterie in 70-80% ihrer Laufzeit. Viele Geräte (aus der Nicht-Smarthome-Ära) reklamieren Batterien etwa bei diesem Level als austauschwürdig, nach meinen Erfahrungen und Messungen (habe u.a. Batterien in Messgeräten "restentleert").
Du hast recht, das ist eine Festlegungsfrage - aber sie tritt eh nur auf, wenn das Gerät selbst keinen simplen BatterieStatus liefert, sondern nur eine prozentuale Angabe. Solche Geräte kenne ich jedenfalls nicht.

Die aktuelle Änderung halte ich für ... mehr als unschön. Weil sich dafür entschieden wurde, die 90% vorhandenen "battery (ok|low)" zu ändern.

Das unterschreib ich, dann argumentier das so an der richtigen Stelle - in Development, im Wiki, in der Wiki-Diskussion, ...?
Vielleicht findest Du mehr Unterstützer dort als Du denkst.
Und vergiss nicht "low_critical" bzw. "critical" ... 

Nachtrag: Wir sollten bei der Diskussion immer die Sachen trennen:
1. Wie sollen die Readings künftig heißen (umbenennen, welche beibehalten, ...)
2. Welcher Wertebereich ist sinnvoll, ohne dass signifikante Infos verloren gehen.
3. wie sollte der Übergang gestaltet werden. Dazu gab es zuletzt sinnvolle Einwendungen, feature level betreffend (finde ich).

[martinp876]

Wir sind dennoch in vielen Punkten einer Meinung

Sehe ich auch so.

Ich wollte damit sagen: CUL_HM müsste so oder so ändern, weil batteryLevel in CUL_HM auch kein % ist

sagte ich(etwas indirekt) auch schon. Aber erst wenn das Konzept komplett steht. Auch der "State"

"dead" hat mit dem Batteriezustand absolut nichts zu tun

sehe ich nicht so. Es ist der Zustand nach "low" welcher von der Zentrale festgestellt werden muss. Macht die HMCCU ähnlich. Ist quasi auch so beschrieben.
Wenn die Batterie leer ist bleibt im Reading immernoch "low". Inhaltlich quatsch. Man kann es mit Dead mappen.

Ich halte es nicht für sinnvoll, das von CUL_HM nach "battery[Status]" mappen zu lassen.

ok - bin ich auch vorsichtig. Daher ist es ja auch nicht gemacht (ich denke nicht erst seit jetzt darüber nach )

Was mit Batterie eben nichts zu tun hat.

hier wieder keine Übereinstimmung. Typisch ist es eben schon die Batterie.

Aber: wie man es richtig macht. Mit einem zentralen Alarm-modul. Dieses sollte die kritischen Zustände sammeln und auswerten. Macht eine professionelle bedienfreundliche SW so. Will sagen: unterliegende Alarme (ich rede von Maintenance, interne Alarme) werden nur angezeigt, wenn kein überliegender vorliegt. Wenn also ein IO zu Verfügung steht wird (in der Alarmzentrale) ein Alarm für das IO (in CUL_HM die vccu) angezeigt. "Dead" werden ausgeblendet, ebenso wie rssi -alarme oder protokoll-alarme. Nicht gelöscht, nicht im Device. Aber im Alarm/System-Cockpit.

Sind Abstufungen des Batterie(lade)zustandes vorhanden, gehören sie m.M.n. nach "batteryPercent"

keine Zustimmung. Kann man aber so entschienden.

"ok" ist eine Batterie in 70-80% ihrer Laufzeit.

verstehe ich nicht.
1) das Device weiss nicht, ob ein Akku oder eine Batterie eingelegt ist.
2) der Level ist viel zu hoch, da ich bei "low" an das tauschen denke. Also sollte "low" bei 10-20% der Kapazität. Ah - hast du das so gemeint?
3) das kommt typisch sowieso aus den Device und kann nicht beeinflusst werden.

dann argumentier das so an der richtigen Stelle

steht schon drin. Allerdings habe ich viel angeschnitten. Das macht es kompliziert. Ist nur so, dass mir an einigen Stellen die Basis und strikte Führung in FHEM fehlt.

Nachtrag: Wir sollten ...

Zustimmung.
Für mich extrem wichtig: Wann und wie baut jemand ein FHEM-HW-control-center. Also das Teil analog HMInfo welches
- alarme sammelt und darstellt
- eine KURZE! Systemübersicht gibt - was ist aktiv,...
- zwischen Info/Warning/error/critical unterschieden kann
- Alarme Quittieren und ausblenden kann
und das nicht selbst aus den Modulen destiliert sondern die Modulentwickler zwingt, ordentliche und standartisierte Infos breitzustellen

Übrigens werden ich über den Einwürf nach denken, IO Fehler besser darzustellen. Im Device und in HMInfo. Und in den Kanälen.
In meiner Instalation werde ich dann auch die Readings "ausblenden". Hatte es schon zu oft, dass die Power-gierigen Temperatur Sensoren leer waren und das Temp-reading einfach stehen bleibt.
Ich werden es wohl als Attribut anbieten:
attr failReplaceValue: (no,dead,0,<userdef>)
könnte man in jeder Entity setzen und dann bei "last-IO-OOS" oder Device dead werden die "running parameter" wie temperatur "geklemmt" - oder eben nicht.

[Pfriemler]

Es könnte sein, das "dead" das Ergebnis einer leeren Batterie ist. Wenn wir Erkenntnisse haben. Was ActionDetector aber derzeit einzig aufgrund fehlender Meldungen des Devices - aus welchen Gründen auch immer - annimmt, ist ein "probably dead". Hat es zuvor lange einwandfrei funktioniert und rechtzeitig eine "low"-Warnung gesendet, wird die tote Batterie höchstwahrscheinlich - aber eben nicht sicher - die Ursache sein. Typisch, wie Du sagst.
Was aber nur sicher ist: das Gerät liefert keine Daten. Aber es ist sinnlos, den User zum Batteriewechsel zu schicken, weil das Gerät tatsächlich aus anderen Gründen nicht kommunizieren kann. Wenn also ein AlarmModul/interface dem User das Nichtfunktionieren des Gerätes meldet und gleichzeitig auf den zuvor dagewesenen niedrigen Batteriezustand hinweist, fände ich das ok. Aber ein "dead" aufgrund einer blockierten Kommunikation ist eigentlich nicht hinnehmbar. Hier sind die Grenzen fließend: Schon der sehr temporäre Ausfall eines HM-Interfaces, welches als einziges ein entfernteres Gerät liest, kann dazu führen, dass ActionDetector auf "dead" erkennt. Ich habe das bei den SCos und bei einem Schalterinterface am Briefkasten sehr regelmäßig - bei letzterem auch, weil dort von mir ein falsches Interval eingestellt ist - es reicht schon, dass der Briefkasten einen Tag lang nicht "bedient" wurde (was hier ein halbes Dutzend Mal im Jahr vorkommt) und ein Gerät ist "dead" ... Daher meine Weigerung, beim "anscheinlichen" Ausfall eines Gerätes auf "dead" zu erkennen.
Kurz: "dead" für ein Batteriereading ohne vorherige Anzeichen von schwacher Batterie ist Quatsch. Mit vorheriger Meldung einer schwachen Batterie bleibt es eine sinnvolle zwar, aber dennoch Vermutung. 

Zu Deinem "wie man es richtig macht: " volle Zustimmung.

2) der Level ist viel zu hoch, da ich bei "low" an das tauschen denke. Also sollte "low" bei 10-20% der Kapazität. Ah - hast du das so gemeint?

Natürlich.

(Batterie ok) 3) das kommt typisch sowieso aus den Device und kann nicht beeinflusst werden.

Bei Homematic ja. Aber aus der Developer Diskussion entnehme ich, dass es durchaus Geräte zu geben scheint, die stattdessen ein mehrstufiges Ranking liefern. Diese Details sähe ich lieber in batteryPercentage als in battery(State).

Die Akku/Batterie-Problematik ist eine andere. Viele Geräte können von sich aus nicht mit Akkus umgehen, bei HM ist mir kein Gerät bekannt, dem man das explizit sagen kann. Bei einigen ist es indirekt durch das Setzen der lowBat-Schwelle möglich.

Und Deine Argumentationen ...

steht schon drin. Allerdings habe ich viel angeschnitten. Das macht es kompliziert. Ist nur so, dass mir an einigen Stellen die Basis und strikte Führung in FHEM fehlt.

Zustimmung. Aus meiner Sicht gehen Deine/unseren konkreten Vorschläge im Text leider etwas unter. Aus meinen Diskussionserfahrungen ist es sinnvoll, seine Ziele oder Vorschläge gelegentlich, ggf. formulierungsangepasst oder gestrafft, zu wiederholen. Das vermisse ich.
Der Konsenz liegt doch auf der Hand, aber er wird nicht ausgesprochen, schade.

Für mich extrem wichtig: Wann und wie baut jemand ein FHEM-HW-control-center. Also das Teil analog HMInfo welches
- alarme sammelt und darstellt
- eine KURZE! Systemübersicht gibt - was ist aktiv,...
- zwischen Info/Warning/error/critical unterschieden kann
- Alarme Quittieren und ausblenden kann
und das nicht selbst aus den Modulen destiliert sondern die Modulentwickler zwingt, ordentliche und standartisierte Infos breitzustellen

Hallelujah. Bin ich VOLL dabei.

Hatte es schon zu oft, dass die Power-gierigen Temperatur Sensoren leer waren und das Temp-reading einfach stehen bleibt.

Ähnliche Probleme hatte ich früher mit CUL_WS-Sensoren. Mal kamen die Telegramme alle fünf Minuten, dann stunden- oder tagelang nicht, kein System erkennbar. In der Oberfläche stehen bei mir seit längerem die Zeiten der Werte via stateFormat. Das hilft schonmal. Anderswo wird hier gerade daran gebastelt, wie man solchen Werten eine auffällig andre Farbe verpassen kann. Sinnvolle Infos zur Gültigkeit abseits des Readingsalters würden hier ungemein helfen, Zustimmung.

[martinp876]

Es könnte sein, das "dead" das Ergebnis einer leeren Batterie ist. Wenn wir Erkenntnisse haben. Was ActionDetector aber derzeit einzig aufgrund fehlender Meldungen des Devices - aus welchen Gründen auch immer - annimmt, ist ein "probably dead".

sorry, nur ganz kurz: Hier steige ich aus.
Es ist fast alles nur Probably. Es kann immer  auch einen anderen Grund geben. Was willst du sagen, was befürchtet du? Wenn hier "Dead" steht ist erst einmal nichts passiert. Der Anwender weiss, dass sich das Device nicht meldet. Er sollte einmal die batterie tauschen. Wenn das nichts hilft - tauscht er noch einmal und noch einmal... ? Wenn das Device am Display Bat-ok anzeigt, FHEM aber dead dann
1) hat das Device die notwendige Aufmerksamkeit
2) der Anwender die Aufgabe den fehler zu suchen
3) er könnte tagelag die Batterie tauschen und nicht merken, dass es nichts bringt weil das IO kapuut ist. Ich halte auch hart gesottene Anwender für intelligenter. Das passiert nicht.

Diese Details sähe ich lieber in batteryPercentage als in battery(State).

Percentage sind Prozent. Ich würden keinen String erlauben.
in der Developer-Ecke habe ich eher ein "alarmBattery" reading vorgeschlagen. Battery kann m.E. bleiben wie es ist.
Der Wilduchs an Battery-readings und Schreibweisen sollte begrenzt werden.

Sinnvolle Infos zur Gültigkeit abseits

ich bastle mal... Wird mit Sicherheit abschlatbar. Default abgeschaltet.

[martinp876]

Hi Pfriemler, gutes neues Jahr.
Das Attribut readingOnDead habe ich nun für Devices eingebaut.
Funktion/Idee: Wenn ein Device nach "dead" geht kann man Readings entsprechend ändern.
Der Anwender hat die Wahl:
- state nach Dead
- und/oder alle periodischen nummerischen Werte nach "0" (bspw werden dann temperaturen in den Grafiken beeinflusst, also genullt. Ausfall ist sichtbat
- und/oder periodiche string werte nach 'dead'
- und/oder setzen user definierter Readings auf "dead"
- Auch alle Kanäle des Device bearbeiten, gleichen Prinzip

Warum nur Devices? => Channels können nicht dead sein
warum keine weiteren Filter (user readings nach '0' ändern): Irgendwann ist schluss und man muss es mit einem Notify machen
warum keine Behandlung von unerrechbaren Devices (Diskussion bevor: letztes IO ist verstorben): Ungünstig. Evtl ist es nur ein temporärer Ausfall Readings sollten dann nicht verändert werden. Dead ist eine vereinbarte tot-Zeit. Wenn diese nicht eingehalten wird, wird entsprechend alarmiert.
Was ist mit Batterie: Kann man über die Periodischen Readings einbeziehen oder nicht.
Wie wird recovered? Die Strings werden auf "notDead" gesetzt. Es sollte nicht lange dauern, bis sie mit gültigen Werten Überschrieben werden.
Wenn ich keine Beeinflussung will? das Attribut nicht setzen oder auf noChange setzen.

Mir hilft es, falsche weil veraltete Statusanzeigen zu erkennen wenn das Device tot ist.

[Pfriemler]

Hallo Martin,
gleiche Wünsche auch für Dich!
Sehe es mir ab morgen interessiert an, da habe ich endlich mehr Zeit. Bin schon gespannt.

nur noch das:

Percentage sind Prozent. Ich würden keinen String erlauben.

Natürlich nicht, war auch nie so gemeint. Ich dächte eher, dass man (hypothetische) Meldungen eines Gerätes zum Batteriezustand wie "voll, halbvoll, niedrig, kritisch" in batteryState als "ok,ok,low,low_critical" mappen sollte und in batteryPercentage als "100,50,20,10" - etwa. 100 ist voll, 0 ist leer. Und bitte keine Kommastellen ...