Autor Thema: BEST PRACTICE: event-on-change-reading vs. event-on-update-reading  (Gelesen 17056 mal)

Offline vbs

  • Hero Member
  • *****
  • Beiträge: 2473
Also ich denke, dass ich inhaltlich die event-on-*-Attribute verstehe (hoffentlich) und auch das Zusammenspiel mit event-min-interval. Aber mir ist noch nicht so klar, wann man am besten welche Attribute einsetzt bzw. nach welchen Kriterien man entscheidet, wo man welches Reading einträgt.

Generell will man ja die Anzahl der Events minimieren bzw. keine unnötigen Events generieren. Ich gehe dabei im Moment so vor:
1. Ich trage die relevanten Readings in event-on-change-reading ein.
   Relevant sind:
     - Readings, auf die ich per notify reagieren möchte
     - Readings, die ich plotten möchte
     - Readings, die ich per longpoll in der GUI live updaten möchte
2. Falls sich Werte wegen on-change ZU selten ändern, trage ich sie zusätzlich bei event-min-interval on, um alle x Minuten doch ein Event zu bekommen (zB zum Plotten).
3. Bei Geräten, bei denen ich keine Events brauche, trage ich nur bei event-on-update-reading einen leeren String ein (resultiert dann im Wert "1").

Nach welchen Kriterien geht ihr vor? Wann genau ist event-on-update-reading überhaupt sinnvoll?
« Letzte Änderung: 21 April 2015, 13:20:03 von vbs »

Offline peterchen89

  • Jr. Member
  • **
  • Beiträge: 97
    • Mein Blog
Ich glaube das event-min-interval hast du nicht ganz richtig verstanden (aus der Doku):
Zitat
event-min-interval
Dieses Attribut enthält eine durch Kommata getrennte Liste von "readings:minInterval" Paare. readings kann ein regexp sein. Ein Event wird nur dann generiert, falls seit dem letzten Auftreten des gleichen Events mindestens minInterval Sekunden vergangen sind.
D.h. es wird höchstens alle X Sekunden ein Event generiert.

Das von dir beschriebene Problem mit dem Plotten kannst du mit Logproxy in den Griff bekommen. Logproxy kann etwas weiter in die Vergangenheit gucken und so den Plot nach Vorne hin sozusagen verlängern.
« Letzte Änderung: 21 April 2015, 12:41:18 von peterchen89 »
FHEM 5.5 auf HP ProLiant MicroServer G7 N54L 8 GB Ubuntu 14.04 LTS.
1x HM-CFG-LAN, 1x HM-CFG-USB, 7x HM-CC-RT-DN, 5x HM-SEC-SC-2, 1x HM-SEC-SCo, 2x HM-TC-IT-WM-W-EU, 2x HM-LC-Sw1-Pl, 2x HM-ES-PMSw1-Pl, 4x HM-PB-2-WM55-2, 1x HM-PB-6-WM55, 1x HM-WDS10-TH-O, 1x CUL433, 6x Pollin Funksteckdose

Offline vbs

  • Hero Member
  • *****
  • Beiträge: 2473
Ich glaube das event-min-interval hast du nicht ganz richtig verstanden (aus der Doku):D.h. es wird höchstens alle X Sekunden ein Event generiert.
So viel ich weiß, ist das eben genau nicht so. Es verhält sich scheinbar unterschiedlich bei on-change und on-update. Es wird einmal verODERt und einmal verUNDet:
http://forum.fhem.de/index.php/topic,26694.msg196955.html#msg196955
http://forum.fhem.de/index.php/topic,31856.msg247547.html#msg247547

Das von dir beschriebene Problem mit dem Plotten kannst du mit Logproxy in den Griff bekommen. Logproxy kann etwas weiter in die Vergangenheit gucken und so den Plot nach Vorne hin sozusagen verlängern.
Ja, das kenne ich. Empfinde ich persönlich aber eher als Workaround. Dieses "etwas weiter" ist leider schlecht greifbar.
« Letzte Änderung: 21 April 2015, 13:14:58 von vbs »

Offline Hollo

  • Hero Member
  • *****
  • Beiträge: 1443
