[Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe
-
@passuff sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
Wäre es möglich für die Dead Device Auswertung eine zusätzliche Function im Skript zu definieren? Das würde zum einen das Problem mit HM Geräten beheben und zum anderen könnte ich so auch unabhängig von der Batteriespannung andere Geräte überwachen (anstelle oder zusätzlich zum Ping Adapter)
Möglich is immer alles, die Frage ist meist obs Sinn macht. In diesem Fall find ich das ne gute Idee und schöne Erweiterung für das Skript. Das is aber auch nix was man "mal schnell so" einbaut. Fazit: Wird kommen kann aber bisserl dauern.
-
@Pittini : Mit dieser Aussage kann ich super leben. Danke noch mal für das tolle Skript. Kostet sicherlich viel Zeit und die ist rar!
-
@Pittini ich habe gerade noch mal einige Devices überprüft. HM ist da wohl sehr eigen. Die Variablen werden oft nur bei einer Änderung aktualisiert. Eine Regelmäßigkeit scheint es zumindest nicht wirklich zu geben, daher macht eine Auswertung der HM Zeitstempel in meinen Augen keinen Sinn. Da HM aber einen "unreach" Status schickt, könnte man auch diesen auswerten.
-
@Pittini Auch Mihome Devices sind nicht so einfach als dead devices zu erkennen. Der Zeitstempel hilft hier alleine nicht weiter, da dieser auch aktualisiert wird, wenn die devices schon nicht mehr reagieren. Das Gateway sendet immer wieder den zuletzt bekannten Wert. Die Spannung kann man allerdings super überwachen.
-
Moin @Pittini !
Ich habe gerade mal dein Script eingebaut, laufen lassen und wundere mich ein bisschen darüber, dass alle meine Comet-SECT Geräte angeblich tot sind.
Bei näherer betrachtung habe ich folgendes herausgefunden:
Der State als solcher ist zwar korrekt als type Number angegeben:
Das Scrpit interpretiert die aber als String:
javascript.0 2020-08-14 18:04:11.146 info (32078) script.js.common.Batterien_überwachen: 1 BatterieSpannung_30 found at fritzdect.0.Comet_119610695248.battery Umax= 3 BattMinLimit=2.4 Val= 0 SensorProzent= 0 javascript.0 2020-08-14 18:04:11.146 info (32078) script.js.common.Batterien_überwachen: Tempval=40 TempUnit=% TypeOf=string javascript.0 2020-08-14 18:04:11.146 info (32078) script.js.common.Batterien_überwachen: 0 BatterieSpannung_30 found at fritzdect.0.Comet_119610679280.battery Umax= 3 BattMinLimit=2.4 Val= 0 SensorProzent= 0 javascript.0 2020-08-14 18:04:11.145 info (32078) script.js.common.Batterien_überwachen: Tempval=100 TempUnit=% TypeOf=string javascript.0 2020-08-14 18:04:11.145 info (32078) script.js.common.Batterien_überwachen: BattMinLimit Value conversion - success javascript.0 2020-08-14 18:04:11.144 info (32078) script.js.common.Batterien_überwachen: Reaching init() javascript.0 2020-08-14 18:04:11.144 info (32078) script.js.common.Batterien_überwachen: Reaching main()
Ich könnte jetzt natürlich im Script rumfummeln um die Comet-Dinger zu erkennen, aber das will ich eigentlich nicht (wegen Updates und so). Außerdem wäre es nach meinem dafürhalten nur ein Workaround.
Hast Du eine Idee was der eigentliche root-cause dabei ist?
Danke im Voraus und
viele Grüße
Grizzelbee -
@Grizzelbee sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
Hast Du eine Idee was der eigentliche root-cause dabei ist?
Bevor ich mir da nen Kopp drum mach, folgende Frage: Hast Du schon kontrolliert wieoft die Comet Dinger tatsächlich aktualisieren. Bisher lags bei Dauertotmeldungen immer daran dass das Gerät einfach nicht häufig genug aktualisiert hat (Das Skript geht da nachm Zeitstempel). Wenn Du feststellst dass die innerhalb der eingestellten Zeit aktualisieren, das Skript aber trotzdem anderes behauptet, dann meldest Dich nochmal. Die Typeof Meldung kannste erstmal ignorieren denk ich, außer es kommen iwo echte Fehlermeldungen.
-
@Pittini
Ich fürchte das ich die typeOf Geschichte leider nicht ignorieren kann...
Meines Wissens nach aktualisieren die Cometen alle 15 Minuten. die Dead-Zeit habe ich wegen der ebenfalls abgefragten Shelly Door/Window auf 36 Stunden eingestellt.
Das Problem ist ja, dass das Script den Prozentwert der Cometen gar nicht versucht zu parsen, weil es eben type String und nicht Number ist. Dadurch stehen die alle auf 0%, was wie man in dem Logausschnitt sehen kann falsch ist.
Fakt ist, dass String offensichtlich falsch ist, die Frage ist nur, wie das Script auf String kommt, wo der Datenpunkt doch allem Anschein nach eine Number ist.
javascript.0 2020-08-14 18:04:11.151 info (32078) script.js.common.Batterien_überwachen: BattMinLimit Value conversion - success javascript.0 2020-08-14 18:04:11.150 info (32078) script.js.common.Batterien_überwachen: 13 BatterieSpannung_30 found at tradfri.0.MS-65540.batteryPercentage Umax= 3 BattMinLimit=2.4 Val= 1.7999999999999998 SensorProzent= 60 javascript.0 2020-08-14 18:04:11.150 info (32078) script.js.common.Batterien_überwachen: Tempval=60 TempUnit=% TypeOf=number javascript.0 2020-08-14 18:04:11.150 info (32078) script.js.common.Batterien_überwachen: 12 BatterieSpannung_30 found at tradfri.0.MS-65538.batteryPercentage Umax= 3 BattMinLimit=2.4 Val= 2.61 SensorProzent= 87 javascript.0 2020-08-14 18:04:11.150 info (32078) script.js.common.Batterien_überwachen: Tempval=87 TempUnit=% TypeOf=number javascript.0 2020-08-14 18:04:11.150 info (32078) script.js.common.Batterien_überwachen: 11 BatterieSpannung_30 found at fritzdect.0.Comet_119610718280.battery Umax= 3 BattMinLimit=2.4 Val= 0 SensorProzent= 0 javascript.0 2020-08-14 18:04:11.150 info (32078) script.js.common.Batterien_überwachen: Tempval=80 TempUnit=% TypeOf=string javascript.0 2020-08-14 18:04:11.150 info (32078) script.js.common.Batterien_überwachen: 10 BatterieSpannung_30 found at fritzdect.0.Comet_119610717960.battery Umax= 3 BattMinLimit=2.4 Val= 0 SensorProzent= 0 javascript.0 2020-08-14 18:04:11.149 info (32078) script.js.common.Batterien_überwachen: Tempval=80 TempUnit=% TypeOf=string javascript.0 2020-08-14 18:04:11.149 info (32078) script.js.common.Batterien_überwachen: 9 BatterieSpannung_30 found at fritzdect.0.Comet_119610717848.battery Umax= 3 BattMinLimit=2.4 Val= 0 SensorProzent= 0 javascript.0 2020-08-14 18:04:11.149 info (32078) script.js.common.Batterien_überwachen: Tempval=30 TempUnit=% TypeOf=string javascript.0 2020-08-14 18:04:11.149 info (32078) script.js.common.Batterien_überwachen: 8 BatterieSpannung_30 found at fritzdect.0.Comet_119610711024.battery Umax= 3 BattMinLimit=2.4 Val= 0 SensorProzent= 0 javascript.0 2020-08-14 18:04:11.149 info (32078) script.js.common.Batterien_überwachen: Tempval=100 TempUnit=% TypeOf=string javascript.0 2020-08-14 18:04:11.148 info (32078) script.js.common.Batterien_überwachen: 7 BatterieSpannung_30 found at fritzdect.0.Comet_119610710968.battery Umax= 3 BattMinLimit=2.4 Val= 0 SensorProzent= 0 javascript.0 2020-08-14 18:04:11.148 info (32078) script.js.common.Batterien_überwachen: Tempval=50 TempUnit=% TypeOf=string javascript.0 2020-08-14 18:04:11.148 info (32078) script.js.common.Batterien_überwachen: 6 BatterieSpannung_30 found at fritzdect.0.Comet_119610710720.battery Umax= 3 BattMinLimit=2.4 Val= 0 SensorProzent= 0 javascript.0 2020-08-14 18:04:11.148 info (32078) script.js.common.Batterien_überwachen: Tempval=50 TempUnit=% TypeOf=string javascript.0 2020-08-14 18:04:11.148 info (32078) script.js.common.Batterien_überwachen: 5 BatterieSpannung_30 found at fritzdect.0.Comet_119610710624.battery Umax= 3 BattMinLimit=2.4 Val= 0 SensorProzent= 0 javascript.0 2020-08-14 18:04:11.147 info (32078) script.js.common.Batterien_überwachen: Tempval=50 TempUnit=% TypeOf=string javascript.0 2020-08-14 18:04:11.147 info (32078) script.js.common.Batterien_überwachen: 4 BatterieSpannung_30 found at fritzdect.0.Comet_119610710432.battery Umax= 3 BattMinLimit=2.4 Val= 0 SensorProzent= 0 javascript.0 2020-08-14 18:04:11.147 info (32078) script.js.common.Batterien_überwachen: Tempval=60 TempUnit=% TypeOf=string javascript.0 2020-08-14 18:04:11.147 info (32078) script.js.common.Batterien_überwachen: 3 BatterieSpannung_30 found at fritzdect.0.Comet_119610710296.battery Umax= 3 BattMinLimit=2.4 Val= 0 SensorProzent= 0 javascript.0 2020-08-14 18:04:11.147 info (32078) script.js.common.Batterien_überwachen: Tempval=50 TempUnit=% TypeOf=string javascript.0 2020-08-14 18:04:11.146 info (32078) script.js.common.Batterien_überwachen: 2 BatterieSpannung_30 found at fritzdect.0.Comet_119610695752.battery Umax= 3 BattMinLimit=2.4 Val= 0 SensorProzent= 0 javascript.0 2020-08-14 18:04:11.146 info (32078) script.js.common.Batterien_überwachen: Tempval=50 TempUnit=% TypeOf=string javascript.0 2020-08-14 18:04:11.146 info (32078) script.js.common.Batterien_überwachen: 1 BatterieSpannung_30 found at fritzdect.0.Comet_119610695248.battery Umax= 3 BattMinLimit=2.4 Val= 0 SensorProzent= 0 javascript.0 2020-08-14 18:04:11.146 info (32078) script.js.common.Batterien_überwachen: Tempval=40 TempUnit=% TypeOf=string javascript.0 2020-08-14 18:04:11.146 info (32078) script.js.common.Batterien_überwachen: 0 BatterieSpannung_30 found at fritzdect.0.Comet_119610679280.battery Umax= 3 BattMinLimit=2.4 Val= 0 SensorProzent= 0 javascript.0 2020-08-14 18:04:11.145 info (32078) script.js.common.Batterien_überwachen: Tempval=100 TempUnit=% TypeOf=string javascript.0 2020-08-14 18:04:11.145 info (32078) script.js.common.Batterien_überwachen: BattMinLimit Value conversion - success javascript.0 2020-08-14 18:04:11.144 info (32078) script.js.common.Batterien_überwachen: Reaching init()Hmmm. Ich sehe gerade: Nuki ist irgendwie auch komisch:
javascript.0 2020-08-14 18:04:11.153 info (32078) script.js.common.Batterien_überwachen: 19 BatterieSpannung_60 found at nuki-extended.0.smartlocks.haustür.state.batteryCritical Umax= 6 BattMinLimit=4.8 Val= 6 SensorProzent= 100 javascript.0 2020-08-14 18:04:11.152 info (32078) script.js.common.Batterien_überwachen: Tempval=false TempUnit=undefined TypeOf=booleanLowBat ist false, wird aber dennoch als tot gekennzeichent.
-
@Grizzelbee sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
LowBat ist false, wird aber dennoch als tot gekennzeichent.
Das eine hat erstmal nix mitm anderen zu tun. Da es Geräte gibt bei denen wenn tot immer noch die letzten Werte stehenbleiben geht das Skript ausschließlich nach Aktualisierung, unabhängig wie Spannung oder % aussehen.
Zu dem Stringproblem, ich hab versucht das hier zu reproduzieren, vergeblich. Deswegen mach doch bitte mal folgenden einfachen Test. Leg ein neues Skript an, mit folgendem Inhalt:
log(typeof getState("fritzdect.0.Comet_119610711024.battery").val)Führ das Skript aus, und sag mir bitte was es ausspuckt.
Edit:
Ich könnte jetzt natürlich im Script rumfummeln um die Comet-Dinger zu erkennen, aber das will ich eigentlich nicht (wegen Updates und so).
Sollte es tatsächlich ein Skriptproblem sein (woran ich grad iwie nicht glaube) und Du ne Lösung dazu finden, kannste ja jederzeit das auf Git forken, verbessern und dann nen PR machen.
-
@Pittini sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
Führ das Skript aus, und sag mir bitte was es ausspuckt.
Da kommt (bei der im Stable befindlichen Version 0.2.4), nicht ganz unerwartet String bei raus.
Ich habe bei der Suche nach der Lösung allerdings gesehen, dass es deutlich neuere Versionen (V1.0.1) des Adapters auf Github gibt. Nach der Installation der aktuellen Version von github wird es korrekt zu Number und dein Script funktioniert wieder.Es lag also wie unterschwellig befürchtet am Adapter selbst.
Vielen Dank für deinen Support und das tolle Script!
viele Grüße
GrizzelbeeP.S.: Eine Frage dennoch: Mindestens der Tradfri und der Nuki-extended Adapter geben zwar regelmäßig Lebenszeichen von sich - Geschwister-Datenpunkte auf der selben Ebene werden aktualisiert, der Batterie-State aber wirklich nur, wenn er sich auch ändert - was selten der Fall ist. Dadurch scheitert die Tot-Erkenung in der Regel.
Siehst Du eine elegante Möglichkeit in diesen Fällen (als tot erkannt) den Timestamp sämlicher Geschwister zusätzlich zu testen ob da noch Lebenszeichen bei sind und nur tot zu melden, wenn auch sämliche Geschwister tot sind? -
@Grizzelbee sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
Siehst Du eine elegante Möglichkeit in diesen Fällen (als tot erkannt) den Timestamp sämlicher Geschwister zusätzlich zu testen ob da noch Lebenszeichen bei sind und nur tot zu melden, wenn auch sämliche Geschwister tot sind?
Machbar aber schwierig und erzeugt dann massive Systemlast fürchte ich. Müßte dann ja minütlich ALLE Datenpunkte aller Batteriegeräte auf Aktualisierung abfragen. Hab da grad eigentlich keine gute Idee zu, von elegant mal gar nicht zu reden.
-
@Pittini
Hmm. So schlimm dürfte das nur im worst case werden. Die Prüfung kann ja beim ersten Erfolg abgebrochen werden - im Idealfall direkt nach Prüfung des ersten Geschwisterchens.
Oder ist vielleicht ein BatterieSpannung_DeadTsHelper eine Option? Der müsste dann halt vom Anwender passend gesetzt werden. -
@Pittini
Hi, auch von mir erst mal ein großes Lob an dich und deine Scripte. Ich kann das Problem von Passuff mit HM-Devices bestätigen. Ursache soweit mir bekannt:
Die LOWBAT Anzeige (Channel 1) wird nur aktualisiert wenn sich der Status ändert. Im Channel 0 sogar erst bei einer Änderung des LowBat Status.
Da somit alle Devices bei Nichtbetätigung nach der eingestellten Zeit auf Dead gehen wäre ich auch sehr an einer Erweiterung mit "Unreacheble" interessiert -
@Mike-Hellracer @passuff Ich kann das Problem hier zwar leider nicht reproduzieren (weder bei meinen HM Thermostaten, noch bei meinen ca. 50 Xiaomi Devices an Gateways) aber glaub Euch das natürlich. Hier ne separate Funktion zu nehmen dürfte tatsächlich der sinnvollste Ansatz sein. Das würde aber auch bedeuten dass grundsätzlich zwei Funktionen pro Gerät gesetzt werden müssen was mir nicht wirklich gut gefällt. Mache ich nen separates Skript draus, isses wieder nimmer in einer Tabelle erfasst. Bin offen für Eure Meinung und grundsätzlich bereit das umzusetzen (sobald ich mein aktuelles Projekt LightControl einigermaßen fertig hab).
-
@Pittini
Wahrscheinlich läuft es auf die Zuweisung einer zweiten Funktion heraus.
Aber man könnte vlt darauf prüfen und wenn die zweite Funktion nicht gesetzt ist die "herkömmliche" Methode nlverwenden.
Und eine zweite Bitte hätte ich. In deinen Scripts verwendest du getEnum('functions')
Könntest du den Typ durch eine Variable ersetzen? zB. GetEnum(enumCazegory)
Dann wären hier auch eigene Kategorien verwendbar.. -
@Pittini Hi,
habe Probleme mit zwei Sensoren die nur „dead“ Anzeigen (Rauchmelder und Bewegungsmelder). Die Sensoren arbeiten einwandfrei, die Batterien sind auch voll, jedoch wird das Objekt „lowbat“ nicht aktualisiert.
Gleiches Problem hatte ich bei den Homematic Fensterkontakten auch. Da habe ich aber dann auf das Objekt „lowbat“ aus dem Verzeichnis 1 gewechselt dann ging es. Warum gibt es das Objekt lowbat in Unterverzeichnis „0“ und „1“ der Sensoren?
Leider kann hat der Rauchmelder und Bewegungsmelder das Objekt „lowbat“ nur im Verzeichnis „0“.
Also irgendeine Idee warum der Wert nicht aktualisiert wird?
Gruß
gogo -
@gogohome sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
Also irgendeine Idee warum der Wert nicht aktualisiert wird?
Da bin ich der falsche Ansprechpartner, da sollteste den Entwickler des jeweiligen Adapters fragen, mein Skript reagiert nur auf das was da ist. Da es diese Probs aber offenbar mit etlichen Geräten gibt, werd ich da im nächsten update das Handling anders handhaben, aber wird nochn bisserl dauern.
-
@Pittini OK verstehe, Danke für die schnelle Antwort.
-
@Pittini
Hi, gibt es schon Pläne für das Auslagern von "dead" in eine eigene Funktion? z.B. Prüfung von DP "UNREACHABLE" bzw. Gruppe
brauchst du dafür noch weitere Infos oder Unterstützung? -
@Mike-Hellracer sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
@Pittini
Hi, gibt es schon Pläne für das Auslagern von "dead" in eine eigene Funktion? z.B. Prüfung von DP "UNREACHABLE" bzw. Gruppe
brauchst du dafür noch weitere Infos oder Unterstützung?Wird kommen. Aber wird dauern, da ich grad zum einen eh rel. wenig Zeit hab und zum anderen das neue Skript "LightControl" erstmal Vorrang hat.
-
@Pittini
Hi, danke für die schnelle Antwort.
Ich möchte nicht kritisieren, aber wenn ich dich richtig verstehe ist "light control" das gleiche was der Adapter "Smart Control" übernimmt?
Oder ist das ein Missverständnis von meiner Seite?
