Batterieüberwachung

[volschin]

Hallo zusammen,
zu dem Thema gibt es ja einen schönen Wiki-Artikel, den ich bei mir auch so umgesetzt habe.
Jetzt hatte ich meinen ersten Battery:low und das notify feuerte alle 5-10 Minuten eine Mail an mich. Nervig. 

Wie habt Ihr das bei Euch gelöst?

Danke und Gruß,
Veit

[Puschel74]

Hallo,

Battery:low und das notify feuerte alle 5-10 Minuten eine Mail an mich.

Das ist klar.
das Device meldet ja alle x Minuten das die Batterie am leer werden ist.

Wie habt Ihr das bei Euch gelöst?

Wenn battery low gemeldet wird wird ein dummy gesetzt und die Mail abgesendet.
Bei jeder weiteren Meldung wird geprüft ob der Dummy gesetzt ist.

Grüße

[justme1968]

oder man verwendet z.b. event-on-change reading.

gruss
  andre

[volschin]

Hallo zusammen,
danke für die Tipps. Event-on-change scheint mir die elegantere Variante, auch wenn ich es an jedem Batterie-Device setzen muss und beim Kaufen neuer Geräte dann auch dran denken muss das dort nachzuziehen.

Gruß,
veit

[volschin]

Hallo André,
War leider doch nicht problemlos. Nachdem ich in den Thermostaten das Event-on-change-Reading für battery eingetragen habe, wurden die Plots nicht mehr weitergeschrieben. Als ich den Eintrag heute Abend wieder gelöscht habe, funktioniert es wieder. Hast Du noch eine Idee dazu?

Gruß
Veit

[justme1968]

sobald event-on-change gesetzt ist werden nur noch events für die readings erzeugt für die es gesetzt ist. d.h. du musst es für alle readings setzen. bzw. event-on-update-reading wenn das besser für dich passt.

schau dir die erklärung in der command ref an.

gruss
  andre

[volschin]

Oh, das ist damit doch deutlich komplexer als ich beim ersten Lesen angenommen hatte. 
Ich werde dann jetzt doch schauen, dass ich mir dem Dummy mein Ziel erreiche.

Danke und Gruß
Veit

[justme1968]

eigentlich kommt nur ein 'event-on-update-reading .*' dazu.

oder eben gleich 'event-on-change-reading: .*'.

gruss
  andre

[volschin]

Danke, ich habe das jetzt mal nur für eine Heizungskette (TC+VD) umgestellt. Mal sehen, ob sie sich heute anders als der Rest verhalten.

Gruß,
Veit

[volschin]

Nochmal ein bisschen Logfileanalyse gemacht. Während ein VD das 'battery:' mit jedem Ereignis mitsendet, kommt es beim TC nur zusammen mit desired-temp bei einer Änderung dieser.

Das event-on-change für alles macht das Logfile ziemlich klein, z.B. entfallen die ganzen actuator: 0 % Meldungen. Mal abwarten, wie das dann im Plot aussieht. Ein kleineres Logfile wäre ja ein positiver Nebeneffekt. 

Gruß,
Veit

[justme1968]

die logs werden kleiner. aber du wirst unschöne effekte beim reinzoomen in einen plot bemerken. von daher ist es eigentlich nur für werte die nicht mit hoher auflösung geplottet werden sollen sinnvoll.

gruss
  andre

[volschin]

Bis jetzt sieht das mit den Logs gut aus, Einträge auf rund ein Fünftel reduziert. Ich habe den Plot für meinen Actuator von line auf steps umgestellt. Die Funktionalität ist voll da. Jetzt bräuchte ich nur noch eine Idee, die Endwerte zu den Plotenden zu extrapolieren. Positiver Effekt ist auch, dass der Plot auf meiner Fritzbox deutlich schneller erzeugt wird.

Gruß
Veit

[tpm88]

eigentlich kommt nur ein 'event-on-update-reading .*' dazu.

Das ist so nicht ganz richtig. Laut CommandRef hat event-on-update-reading nämlich Vorrang vor event-on-change-reading.

Siehe Punkt 3: "If a reading is listed in event-on-update-reading, an update of the reading creates an event no matter whether the reading is also listed in event-on-change-reading."

Somit wäre der Effekt von event-on-change-reading für battery wieder aufgehoben.

Ich habe es mit Hilfe von http://stackoverflow.com/questions/406230/regular-expression-to-match-string-not-containing-a-word so gelöst.
Setzen von event-on-change-reading für battery. Setzen von event-on-update-reading für ALLE andereren readings, die nicht den String battery im Namen haben.

Code Auswählen Erweitern


event-on-change-reading battery
event-on-update-reading ^((?!battery).)*$


Tobias