Ich glaube das event-min-interval hast du nicht ganz richtig verstanden (aus der Doku):D.h. es wird höchstens alle X Sekunden ein Event generiert...
Nein, er hat es richtig verstanden.   :)
Wenn längere Zeit KEIN Event kommt, weil sich der Wert NICHT geändert hat (on-change), dann wird nach MIN-INTERVAL trotzdem ein Event generiert.
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

Offline frank

  • Hero Member
  • *****
  • Beiträge: 10690
Zitat
Nach welchen Kriterien geht ihr vor? Wann genau ist event-on-update-reading überhaupt sinnvoll?
sobald man bei event-on-change/update explizit ein odere mehrere readings angibt, werden bei allen nicht aufgeführten readings die events abgeschaltet. daher mache ich grundsätzlich "event-on-change-reading .*", um grundsätzlich die events zu minimieren, aber trotzdem alle infos speichern zu können. also alle readings erzeugen events bei änderung. wenn ich nun bei bestimmten readings aber immer ein event brauche, zb bei buttons oder zum überwachen der rssi-werte, setze ich für diese readings zusätzlich event-on-update.

Zitat
Wenn längere Zeit KEIN Event kommt, weil sich der Wert NICHT geändert hat (on-change), dann wird nach MIN-INTERVAL trotzdem ein Event generiert.
nicht ganz. sondern erst, wenn das reading neu gesetzt wird. also wenn ein reading alle 5 minuten gesetzt wird, es sich aber nicht ändert und min-interval auf 12 min eingestellt ist, sollte das event nach 15 minuten erscheinen.

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

bendim

  • Gast
Antw:BEST PRACTICE: event-on-change-reading vs. event-on-update-reading
« Antwort #5 am: 06 Dezember 2015, 04:36:28 »
Zitat
Generell will man ja die Anzahl der Events minimieren bzw. keine unnötigen Events generieren. Ich gehe dabei im Moment so vor:
1. Ich trage die relevanten Readings in event-on-change-reading ein.
   Relevant sind:
     - Readings, auf die ich per notify reagieren möchte
     - Readings, die ich plotten möchte
     - Readings, die ich per longpoll in der GUI live updaten möchte
2. Falls sich Werte wegen on-change ZU selten ändern, trage ich sie zusätzlich bei event-min-interval on, um alle x Minuten doch ein Event zu bekommen (zB zum Plotten).

Zu beachten ist noch das die Readings bei event-min-interval nur ein Event auslösen, wenn sie auch in event-on-change-reading oder event-on-update-reading eingetragen sind.

Bei event-on-change-reading wird event-min-interval ignoriert wenn sie die Werte änder und sofort ein Event gefeuert
Bei event-on-update-reading wird event-min-interval nicht ignoriert wenn sie die Werte änder und wartet bis den Interval ab bis ein Event gefeuert wird


Frage: Wie kann ich Schwellenwerte für ein Reading setzen das nicht nur einen Wert beinhaltet.

Readings:
     2015-12-06 04:45:18   battery         ok
     2015-12-06 04:45:18   dewpoint        11.9
     2015-12-06 04:45:18   humidity        53
     2015-12-06 04:43:30   state           T: 21.9 H: 53 D: 11.9
     2015-12-06 04:45:18   temperature     21.9

Ich möchte das state reading alle 15min per event-min-interval ein event feuert auch wenn sich nichts ändert. Wenn sich zwischen den 15min aber der T Wert um 0.5 oder der H Wert um 5 ändert, soll mit event-on-change-reading sofort ein Event gefeuert werden.

attr LaCr.Thermo01 event-min-interval state:900
attr LaCr.Thermo01 event-on-change-reading state:??????
« Letzte Änderung: 06 Dezember 2015, 04:50:53 von bendim »

Offline willybauss

  • Hero Member
  • *****
  • Beiträge: 1883
Antw:BEST PRACTICE: event-on-change-reading vs. event-on-update-reading
« Antwort #6 am: 18 Februar 2016, 13:36:36 »
Nein, er hat es richtig verstanden.   :)
Wenn längere Zeit KEIN Event kommt, weil sich der Wert NICHT geändert hat (on-change), dann wird nach MIN-INTERVAL trotzdem ein Event generiert.

Ist zwar schon eine Weile her, aber hier gibts nochmal ne Antwort darauf:

