[gelöst] event-on-change-reading geht nicht

[FhemPiUser]

ich habe ein dummy device mit folgendem attributen:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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...

[rudolfkoenig]

Und wie schaut es ohne event-min-interval aus?

[FhemPiUser]

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?

[rudolfkoenig]

Mir faellt nur was mit expliziter Programmierung ein.

[FhemPiUser]

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?

[KernSani]

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

[FhemPiUser]

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...

[justme1968]

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?

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.

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...

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.

[FhemPiUser]

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..

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...

[FhemPiUser]

nein. 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:

event-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...

[justme1968]

dann 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.

es 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.

[FhemPiUser]

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...

weil 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..

[justme1968]

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.

[FhemPiUser]

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...

[justme1968]

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.