ich habe ein dummy device mit folgendem attributen:
attr dev event-on-change-reading state
attr dev event-min-interval state:3
ausserdem ein paar userreadings.
auf dem dummy habe ich ein filelog mit folgendem output:
2017-03-06_20:14:02 Arduino_Heizung_A4_temp 38
2017-03-06_20:14:07 Arduino_Heizung_A4_temp 38
2017-03-06_20:14:12 Arduino_Heizung_A4_temp 38
eigentlich dürften doch keine einträge mit gleichem wert hintereinander stehen. hat jemand eine idee woran das liegt?
ich möchte nur einträge im filelog haben, wenn sich der state ändert...
Und wie schaut es ohne event-min-interval aus?
danke, stimmt, es geht wenn ich event-min-interval weglasse.
nur dann kann ich dann nicht mehr kontrollieren, wie lange mindestens zwischen zwei events sein darf.
kann man irgendwie erreichen, dass nur änderungen zu events führen UND dass mindestens x sekunden zwischen den events sein müssen?
Mir faellt nur was mit expliziter Programmierung ein.
würde es sinn machen die precedence zu ändern, sodass wenn beide attribute gesetzt sind event-on-change priorität hat und nur änderungen events generieren mit dem minimalen intervall?
oder gibt es einen sinn die precedence für event-min-interval höher zu setzen?
Mir stellt sich die Frage, warum dich a) gleiche Werte stören, oder b) du nicht jede Änderung loggen möchtest. Wenn du den Hintergrund erklärst finden sich bielleicht andere Lösungen
hintergrund ist folgender: ich habe einen arduino mit firmata-ethernet protokoll am fhem rpi angebunden und verschiedenen sensoren an meiner heizung. ein sensor muss mit hoher sampling frequenz alle 3s werte liefern, da zeitkritische steuerung (zur steuerung der zirkulationspumpe). alle anderen sensoren reichen alle 5min ein wert, da nicht zeitkritische steuerung. man kann aber nur eine einheitliche sampling frequenz für alle eingänge am arduino bzw frm device konfigurieren.
damit die logs nicht riesig werden und der load am rpi nicht zu hoch wird, möchte ich mit größtmöglichem intervall loggen und verarbeiten. d.h. es sollen für alle sensoren nur alle 300s werte verarbeiten und loggen nur von dem einem sensor benötige ich alle 3s werte, zumindest wenn sich der wert ändert...
Zitatwürde es sinn machen die precedence zu ändern, sodass wenn beide attribute gesetzt sind event-on-change priorität hat und nur änderungen events generieren mit dem minimalen intervall?
nein. auf keinen fall. das aktuelle verhalten ist dokumentiert und wird genau so auch verwendet.
um hier etwas zu ändern müsste man neue attribute einführen. und das macht alles noch unübersichtlicher.
Zitatdamit die logs nicht riesig werden und der load am rpi nicht zu hoch wird, möchte ich mit größtmöglichem intervall loggen und verarbeiten. d.h. es sollen für alle sensoren nur alle 300s werte verarbeiten und loggen nur von dem einem sensor benötige ich alle 3s werte, zumindest wenn sich der wert ändert...
dann setz doch für alle sensoren event-min-interval auf einen grossen wert und für den einen sensor den du öfter brauchst event-on-change-reading so das dieser eine öfter ein event erzeugt.
es gibt keinen grund das alle sensoren oder readings gleich behandelt werden müssen.
Zitat von: justme1968 am 06 März 2017, 21:14:23
nein. auf keinen fall. das aktuelle verhalten ist dokumentiert und wird genau so auch verwendet.
nur ob man event-min-interval mit oder ohne event-on-change-reading verwendet ist ja das gleiche verhalten. es sollte also nur jemand aus unwissenheit beides gleichzeitg verwendet haben..
Zitat
dann setz doch für alle sensoren event-min-interval auf einen grossen wert und für den einen sensor den du öfter brauchst event-on-change-reading so das dieser eine öfter ein event erzeugt.
dann habe ich trotzdem alle 3s einen logeintrag auch wenn sich der wert nicht ändert, was über lange zeitstrecken (z.b. die ganze nacht für jede nacht sowie bei abwesenheit) der fall ist. das kostet nicht nur speicher, sondern verkürzt auch die lebensdauer der sd karte...
Zitatnein. auf keinen fall. das aktuelle verhalten ist dokumentiert und wird genau so auch verwendet.
im übrigen habe ich vom Lesen der doku ein anderes verhalten erwartet, wenn ich event-on-change-reading und event-min-interval kombiniere:
Zitatevent-on-change-raeding:...If set, only changes of the listed readings create events. In other words, if a reading listed here is updated with the new value identical to the old value, no event is created....
event-min-interval:...Events will only be generated, if at least minInterval seconds elapsed since the last reading of the matched type...
heisst für mich: nur events bei änderungen UND mind x sek abstand...
Zitatdann habe ich trotzdem alle 3s einen logeintrag auch wenn sich der wert nicht ändert
du kannst bei event-on-change-reading einen threshold angeben um den der wert sich mindestens ändern muss um ein event zu erzeugen.
Zitates sollte also nur jemand aus unwissenheit beides gleichzeitg verwendet haben.
nein. aus dem grund oben und weil man z.b. für event-min-interval eine allgemeine regex wie .* verwenden kann und für event-on-change-reading eine spezifischere.
Zitat von: justme1968 am 06 März 2017, 21:36:26
du kannst bei event-on-change-reading einen threshold angeben um den der wert sich mindestens ändern muss um ein event zu erzeugen.
ja, aber geht leider auch nicht bei mir, da die steuerung auch bei kleineren wertänderungen schon reagieren muss...
Zitatweil man z.b. für event-min-interval eine allgemeine regex wie .* verwenden kann und für event-on-change-reading eine spezifischere.
ja, aber man müsste ja nur das verhalten ändern für readings, die auf beides matchen. aber es gibt natürlich ein restrisiko, dass das jemand nichtwissend so verwendet..
ich weiss ja nicht wie genau dein messfühler ist, aber wenn er wirklich wie oben zu sehen über einen langen zeitraum exakt das gleiche liefert, sollte ein threshold von 0.0001 oder ähnlich funktionieren. eine regelung die so genau muss gibt es für keine heizung.
nein, er liefert nur ganzzahlige werte, die z.b. nachts max um 1 hoch oder runterschwanken. bei differenz ab 2 soll aber schon die pumpe anspringen. ich könnte die differenz für die pumpe natürlich höher einstellen, dann würde es aber länge dauern, bis ich warmes wasser kriege nach öffnung des wasserhahns und da zählt jede sekunde...
dann musst du doch nur den threshold auf 0.1 stellen und alles ist gut. gleiche werte erzeugen kein event und keinen log eintrag und eine änderung um 1 ist größer als 0.1 und erzeugt ein event und einen log eintrag.
oder auf 1.9. dann wird alles < 2 rausgefiltert.
hmm, stimmt, müsste gehen. teste ich mal, danke!
trotzdem nicht optimal, da die anderen zeitunkritischen sensoren unnötigerweise alle min-interval sekunden den gleichen wert schreiben...
Zitattrotzdem nicht optimal, da die anderen zeitunkritischen sensoren unnötigerweise alle min-interval sekunden den gleichen wert schreiben...
@FhemPiUser: Wenn du einen gut getesteten Patch dafuer lieferst, werde ich es anschauen.
Ich habe mal im Code geschaut und mit Änderungen getestet (fhem.pl:13560/2017-03-01).
Aus meiner Sicht ist der "Fehler" in der if-Anweisung ab Zeile 4272, da dort bei event-min-interval nur dann changed=0 gesetzt wird und damit kein event generiert wird, wenn der Value sich NICHT ändert (da ist changed aufgrund einer Abfrage weiter oben in Zeile 4259 ohnehin schon 0). changed sollte aber auch auf 0 gesetzt werden, wenn sich der Wert ändert, das Interval aber noch nicht abgelaufen ist.
Außerdem sollte nicht automatisch bei Ablauf von event-min-interval changed auf 1 gesetzt werden, also ein Event generiert werden, sondern nur, wenn es auch eine Änderung des Values gab (was aber schon weiter oben abgefragt wird und da dann ggf. changed schon auf 1 gesetzt wurde).
Daher muss
if($le && $now-$le < $minInt) {
if(!$eocr || ($eocr && $value eq $readings->{VAL})){
$changed = 0;
} else {
$hash->{".lastTime$reading"} = $now;
}
} else {
$hash->{".lastTime$reading"} = $now;
$changed = 1 if($eocrExists);
}
ersetzt werden durch
if($le && $now-$le < $minInt) {
$changed = 0;
} else {
$hash->{".lastTime$reading"} = $now;
}
Macht das Sinn für Euch? Bei meinen Tests hat es funktioniert...
Zitat von: FhemPiUser am 06 März 2017, 20:20:16
ich habe ein dummy device mit folgendem attributen:
attr dev event-on-change-reading state
attr dev event-min-interval state:3
ausserdem ein paar userreadings.
auf dem dummy habe ich ein filelog mit folgendem output:
2017-03-06_20:14:02 Arduino_Heizung_A4_temp 38
2017-03-06_20:14:07 Arduino_Heizung_A4_temp 38
2017-03-06_20:14:12 Arduino_Heizung_A4_temp 38
eigentlich dürften doch keine einträge mit gleichem wert hintereinander stehen. hat jemand eine idee woran das liegt?
Works as designed!
Zumindest sagt das so das Wiki https://wiki.fhem.de/wiki/Event-on-change-reading (https://wiki.fhem.de/wiki/Event-on-change-reading):
"In der Regel ist es sinnvoll, event-on-change-reading mit min-interval zu kombinieren, min-interval deshalb, damit von Zeit zu Zeit Einträge in das Logfile geschrieben werden (findet FHEM zu wenige Ereignisse pro betrachteter Zeitspanne, bleibt das Diagramm leer oder wird nur teilweise gezeichnet (Plotabriss))."
Und genau so verwende ich die beiden Attribute:
attr Heizungsvorlauf event-min-interval .*:600
attr Heizungsvorlauf event-on-change-reading temperature:0.6
Das loggt bei Änderungen um min. 0,6
oder alle 600 Sekunden.
das ist für mich von der logik aber ein event-max-interval anstatt ein event-min-interval, denn dann sind
events ja max 600s auseinander, aber es gibt auch kürzere intervalle...
passt für mich auch nicht zusammen mit der fhem referenz beschreibung (s.o)...
man könnte natürlich neben min-interval ein max-interval attr einführen...
@sfancy: danke fuer die Gedaechtnisstuetze, so war das auch gemeint: man will mitkriegen, wenn sich was aendert, und mindestens alle X Sekunden ein Lebenszeichen vom Geraet, wenn sich nichts aendert.
hi rudolf,
das passt für mich nicht mit der fhem referenz beschreibung zusammen
event-min-interval:...Events will only be generated, if at least minInterval seconds elapsed since the last reading of the matched type...
mein vorschlag: man führt noch ein max-interval attr ein...
Das Problem: die Stelle ist komplex. Es ist trivial fuer einen bestimmten (==deinen) Fall zu testen, aber es wird von vielen in kaum vorstellbaren Kombinationen verwendet, die sofort auf meinem Dach steigen, wenn das nicht mehr so funktioniert, wie bisher. Du kannst gerne einen Patch bauen, ich werde es aber nur dann aufnehmen, wenn ich Nebeneffekte auf Anhieb(!) ausschliessen kann. Ich habe mit csrfToken genug Kopfschmerzen, eine neue Baustelle fehlt mir nicht. Und bei csrfToken habe ich wenigstens eine valide Begruendung fuer die Kopfschmerzen.
@FhemPiUser: achtung: max-intervall unterliegt einem denkfehler. fhem erzeugt keine events. nur der sensor tut das. wenn der sensor nichts sendet nützt auch ein max-interval nichts.
der name min-interval ist schon korrekt. es wird kein event erzeugt wenn das interval kleiner als min-interval ist. ein event wird also dann erzeugt wenn mindestens x sekunden vergangen sind.
@rudolfkoenig: ja, kann ich absolut nachvollziehen.
ich werde dann auch keine energie mehr in das thema stecken. auch wenn es nicht optimal ist kann ich auch mit der aktuellen variante leben.
ich würde allerdings empfehlen die fhem referenzbeschreibung nochmal anzupassen, die ist zumindest für mich nicht so, dass ich auf das tatsächliche verhalten kommen würde.
Zitatich würde allerdings empfehlen die fhem referenzbeschreibung nochmal anzupassen
Habe die Doku angepasst.
ok, danke.
habe jetzt das von mir gewünschte verhalten erreicht, indem ich ein notify und ein dummy zusätzlich zum eigentlichen device definiert habe, der dummy mit event-min-interval und das eigentliche device mit event-on-change-reading.