Bevor hier was Falsches gelernt wird:
- event-min-interval sorgt dafuer, dass ein Event hoechstens alle X Sekunden (aber nicht haeufiger) durchgelassen wird, generiert aber selbst keine Events.
- event-on-change-reading laesst events nur bei Aenderung durch (optional mit mindest-delta).
- falls event-on-update-reading gesetzt ist, dann werden die nicht spezifizierten events nicht durchgelassen.
- das Wort "reading" ist in beiden Faellen irrefuehrend, da das Reading immer gesetzt wird, nur das Event wird nicht durchgelassen.
- mit _nicht_ durchlassen meine ich: Modul generiert Event, aber keiner kriegt es mit.
- falls event-on-change-reading zuschlaegt, filtert min-interval nicht (aber da bin ich mir nicht ganz sicher, der Code ist relativ verwirrend).


Das Setzen dieser Attribute erzeugt auch CPU-Last, ob es unter dem Strich weniger Last auf dem System ist, haengt vom Einzelfall ab.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS, CO20, FHEM2FHEM
Hilfreich Hilfreich x 1 Liste anzeigen

Offline sash.sc

  • Hero Member
  • *****
  • Beiträge: 1940
Hallo zusammen.

Habe da nochmal eine Frage zu. Habe dies auch schonmal hier gestellt.
https://forum.fhem.de/index.php/topic,51554.msg463686.html#msg463686

Nochma kurz zusammen gefasst. Energiemessteckdose soll geloogt werden. Von den Reading allerdings nur das state, da ja alle Parameter vorhanden sind. Wenn ich ins Log schaue, dann werden auch die kleinsten Änderungen mitgeloggt, welche aber bei Änderung von 0.1 Watt keinen Sinn machen, diese zu loggen.

Es soll nur das state geloggt werden, wenn es Änderungen in der Spannun bzw. im Strom gibt. Ich möchte das state aber nur loggen, wenn die Änderung der Leistung mehr wie 2 Watt sind  oder Änderung in der Spannung von mehr wie 2 Volt.

Irgendwie bekomme ich das nicht hin.

Jemanmd eine Idee ???

Gruß und danke
Sascha

« Letzte Änderung: 19 Juni 2016, 21:10:37 von sash.sc »
Raspi 4B+ Buster ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; grafana mit influxdb

Offline vbs

  • Hero Member
  • *****
  • Beiträge: 2473
Du könntest zB mit dem Attribut stateFormat den Inhalt des state-Readings selbst definieren (zB ohne Nachkommastellen). Du müsstest das allerdings dann selbst in Perl-Code implementieren.

Offline sash.sc

  • Hero Member
  • *****
  • Beiträge: 1940
D.h. Die Nachkommastelle von der Leistung einfach abschneiden?!
Von Perl habe ich absolut keine Ahnung. Wie sollte das denn dann aussehen?

Gesendet von meinem SM-T560 mit Tapatalk

Raspi 4B+ Buster ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; grafana mit influxdb

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 21051
STATE ist nicht das gleiche wie state. ersteres ist ein internal letzteres ein reading.

mit stateFormat legst du fest wie STATE aussehen soll. das ist das was im frontend angezeigt wird. nicht das reading state das ein event erzeugt das geloggt wird.

du kannst dir ein user reading definieren und dort passend formatieren oder differenzen bestimmen und dann dieses loggen.

bei einem hm aktor müsstest du aber auch konfigurieren können ab welchem
schwellwert die werte überhaupt gesendet werden.

gruss
  andre

FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline sash.sc

  • Hero Member
  • *****
  • Beiträge: 1940
Zitat
bei einem hm aktor müsstest du aber auch konfigurieren können ab welchem
schwellwert die werte überhaupt gesendet werden.

Dies ist kein HM Aktor, sonder eine Funkmessteckdose NC-5426. STATE ist also nicht gleich state. Wann wird denn STATE aktualisiert ?
Ich logge im Moment das state aus den Readings, also direkt von der Steckdose.

Danke schonmal für eure Hilfe.
Sascha
Raspi 4B+ Buster ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; grafana mit influxdb

Offline vbs

  • Hero Member
  • *****
  • Beiträge: 2473
Argh sorry, richtig, war Quatsch was ich gesagt habe...  ::)

t.huber

  • Gast
