event-on-update-reading, event-on-change-reading

Begonnen von tobyk, 01 September 2014, 20:22:25

Vorheriges Thema - Nächstes Thema

tobyk

Hallo zusammen,

um meine DbLog schlank zu halten würde ich gerne die event-on-* einsetzten. Da ich bis auf die CommandoRef. aber nichts genaueres gefunden habe hier noch einmal eine Frage zu den Attributen:

Ich verstehe nicht wirklich den Unterschied zwischen den beiden, da ich bisher nicht den Unterschied zwischen einem Update und einem Change gefunden habe.
Ist ein Update jetzt ein reins Auslesen der Readings und ein Change sozusagen ein Update mit Prüfung ob sich etwas geändert hat?

Ebenfalls verwirrt mich die Referenz etwas:
" 2. Wenn eines der Attribute gesetzt ist, erzeugen nur Updates oder änderungen von "readings" die nicht in einem der Attribute gesetzt sind ein Ereignis."
Im Englischen ist hier eine doppelte Verneinung. Ist die Englische die richtige Beschreibung?

Ich wäre sehr über eine Hilfe und vielleicht ein paar einfach zu verstehende Beispiele dankbar. Ich würde dann auch gerne eine kurze Zusammenfassung hierzu ins Wiki packen. Ich denke ich bin nicht der einzige, der sich mit dem Thema etwas schwer tut :-).

Gruß und vielen Dank
TobyK

 

Bennemannc

Hallo,

Du hast das schon sehr richtig erkannt. Genutzt wird das mit einer Liste von readings (komma getrennt) dahinter. Es kann bei event-on-change auch noch ein THRESHOLD - also ein Wert angegeben werden um den das "neue" reading größer oder kleiner sein soll.
Attr event-on-change-reading temperature:0.4, humidity:2, ...
Dann wird z.B. nur bei Änderungen der Temperatur um mindestens 0,4 Grad oder Änderung der Luftfeuchtigkeit von 2 % ein Eintag ins Log geschrieben. Alle anderen Reading Batterie oder was es da noch gibt, lösen bei Änderung keine Event mehr aus.
Im Umkehrschluss gilt das natürlich auch für die Notifys - auch hier macht dann ein notify auf Batterie keinen Sinn mehr, weil das Event unterdrückt wird.
Es gibt eine Reihenfolge (mal im Forum suchen) in der Update und change abgearbeitet werden.

Gruß Christoph

Cubietruck, Fhem 5.8
CC-RT-DN|LC-SW2-FM|RC-12|RC-19|LC-SW4-BA-PCB|LCp-SW1-BA-PCB|ES-PMSw1-Pl|LC-Bl1PBU-FM|PBI-4-FM|CC-VD|CC-TC|SEC-SC(2)|RC-KEY3-B|LC-Sw1PBU-FM|PB-2-FM|WDS100-C6-O|WDC7000|LC-Bl1-FM
Module: Dewpoint,FB_Callmonitor,HCS,Panstamp,at,notify,THRESHOLD,average,DOIF

Icinger

Update -> Feuert auch, wenn der selbe Wert, der bereits im Reading steht, nochmal reingeschrieben wird
Change -> Feuert nur, wenn der neue Wert wirklich abweichend vom alten Wert ist.

lg, Ici
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

u302320

Um das ganze noch etwas zu verkomplizieren gibt es dann noch event-min-interval. Damit lässt sich zu jedem Attribut eine Zeit angeben. Kombiniert mit Update und Change sieht das dann so aus:

Update + Min-Interval -> Feuert, wenn der selbe Wert, der bereits im Reading steht, nochmal reingeschrieben wird UND mindestens min-interval Sekunden seit dem letzten Event vergangen sind

Change -> Feuert, wenn der neue Wert wirklich abweichend vom alten Wert ist ODER mindestens min-interval Sekunden seit dem letzten Event vergangen sind.

In der Regel wirst du event-on-change-reading + min-interval kombinieren wollen. Das Min-Interval deshalb, damit du von Zeit zu Zeit ein paar Einträge in deinem Logfile hast. (Findet FHEM zu wenig Ereignisse pro betrachteter Zeitspanne, bleibt das Diagramm leer oder wird nur teilweise gezeichnet -> Plotabriss).

Die Dokumentation ist ... nicht ganz klar. Ich hab mir heute auch den Perl-Code anschauen müssen, um zu verstehen, was genau wann passiert bzw nicht passiert.

moemoe

Danke für die Beschreibung oben, ich denke damit ist es mir auch klar geworden :)

