Standardisierte Battery Readings in 10_CUL_HM?

[martinp876]

Mittlerweile wäre mein Favorit
*Kategorie Alarme
> sind primär für ein SystemInfo-modul gedacht
> sollten eigentlich gebündelt für ein Modul (also alle Devices von CULHM bspw) kommen
> könnten aussehen wie in HMInfo: ok:10,warning:2,error:0,critical:2
- alarmBattery wäre die Meldung aller Batterie Devices aus CUL_HM . Andere Module sollten es auch destilieren
- alarmMotor könnte ein weiterer Alarm sein - für Motoren der RTs bspw
- alarmProtokol auch ein Kandidat
=> BatteryLow wäre eine Warning

Das Modul Info sollt dann die Liste der nicht-ok-devices in Internals darstellen. Hier kann man dann in das Device verzweigen (click geht in Readings nicht)

Im Modul kann man dann weitere readings ansehen. Im Reading "battery" kann man dann etwas freizügiger sein, was die Werte betrofft. Auch eine Erweiterung ist nicht mehr so kritisch.

[Deudi]

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.

Dazu eine Anmerkung: Normalerweise bekomme ich von den HM-Sec-RHS ein battery low bevor die sich verabschieden. Wenn es draussen sehr kalt ist, ist es jetzt schon mehrfach vorgekommen, dass das Lüften bei -10°C den RHS den letzten Sargnagel verpasst hat ohne vorher ein battery low zu bekommen. Die waren dann komplett tot und mit frischen Batterien war alles wieder ok.

[martinp876]

Jetzt muss ich noch einmal

Normalerweise bekomme ich von den HM-Sec-RHS ein battery low bevor die sich verabschieden

ich verstehe die bedenken nicht. Ich bin mal ausser Haus. Meine Frau achtet nicht wirklich auf die Batterien "low". Eine Batterie kann versterben, ebenso wie die Elektronik.
Low kann Jahrelang anstehen (wenn man die Nerven hat). Mein HM-PBI-4-FM ist so ein Beispiel. Mittlerweise 4 Jahre - funktioniert prima.
Ja, device klauen oder sterben ist eher selten (gut so)
Ja, bat low kommt typisch vor (bat)dead.
wenn man immer gleich reagiert ( so an zu Hause ist,...) ist das alles nett.

Dead ist schlicht eine Ultimative überwachung. Wenn Device Dead gemeldet wird kann man keine Aussage über die Batterie machen. Es ist zumindest "unknown" - wie alle regelmäßigen Messwerte.
Genau genommen sollten alle Werte ausgeblendet werden, wenn dead.

Bei mir (schlechte Wartung) quittiert die Batterie eines Tempsensors gerne den Betrieb. Der gepeerte RT läuft selbständig weiter. Die Graphen werden weiter geschrieben.  Aus meiner Sicht unschön.

[Pfriemler]

Zwischenruf: Meinem Energiemesszwischenstecker habe ich jetzt mal testweise ein "readingOnDead = state,channels" verpasst. "dead" erscheint als Status, wenn ich das Ding nicht benutze. Gut!

Eins weitergedacht: wenn jetzt von einem Gerät der Status "dead" bekannt ist - nimmt autoReadReg darauf Rücksicht? Es hat ja keinen Sinn, Daten von einem Gerät anzufordern, welches offenbar nicht mehr arbeitet ...

[martinp876]

nein, autoReadReg nimmt keine Rücksicht.
Ist die Frage, ob es der Aufwand wert ist.
a) well alle Daten vorhanden sind wird sowieso nichts gemacht
b) wenn Register fehlen sollten wird einmal probiert. Es schlägt fehl (nur eine  message) - dann wird in 30min wieder probiert. Aufwand gering - und es ist ein Versuch kontakt aufzunehmen
c) wenn der Status unklar ist (eher unwahrscheinlich) ist es wie bei Registern.

Wichtiger würde ich es sehen, wenn das Device nach dead zurück kommt. In einem professionellen System müsste das Device erst einmal frisch eingelesen werden. Dazu ist aber das Protokoll dann doch nicht performat genug.

[Pfriemler]

war etwas zu kurz gedacht von mir ...
Problem: HM-Zwischenstecker wird nur temporär benutzt. autoReadReg vesucht den Status zu ermitteln, alle 30 Minuten, wochenlang. 48 überflüssige Logzeilen pro Tag. Es sollte doch von allein aufgeben ...
Lösung: ist schon vorhanden. 2_ponRestart muss man nur setzen... 
in solchen Fällen kommt das Gerät ja nicht einfach zurück, sondern sendet eine powerOn-Message. Anders sähe das bei batteriebetriebenen Geräten aus, die man auch mobil nutzt und somit temporär entfernt. Da ist mir aber kein Anwendungsfall denkbar.

[Damu]

Normalerweise bekomme ich von den HM-Sec-RHS ein battery low bevor die sich verabschieden

Die Dinger verabschieden sich bei mir immer ohne low.