Antw:BEST PRACTICE: event-on-change-reading vs. event-on-update-reading
« Antwort #13 am: 24 Januar 2017, 23:00:46 »
OK jetzt hab ich mir einige Forenbeiträge und alle 2-3 Wiki-Einträge zu dem Thema durchgelesen.
Entweder ich kapier es doch nicht oder die Funktion ist buggy.

Update + Min-Interval sollte doch nur ein Event auslösen wenn der Wert geändert wird und die Min-Interval (in Sekunden) erreicht ist.

Ich habe eine HM-ES-PMSw1-Pl Mess-Schalt-Steckdose. (Das Device hat 6 Unter-Channels)
Diese bombardierte mich mit Events im Log.
Das hab ich soweit im Griff. (mit attr suppressReading state) auf 4/6 Channels und einem event-on-change-reading state auf das Main-Device.
Interesse habe ich nur an den 2 Readings der verbleibenden 2 Channels für Aktueller Stromverbrauch in Watt (..._SenPwr) und dem Gesamtzähler (..._Pwr) des Stromverbrauches.
Den Wert des Gesamtzählers würde mir momentan 1x am Tag reichen. (86400 Sekunden)

_SenPwr passt.
_Pwr besitz die Attribute event-min-interval 86400 und event-on-update-reading state
^(event-on-update-reading energy habe ich auch schon probiert)

Aber er schreibt trotzdem alle 10-30 Sekunden.

Im Anhang sind die Screenshots vom Main-Device, vom Unter-Channel _SenPwr und vom Unter-Channel _Pwr.

und so sieht trotzdem das Ergebnis im Event Monitor aus:
2017-01-24 22:50:38 CUL_HM HM_32B1AE_Pwr 186526.3
2017-01-24 22:50:38 CUL_HM HM_32B1AE_SenPwr 365.75
2017-01-24 22:51:22 CUL_HM HM_Bewegungsmelder brightness: 58
2017-01-24 22:52:45 CUL_HM HM_32B1AE_Pwr 186539.3
2017-01-24 22:52:45 CUL_HM HM_32B1AE_SenPwr 403.01
2017-01-24 22:52:53 CUL_HM HM_32B1AE_Pwr 186540.1
2017-01-24 22:52:53 CUL_HM HM_32B1AE_SenPwr 371.79
2017-01-24 22:53:01 CUL_HM HM_32B1AE_Pwr 186540.9
2017-01-24 22:53:01 CUL_HM HM_32B1AE_SenPwr 367.02
2017-01-24 22:53:35 CUL_HM HM_32B1AE_Pwr 186544.4
2017-01-24 22:53:35 CUL_HM HM_32B1AE_SenPwr 367.36
2017-01-24 22:56:05 CUL_HM HM_32B1AE_Pwr 186559.8
2017-01-24 22:56:05 CUL_HM HM_32B1AE_SenPwr 389.38
2017-01-24 22:56:13 CUL_HM HM_32B1AE_Pwr 186560.6
2017-01-24 22:56:13 CUL_HM HM_32B1AE_SenPwr 369.61
2017-01-24 22:56:18 CUL_HM HM_32B1AE_Pwr 186561.1
2017-01-24 22:56:18 CUL_HM HM_32B1AE_SenPwr 380.72
2017-01-24 22:56:21 CUL_HM HM_32B1AE_Pwr 186561.4
2017-01-24 22:56:21 CUL_HM HM_32B1AE_SenPwr 371.49
2017-01-24 22:56:36 CUL_HM HM_32B1AE_Pwr 186563
2017-01-24 22:56:36 CUL_HM HM_32B1AE_SenPwr 391.87
2017-01-24 22:56:44 CUL_HM HM_32B1AE_Pwr 186563.8
2017-01-24 22:56:44 CUL_HM HM_32B1AE_SenPwr 370.62

Offline marvin78

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5898
Antw:BEST PRACTICE: event-on-change-reading vs. event-on-update-reading
« Antwort #14 am: 25 Januar 2017, 07:16:29 »
Bitte immer lists in Codetags, statt Screenshots posten!!

Und dann bitte wirklich an den richtigen Stellen lesen. Der 1. Anlaufpunkt ist IMMER die offizielle Doku und die sagt zu event-min-interval

Zitat
[...]comma-separated list of reading:minInterval pairs[...]

Also sowas:

attr <NAME> event-min-interval energy:86400