Zitat von: Mattias am 02 September 2014, 22:58:14
In der Regel wirst du event-on-change-reading + min-interval kombinieren wollen. Das Min-Interval deshalb, damit du von Zeit zu Zeit ein paar Einträge in deinem Logfile hast. (Findet FHEM zu wenig Ereignisse pro betrachteter Zeitspanne, bleibt das Diagramm leer oder wird nur teilweise gezeichnet -> Plotabriss).

Wo liegt hier denn die Grenze, also welches Intervall ist sinnvoll, um einen Plotabriss zu verhindern?

Grüße
Moritz

tobyk

So jetzt habe ich auch endlich Zeit mich zu bedanken.
Gerade die Antwort von Mattias hat mich sehr weiter gebracht. Vielen Dank und daumen hoch.

@moemoe:
Deine maximale Verzögerung ist gleichzeitig auch dein maximaler Wert, um den dein Plot abreißen kann. Idealer weise wären also zwei Punkte um 00:01 Uhr und 23:59 Uhr sinnvoll, was man aber mit den hier genannten Attributen nicht wird realisieren können. Ob man FHEM zwingen kann an ganz bestimmten Uhrzeiten Werte aufzunehme weiß ich nicht, habe aber auch nicht weiter im Forum danach gesucht.

Gruß Toby

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

strauch

#7
Zitat von: Mattias am 02 September 2014, 22:58:14
Change -> Feuert, wenn der neue Wert wirklich abweichend vom alten Wert ist ODER mindestens min-interval Sekunden seit dem letzten Event vergangen sind.

Was ich gut gebrauchen könnte wäre hier ein und statt ein oder. Irgendwie will mir aber nicht einfallen wie. Also:
Feuert nur wenn der Wert vom alten Wert abweicht und zusätzlich mindest x Sekunden vergangen sind.

Hat jemand dazu eine Idee?

Das wäre sehr gut zur Reduktion der Events und auch um die Logs klein zu halten.
Ich könnte natürlich auch eine Schwelle einstellen aber der wieder geloggt wird z.B: die Temperatur meine Gastherme nur in 1°C Schritten und nicht 0,1°C. Aber bei manchen Geräten sind es viele Readings und damit mehr Arbeit und da wäre was allgemeines einfacher.

Edit: Meine bisherige Lösung sieht dann z.B. so aus (Messwerte mit min-interval und Zustände mit Event on change):
Attributes:
   event-min-interval ch_Tflow_measured:120,ch_burner_power:120,dhw_Tcylinder:120,dhw_Tmeasured:120,hc1_Tmeasured:120,sol_Tcollector:120,sol_Tcylinder_bottom:120
   event-on-change-reading ch_Tflow_desired,ch_Tmixer,ch_Toutside,ch_Treturn,ch_burner_fan,ch_burner_operation,ch_mode,ch_pump_circulation,ch_pump_cylinder,ch_pump_heating,ch_runtime_ch,ch_runtime_dhw,ch_runtime_tot,ch_starts_ch,ch_starts_dhw,ch_starts_tot,ch_time,dhw_Tdesired,hc1_Tdesired,hc1_mode,sol_pump,sol_runtime,sol_yield_2,sol_yield_last_hour,state
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

DerFrickler

Zitat von: strauch am 14 Januar 2015, 10:46:40
Was ich gut gebrauchen könnte wäre hier ein und statt ein oder. Irgendwie will mir aber nicht einfallen wie. Also:

genau das ist es, ein UND fehlt an dieser Stelle... ich kämpfe auch gegen Windmühlen bzw. die Datenflut indem ich event-on-change-reading und event-min-interval benutze; zudem habe ich mein Datenwort schon auf eine Nachkommastelle gekürzt.

ZitatInternals:
   CFGFN
   NAME       power.measures.FBDECT_20000
   NR         107
   STATE      15.8 W
   TYPE       dummy
   CHANGETIME:
   Helper:
     Dblog:
       Power:
         Loggingdblog:
           TIME       1421253871.41402
           VALUE      15.8
   Readings:
     2015-01-14 17:44:31   power           15.8
     2015-01-14 17:44:31   state           15.80
Attributes:
   alias      TV/Video Schlafzimmer
   event-min-interval power:180
   event-on-change-reading power
   group      Leistungsmessung Schlafzimmer
   icon       measure_power
   room       Leistungsmessung,Schlafzimmer
   stateFormat {sprintf("%.1f W", ReadingsVal($name,"state",0))}
   userReadings power {sprintf("%.1f", ReadingsVal($name,"state",0))}

leider mit mässigem Erfolg:

Zitat2015-01-14 17:38:00: power.measures.FBDECT_20000, DUMMY, power: 15.7, power, 15.7,
2015-01-14 17:38:30: power.measures.FBDECT_20000, DUMMY, power: 15.8, power, 15.8,                     (bis hier nur 30 Sekunden)
2015-01-14 17:39:30: power.measures.FBDECT_20000, DUMMY, power: 15.7, power, 15.7,                     (bis hier nur 60 Sekunden)
2015-01-14 17:40:00: power.measures.FBDECT_20000, DUMMY, power: 15.8, power, 15.8,                     (bis hier nur 30 Sekunden)
2015-01-14 17:43:03: power.measures.FBDECT_20000, DUMMY, power: 15.9, power, 15.9,

das hier sind die Quelldaten der Powerline546E, die auch nur "on-change", dann aber alle 120 Sekunden kommen sollten

Zitat2015-01-14 17:38:00: FBDECT_20000, FBDECT, power: 15.73 W, power, 15.73, W             
2015-01-14 17:38:30: FBDECT_20000, FBDECT, power: 15.80 W, power, 15.80, W                                (lediglich 30 Sekunden, 120 sollten es sein)
2015-01-14 17:39:30: FBDECT_20000, FBDECT, power: 15.73 W, power, 15.73, W                                (hier sind es 60 Sekunden zu wenig)
2015-01-14 17:40:00: FBDECT_20000, FBDECT, power: 15.80 W, power, 15.80, W                                (hier sind es dann 90 Sekunden zu wenig)
2015-01-14 17:42:01: FBDECT_20000, FBDECT, power: 15.80 W, power, 15.80, W                                (hier wurde das on-change ignoriert, möglicherweise war aber der Wert innerhalb der 120 Sekunden unterschiedlich und hat dann dadurch das minimum-interval ausgelöst... nur zum Auslösezeitpunkt war der Wert dann zurück auf dem Ursprungswert) 
2015-01-14 17:43:00: FBDECT_20000, FBDECT, power: 15.87 W, power, 15.87, W                                (lediglich 59 Sekunden)

das on-change funktioniert ja soweit, nur das minimum-interval wird dabei nicht beachtet.


Das lustige an der Sache ist dass ich bei anderen Daten genau das gegenteilige Problem habe und mit addLog Daten auffüllen muss, allem Anschein nach reichen 2 Datenpunkte für einen Plot nicht aus (http://forum.fhem.de/index.php/topic,31896.msg243573.html#msg243573). Es ist halt wie beim Wetter... wie es auch ist, man schimpft darüber.

andies

Habt Ihr inzwischen eine Lösung für das und-Problem?
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

doc.

Zitat von: u302320 am 02 September 2014, 22:58:14

Change -> Feuert, wenn der neue Wert wirklich abweichend vom alten Wert ist ODER mindestens min-interval Sekunden seit dem letzten Event vergangen sind.


Hallo zusammen,

also irgendwie bin ich am verzweifeln...genau das macht es bei mir nicht...

event-min-interval 3600
event-on-change-reading .*


führt bei mir zu:

24.04.20 13:10 SchlaZiHeizung FHT measured-temp: 19.3 measured-temp 19.03.20 °C
24.04.20 13:10 SchlaZiHeizung FHT temperature: 19.3 temperature 19.03.20 °C
24.04.20 12:42 SchlaZiHeizung FHT measured-temp: 19.2 measured-temp 19.02.20 °C
24.04.20 12:42 SchlaZiHeizung FHT temperature: 19.2 temperature 19.02.20 °C
24.04.20 12:11 SchlaZiHeizung FHT measured-temp: 19.1 measured-temp 19.01.20 °C
24.04.20 12:11 SchlaZiHeizung FHT temperature: 19.1 temperature 19.01.20 °C
24.04.20 11:43 SchlaZiHeizung FHT measured-temp: 19.0 measured-temp 19.0 °C
24.04.20 11:43 SchlaZiHeizung FHT temperature: 19.0 temperature 19.0 °C
24.04.20 11:13 SchlaZiHeizung FHT actuator: 0% actuator 0 %
24.04.20 11:13 SchlaZiHeizung FHT klima: ja klima ja
24.04.20 11:13 SchlaZiHeizung FHT FensterOffenBool: 100 FensterOffenBool 100
24.04.20 11:10 SchlaZiHeizung FHT measured-temp: 18.9 measured-temp 18.09.20 °C
24.04.20 11:10 SchlaZiHeizung FHT temperature: 18.9 temperature 18.09.20 °C


Um 12:13 (bzw. nächste Aktualisierung nach 12:13) hätte ich erwartet, daß die Werte von 11:13 geschrieben werden, obwohl sie sich nicht geändert haben.

Ist meine Erwartung falsch?

Gruß,
doc.

CoolTux

Zeige mal bitte ein sauberes list

list SchlaZiHeizung
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

frank

bei event-min-interval sehe ich kein readingnamen.
siehe commandref.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

CoolTux

event-min-interval .*:3600


Deswegen das list. Dachte er hätte sich da vertan
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

doc.