[Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe
-
@Saschag sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
habe das Script vor paar Tagen auf 1.6.2 aktualisiert und seit dem wieder das Problem dass die HM Geräte alle „tot“ bleiben?!?!
Hm, seltsam, den damaligen Fehlerfix hab ich in der 1.6.2 ja integriert, kontrollier bitte mal ob die Geräte wirklich aktualisiert haben.
Hat’s du die Version 1.6.1 noch mal für mich vielleicht zum testeten?
Nein, ich heb nicht jede Zwischenversion auf.
-
Danke nochmal!
Habe jetzt mal die DP „beobachtet“ diese werden tatsächlich sehr selten (bin jetzt bei 14Tagen im Script) aktualisiert.
Naja da werde ich wohl leben müssen mit.Grüße
-
@Pittini
Vielen Dank für das tolle Skript. Ich bin auf der 1.6.4 und bei mir funktioniert die dead device Erkennug für HM Geräte ebenfalls nciht. Mal werden alle, mal nur einzelne Devices als dead erkannt. Ich bekomme mindestens alle 180min eine Meldung. -
@passuff sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
Vielen Dank für das tolle Skript. Ich bin auf der 1.6.4 und bei mir funktioniert die dead device Erkennug für HM Geräte ebenfalls nciht. Mal werden alle, mal nur einzelne Devices als dead erkannt. Ich bekomme mindestens alle 180min eine Meldung.
Bitte erst mal prüfen ob die Geräte tatsächlich aktualisieren und das Skript das falsch meldet. Wenn die erst sehr spät aktualisieren kann ja das Skript nix für, dann mußt halt die Zeit hochsetzen in den Einstellungen.
-
@Pittini die Geräte sind soweit in Ordnung.
Wenn ich das skript starte bekomme ich alle hm Geräte direkt als dead gelistet. Aktuell sind 180 Minuten konfiguriert. Nach einer gewissen Zeit heilt sich das system bis auf ein HM device. Es ist immer das erste in der Functions Liste. MiHome und shelly funktionieren augenscheinlich... -
@passuff sagte in [Vorlage] Generische Batteriestandsüberwachung + Vis-ausgabe:
die Geräte sind soweit in Ordnung.
Das will ich ja auch gar nicht anzweifeln, aber die können trotzdem evtl. sehr spät aktualisieren. Was passiert denn wenn Du die Zeit auf 360min hochsetzt?
Wenn ich das skript starte bekomme ich alle hm Geräte direkt als dead gelistet.
HM Geräte werden an sich vom Skript nicht anders behandelt als alle anderen auch. Wenn das Skript das so meldet, wirds so sein, vorallem wenn die anderen ja passen wie Du sagst. Wenn nicht, dann bitte Screenshot aus der Objektliste von so nem Gerät wo ich auch seh wann die letzte Aktualisierung war und ein komplettes Startlog mit eingeschaltetem Logging.
-
@Pittini
Nach näherer Betrachtung muss ich dir Recht geben. Die Batteriestati der HM Geräte (Lowbat false/true) werden nicht so oft aktualisiert wie die eigentlichen Sensorwerte (z.B. Verschluss geöffnet).
D.h. aber auch, die Dead Device Auswertung macht bei HM Geräten m.E. generell auf diese Weise keinen Sinn. Man müsste den Batteriestatus für den Low Bat Alarm und den Sensorwert für die Dead Device Auswertung heranziehen. 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)EDIT: Einfacher: kann ich die Batterieauswertung ausschalten und nur dead devices aktivieren? Dann würde ich einfach zwei Skripte laufen lassen, wenn sich die globalen Variablen nicht in die Quere kommen....
-
@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).
