Hallo,
ich habe diverse Funk-Temperatur-Feuchtesensoren, die jede Minute einen Messwert liefern, wobei sich meistens natürlich nicht jede Minute die Messwerte in einem Raum ändern. Nun würde ich gerne nicht alle minütlichen Messwerte im FileLog erfassen, damit das nicht zu umfangreich wird.
Dafür gibt es ja bereits das "event-on-change-reading" Attribut, bei dem man nach einem Doppelpunkt auch einen Threshold setzen kann. Allerdings habe ich damit das Problem, dass sich teilweise die Messwerte auch über Stunden nicht ändern, was in Plots zu unschönen Lücken führt.
Aus meiner Sicht wäre es daher ideal, wenn man bei "event-on-change-reading" vorgeben könnte, dass wenn das letzte Event x Sekunden her ist, trotzdem ein Event erzeugt wird, auch wenn sich nichts geändert hat. So weit ich das sehe, lässt sich das aktuell nur mit entsprechenden Attributen nicht lösen.
Natürlich könnte man das auch über einen dummy und ein notify mit eigenem Code lösen, allerdings halte ich diese Funktion für so naheliegend, dass es schön wäre, wenn sie standardmäßig in FHEM integriert wäre.
Ich habe mir daher mal den Code in der fhem.pl angeschaut und einen entsprechenden Patch (siehe Anhang, auf Basis von FHEM 5.7) erstellt, der genau diese Funktion nachrüstet, indem man die gewünschte Sekundenzahl als dritten Parameter hinter einem Doppelpunkt bei "event-on-change-reading" angeben kann. D.h. ein "event-on-change-reading" Attribut von
temperature:0.1:300
bedeutet, dass neue temperature Events erzeugt werden, wenn sich die Temperatur um mindestens 0.1 verändert hat oder das letzte Event mehr als 300 Sekunden her ist. Ein ausgelassener Threshold "temperature::300" wird als 0 interpretiert.
Viele Grüße
Dominik
Schau dir mal logProxy an:
http://fhem.de/commandref.html#logProxy (http://fhem.de/commandref.html#logProxy)
http://www.fhemwiki.de/wiki/LogProxy (http://www.fhemwiki.de/wiki/LogProxy)
Außerdem gibt es noch die Möglichkeit mit addLog einen Plotabriss zu vermeiden:
http://www.fhemwiki.de/wiki/Plot-Abriss_vermeiden (http://www.fhemwiki.de/wiki/Plot-Abriss_vermeiden)
Was ist mit event-min-interval?
Und wenn man das wirklich in die fhem.pl bauen will, wäre ich eher dafür, dafür ein Attribut "event-max-interval" oder ähnlich einzuführen, um die Logik, die man mit "event-min-interval" eingeführt hat, einfach umzukehren.
Von immer mehr Parametern hinter unzähligen Doppelpunkten halte ich gar nichts.
Ich denke, dass es auf jeden Fall ein Feature ist, das fehlt. Wie man das am besten umsetzt, darüber kann man sicherlich diskutieren, wobei ich mich für diese Variante entschieden habe, weil sie mit den geringsten Code-Änderungen umzusetzen war.
Es geht mir nicht nur um Plots. Ich will z.B. anhand des FileLogs auch nachvollziehen können, ob ein Sensor ausgefallen ist bzw. es Probleme mit dem Funk gibt, und da sind Lücken von mehreren Stunden aufgrund von "event-on-change-reading" ungünstig.
Zitat von: betateilchen am 07 Februar 2016, 16:54:42
Und wenn man das wirklich in die fhem.pl bauen will, wäre ich eher dafür, dafür ein Attribut "event-max-interval" oder ähnlich einzuführen, um die Logik, die man mit "event-min-interval" eingeführt hat, einfach umzukehren.
Von immer mehr Parametern hinter unzähligen Doppelpunkten halte ich gar nichts.
Dafür.
Bin auch Dafür - ist für mich auch die bessere Lösung
kann es sein das hier verschiedene anwendungen vermischt werden?
events nur senden wenn sich der wert (um einen mindestwert) geändert hat aber mindestens alle x ninuten. das geht mit den bestehenden attributen.
device ausfall überwachen. das geht mit dem ActionDetector (sehr eng mit hm integriert. besser als nur auf event ebene) oder mit dem DeviceMonitor. letzeren könnte man mal etwas aktualisieren, aufbohren und aus contrib heraus holen.
absichtlich events erzeugen wenn das devie eigentlich gar keine erzeugt geht mit AddLog oder der gleiche effekt ohne zusätzliche events mit logProxy.
ein event-max-intervall wäre nur ersatz für AddLog und die implementierung nicht ganz trivial wenn es bei allen die das feature nicht nutzen keinen overhead erzeugen soll.
gruss
andre
Hallo Andre,
Zitatevents nur senden wenn sich der wert (um einen mindestwert) geändert hat aber mindestens alle x ninuten. das geht mit den bestehenden attributen.
genau das funktioniert bei mir nicht. Ich habe ein event-on-change und ein event-min-intervall mit 3600. Nach der Doku sind das Sekunden - somit sollte zumindest jede Stunde ein Wert geschrieben werden. Kann man da noch bestimmte Logewerte einstellen ? Ich logge 3 Werte, von denen einer regelmäßig kommt, für die anderen Beiden hätte ich gerne diese min-intervall. Geht das ?
Gruß Christoph
jede stunde so fern der sensor auch etwas sendet. wenn der sensor nur alle 2 stunden sendet wird auch nur alle 2 stunden ein event erzeugt. fhem 'erfindet' keine daten.
wie oft wird denn geloggt wenn du das event-min-intervall weg lässt?
gruss
andre
Hallo,
also das sind Werte, die aus dem Modul SYSMON kommen. Hier werden Temperatur, Power und Frequenz mitgeloggt. Das "Problem" ist, das jedes einen eigenständigen Eintrag in die Logdatei schreibt. Am häuftigsten sind die "Power" Einträge. Die kommen alle 2-5 minuten. Temperatur kommt ca. alle 15 min und Frequenz kommt 4-5 mal am Tag.
Das event-min-intervall greift nicht richtig, weil ja regelmäßig Power einträge da sind. Dershalb war ja die Frage, ob man da genauso wie bei event-on-change readings angeben kann.
Gruß Christoph
ich verstehe nicht ganz warum das ein 'problem' ist.
du kannst bei event-min-interval für jedes reading einen eigenen timeout angeben.
gruss
andre
stimmt, manchmal lohnt es sich doch, in die commandref und nicht nur ins wiki zu sehen.
Gruß Christoph
Hallo,
ich muss meinen Vorschlag zurücknehmen, denn wie ich jetzt festgestellt habe, ist es bereits so in FHEM integriert. Um noch einmal klarzustellen:
event-on-change-reading => Bedingung, dass ein Event nicht blockiert wird: Reading-Wert hat sich verändert
event-min-interval => Bedingung, dass ein Event nicht blockiert wird: letztes Event ist entsprechend lange her
Da in der commandref nichts von einer Wechselwirkung zwischen beiden Attributen steht, bin ich davon ausgegangen, dass wenn man beide Attribute setzt, beide Bedinungen mit UND verknüpft werden. Tatsächlich ist es aber so, dass beide Bedingungen mit ODER verknüpft werden, was genau das ist, was ich haben möchte.
Ich dachte eigentlich, dass ich das getestet hätte, aber anscheinend hatte ich es doch nicht getan oder mich dabei bei einem Attribut vertippt. Als ich mir jetzt noch einmal den Code zur Behandlung von "event-min-interval" genau angeschaut habe, ist es mir aufgefallen.
Im Umkehrschluss bedeutet dies jedoch, dass sich aktuell der UND-Fall nicht durch Attribute abbilden lässt, allerdings sollte das nicht allzu praxisrelevant sein.
Allerdings denke ich, sollte man in der commandref bei "event-on-change-reading" noch eine entsprechende Ergänzung machen, z.B.:
"If additionally the attribute event-min-interval is set for the same reading and this time has already elapsed since the last event, a new event is not blocked even if the reading's value is the same."
Viele Grüße
Dominik