Event-on-change-reading: Unterschied zwischen den Versionen

Aktuelle Version vom 5. Februar 2022, 19:33 Uhr

Mit dem Attribut event-on-change-reading kann für Readings eines Gerätes festgelegt werden, dass nur bei einer Wertänderung ein Event (und damit in der Regel auch ein Log-Eintrag) erzeugt werden soll und nicht bei jedem turnusmäßigen Update des Gerätes.

Wird event-on-change-reading für ein einzelnes Reading gesetzt, werden zunächst alle übrigen Readings nicht mehr protokolliert, erzeugen also keine Events mehr.

Einführung

Grundsätzlich senden Geräte ihre Readings dann, wenn ein Ereignis zu einer Statusänderung führt, also z.b. ein Schalter betätig wird. Allerdings senden die meisten Geräte auch immer Zusatzinformationen, etwa den Batteriestatus, Zieltemperatur, Pairingstatus, PeerList etc.etc.; meist sogar in bestimmten Intervallen (Update) auch ohne das das Reading sich ändert. Einige Geräte wie z.b. Shelly Plugs sind sehr "gesprächig" und senden auch den Status des Tasters mit jedem Update, selbst wenn der Schaltzustand sich nicht ändert.

Dies hat einige Nachteile:

Aufblähen des Logfiles
höhere Last der FHEM-Installation, da ein Event vom GeraetXXXX zunächst alle Notifys in FHEM benachrichtigt (d.h. notify, FileLog, sequence, watchdog, DOIF, etc), auch wenn diese mit dem Event nichts anfangen können.
Konstrukte der Art … notify GeraetXXXX:wert … werden unter Umständen immer wieder im Update-Intervall ausgelöst, obwohl der Schaltzustand sich nicht geändert hat. (z.b. bei Shelly Plugs)
EvenMonitor bzw. Telnet Info Timer mitunter unübersichtlich

Mit event-on-change-reading lässen sich für Readings eines Gerätes festgelegt, dass nur bei einer Wertänderung ein Event erzeugt wird und nicht mit jedem Update. Dies adressiert alle oben genannten Nachteile.

Allerdings kann die Nutzung von event-on-change-reading auch selbst Probleme erzeugen:

Es muss überlegt werden, ob die eigene FHEM Installation an manchen Stellen in bestimmten Intervallen Meldungen benötigt, auch wenn die Werte sich nicht ändern. Dies sind typischerweise Graphen.
Wird event-on-change-reading für ein einzelnes Reading gesetzt, erzeugen alle übrigen Readings des Gerätes keine Events mehr, auch nicht wenn Werte sich ändern.

Um das Verhalten von event-on-change-reading zu modifizieren und diese Probleme zu lösen, stehen ausserdem die Attribute event-on-update-reading (Reading soll mit jedem Update gesendet werden, auch wenn es sich nicht geändert hat) und event-min-interval ((Reading soll mit Update gesendet werden, wenn seit der letzten Meldung ZeitspanneX vergangen ist) zur Verfügung.

Syntax

Das event-on-change-reading Attribut wird in der folgenden Weise spezifiziert:

attr <device> event-on-change-reading reading1[:threshold][,reading2[:threshold]...n]

Die zu berücksichtigenden Readings sind als durch Komma getrennte Werte anzugeben, können aber auch über reguläre Ausdrücke zusammengefasst werden.

Insbesondere sinnvoll ist der reguläre Ausdruck .* , der alle Readings umfasst:

attr <device> event-on-change-reading .*

So formuliert führt das Attribut dazu, dass alle Readings noch Events erzeugen, aber nur wenn diese sich im Wert ändern.

Mit Threshold ist optional ein Wert angebbar, um den das "neue" Reading größer oder kleiner sein soll als das vorherige, um ein Event auszulösen. So löst

attr event-on-change-reading temperature:0.4,humidity:2

nur bei Änderungen der Temperatur um mindestens 0,4 Grad oder Änderung der Luftfeuchtigkeit von 2 % ein Event aus (und damit einen Eintrag ins Logfile). Threshold ist besonders sinnvoll bei sehr fein auflösenden Sensoren, um z.B. zu verhindern, dass jede Temperaturschwankung um 0,1 Grad ein Event auslöst.

Wechselwirkungen

Wie oben erwähnt, steht das Attribut in Wechselwirkung mit den Attributen timestamp-on-change-reading event-on-update-reading und event-min-interval, die das Verhalten modifizieren. Dies ist beim Einsatz zu berücksichtigen.

Sind bei einem Device weder event-on-change-reading noch event-on-update-reading spezifiziert, werden für alle Readings sowohl bei Änderung als auch bei der Aktualisierung (Update mit dem gleichen Wert) Events erzeugt (Default Verhalten). Sobald jedoch eines der beiden Attribute gesetzt ist, müssen alle Readings, die protokolliert werden sollen, bei (mindestens) einem der Attribute berücksichtigt sein.

Ist für ein Reading sowohl event-on-change-reading als auch event-on-update-reading spezifiziert, wird bei jeder Aktualisierung des Readings ein Event erzeugt, das event-on-change wird für dieses Reading also außer Kraft gesetzt bzw. "überstimmt".

timestamp-on-change-reading

Ist nur event-on-change-reading für ein Reading spezifiziert, entfällt zunächst einmal nur der Trigger, der Zeitstempel wird weiter aktualisiert. Benötigt man jedoch den Zeitstempel der letzten Änderung (z.B. die Ein- oder Ausschaltzeit eines Relais), kann man mithilfe von timestamp-on-change-reading auch die Aktualisierung des Zeitstempels unterbinden, falls der Wert sich nicht geändert hat.

Beispiel

In einer einfachen Anwendung kann, um alle Readings eines Gerätes nur bei Änderungen zu verarbeiten, das Attribut folgendermaßen gesetzt werden:

attr <device> event-on-change-reading .*

Zusätzlich kann mit

attr <device> event-min-interval .*:3600

dafür gesorgt werden, dass jede Stunde auch ohne Werteänderung die Readings dennoch verarbeitet werden, also in z.b. in das Logfile geschrieben werden (findet FHEM zu wenige Ereignisse pro betrachteter Zeitspanne, bleiben Graphen leer oder werden nur teilweise gezeichnet (Plotabriss)).

Das obige Kombination der Attribute führt also dazu, dass ein Event erzeugt wird, wenn der neue Wert wirklich abweichend vom alten Wert ist oder mindestens min-interval Sekunden seit dem letzten Event vergangen sind.

Achtung: dies löst wie oben beschrieben ggf. Konstrukte wie … notify GeraetXXXX:wert … aus.

Falls ein Reading namens "unwanted" KEINE Events erzeugen soll, lässt sich das mit

attr <device> event-on-change-reading (?!unwanted).*

unterdrücken.

Wenn KEIN Event bei einem Gerät erzeugt werden soll, lässt sich das mit

attr <device> event-on-change-reading $

erreichen.

Um ein Threshold für nur ein Reading zu setzen:

attr <device> event-on-change-reading Temp.*:0.4,.*

Alle Readings, die mit Temp beginnen, erzeugen nur ein Event, wenn die Änderung >0.4 Grad ist. Alle anderen Readings erzeugen bei jeder Änderung ein Event.

Nur ein Reading mit Threshold berücksichtigen:

attr <device> event-on-change-reading Temp.*:0.4

Alle Readings, die mit Temp beginnen, erzeugen nur ein Event, wenn die Änderung >0.4 Grad ist. Alle anderen Readings erzeugen keine Event, auch nicht bei Werteänderung.

Mit event-on-update-reading und event-min-interval kann das Verhalten verfeinert werden.

Siehe auch

Forenbeitrag
event-on-update-reading
event-min-interval
event-aggregator
Benutzungstipps (Best Practice) für das Attribut in diesem Forenthread

@@ Zeile 1: / Zeile 1: @@
 {{SEITENTITEL:event-on-change-reading}}  <!-- da richtige Schreibweise kleinen Anfangsbuchstaben hat -->
 <!-- Infobox Attribut sinnvoll? -->
-Mit dem Attribut [[event-on-change-reading]] kann für Readings eines Gerätes festgelegt werden, dass nur bei einer Wertänderung ein Event (und damit in der Regel auch ein Log-Eintrag) erzeugt werden soll. Damit stellt das Attribut eine Möglichkeit zur Verfügung, die Menge von Log-Einträgen zu reduzieren.
+Mit dem Attribut [[event-on-change-reading]] kann für Readings eines Gerätes festgelegt werden, dass nur bei einer Wertänderung ein Event (und damit in der Regel auch ein Log-Eintrag) erzeugt werden soll und nicht bei jedem turnusmäßigen Update des Gerätes.
 Wird ''event-on-change-reading'' für ein einzelnes Reading gesetzt, werden zunächst alle übrigen Readings nicht mehr protokolliert, erzeugen also keine Events mehr.
+== Einführung ==
+Grundsätzlich senden Geräte ihre Readings dann, wenn ein Ereignis zu einer Statusänderung führt, also z.b. ein Schalter betätig wird. Allerdings senden die meisten Geräte auch immer Zusatzinformationen, etwa den Batteriestatus, Zieltemperatur, Pairingstatus, PeerList etc.etc.; meist sogar in bestimmten Intervallen (Update) auch ohne das das Reading sich ändert. Einige Geräte wie z.b. Shelly Plugs sind sehr "gesprächig" und senden auch den Status des Tasters mit jedem Update, selbst wenn der Schaltzustand sich nicht ändert.
+Dies hat einige Nachteile:
+* Aufblähen des Logfiles
+* höhere Last der FHEM-Installation, da ein Event vom GeraetXXXX zunächst alle Notifys in FHEM benachrichtigt (d.h. notify, FileLog, sequence, watchdog, DOIF, etc), auch wenn diese mit dem Event nichts anfangen können.
+* Konstrukte der Art <code><nowiki>… notify GeraetXXXX:wert …</nowiki></code> werden unter Umständen immer wieder im Update-Intervall ausgelöst, obwohl der Schaltzustand sich nicht geändert hat. (z.b. bei Shelly Plugs)
+* EvenMonitor bzw. Telnet ''Info Timer'' mitunter unübersichtlich
+Mit event-on-change-reading lässen sich für Readings eines Gerätes festgelegt, dass nur bei einer Wertänderung ein Event erzeugt wird und nicht mit jedem Update. Dies adressiert alle oben genannten Nachteile.
+Allerdings kann die Nutzung von ''event-on-change-reading'' auch selbst Probleme erzeugen:
+*  Es muss überlegt werden, ob die eigene FHEM Installation an manchen Stellen in bestimmten Intervallen Meldungen benötigt, auch wenn die Werte sich nicht ändern. Dies sind typischerweise Graphen.
+* Wird ''event-on-change-reading'' für ein einzelnes Reading gesetzt, erzeugen alle übrigen Readings des Gerätes keine Events mehr, '''auch nicht wenn Werte sich ändern'''.
+Um das Verhalten von event-on-change-reading zu modifizieren und diese Probleme zu lösen, stehen ausserdem die Attribute [[event-on-update-reading]] (Reading soll mit jedem Update gesendet werden, auch wenn es sich nicht geändert hat) und [[event-min-interval]] ((Reading soll mit Update gesendet werden, wenn seit der letzten Meldung ZeitspanneX vergangen ist) zur Verfügung.
 == Syntax ==
@@ Zeile 10: / Zeile 28: @@
 Die zu berücksichtigenden Readings sind als durch Komma getrennte Werte anzugeben, können aber auch über reguläre Ausdrücke zusammengefasst werden.
-Insbsondere sinnvoll ist
+Insbesondere sinnvoll ist der reguläre Ausdruck .* , der alle Readings umfasst:
-<code><nowiki>event-on-change-reading .*</nowiki></code> Dies führt dazu, das alle Readings noch Events erzeugen, aber nur wenn diese sich im Wert ändern.
+:<code><nowiki>attr <device> event-on-change-reading .*</nowiki></code>
+So formuliert führt das Attribut  dazu, dass alle Readings noch Events erzeugen, aber nur wenn diese sich im Wert ändern.
+Mit Threshold ist optional ein Wert angebbar, um den das "neue" Reading größer oder kleiner sein soll als das vorherige, um ein Event auszulösen. So löst
+:<code>attr event-on-change-reading temperature:0.4,humidity:2 </code>
+nur bei Änderungen der Temperatur um mindestens 0,4 Grad oder Änderung der Luftfeuchtigkeit von 2 % ein Event aus (und damit einen Eintrag ins Logfile). Threshold ist besonders sinnvoll bei sehr fein auflösenden Sensoren, um z.B. zu verhindern, dass jede Temperaturschwankung um 0,1 Grad ein Event auslöst.
 == Wechselwirkungen ==
-Dieses Attribut steht in Wechselwirkung mit den Attributen ''timestamp-on-change-reading'' [[event-on-update-reading]] und [[event-min-interval]], bitte also unbedingt auch deren Beschreibung berücksichtigen!
+Wie oben erwähnt, steht das Attribut in Wechselwirkung mit den Attributen ''timestamp-on-change-reading'' [[event-on-update-reading]] und [[event-min-interval]], die das Verhalten modifizieren. Dies ist beim Einsatz zu berücksichtigen.
-Sind bei einem Device weder ''event-on-change-reading'' noch ''event-on-update-reading'' spezifiziert, werden für alle Readings sowohl bei Änderung als auch bei der Aktualisierung (mit dem gleichen Wert) Events erzeugt. Sobald jedoch eines der beiden Attribute gesetzt ist, müssen alle Readings, die protokolliert werden sollen bei (mindestens) einem der Attribute berücksichtigt sein.
+Sind bei einem Device weder ''event-on-change-reading'' noch ''event-on-update-reading'' spezifiziert, werden für alle Readings sowohl bei Änderung als auch bei der Aktualisierung (Update mit dem gleichen Wert) Events erzeugt (Default Verhalten). Sobald jedoch eines der beiden Attribute gesetzt ist, müssen alle Readings, die protokolliert werden sollen, bei (mindestens) einem der Attribute berücksichtigt sein.
 Ist für ein Reading sowohl ''event-on-change-reading'' als auch ''event-on-update-reading'' spezifiziert, wird bei jeder Aktualisierung des Readings ein Event erzeugt, das ''event-on-change'' wird für dieses Reading also außer Kraft gesetzt bzw. "überstimmt".
-Eine Zusammenfassung aus {{Link2Forum|Topic=26694|Message=196955|LinkText=diesem Forenbeitrag}}:
-;Update + Min-Interval
-:ein Event wird erzeugt, wenn der selbe Wert, der bereits im Reading steht, nochmal reingeschrieben wird '''und''' mindestens ''min-interval'' Sekunden seit dem letzten Event vergangen sind
-;Change
-:ein Event wird erzeugt, wenn der neue Wert wirklich abweichend vom alten Wert ist '''oder''' mindestens ''min-interval'' Sekunden seit dem letzten Event vergangen sind.
-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)).
 == timestamp-on-change-reading ==
 Ist nur event-on-change-reading für ein Reading spezifiziert, entfällt zunächst einmal nur der Trigger, der Zeitstempel wird weiter aktualisiert. Benötigt man jedoch den Zeitstempel der letzten Änderung (z.B. die Ein- oder Ausschaltzeit eines Relais), kann man mithilfe von ''timestamp-on-change-reading'' auch die Aktualisierung des Zeitstempels unterbinden, falls der Wert sich nicht geändert hat.
-== Beispiele ==
+== Beispiel ==
-Um alle Readings eines Gerätes nur bei Änderungen zu protokollieren, sollte das Attribut folgendermaßen gesetzt werden:
+In einer einfachen Anwendung kann, um alle Readings eines Gerätes nur bei Änderungen zu verarbeiten, das Attribut folgendermaßen gesetzt werden:
 :<code><nowiki>attr <device> event-on-change-reading .*</nowiki></code>
+Zusätzlich kann mit
+:<code><nowiki>attr <device> event-min-interval .*:3600</nowiki></code>
+dafür gesorgt werden, dass jede Stunde auch ohne Werteänderung die Readings dennoch verarbeitet werden, also in z.b. in das Logfile geschrieben werden (findet FHEM zu wenige Ereignisse pro betrachteter Zeitspanne, bleiben Graphen leer oder werden nur teilweise gezeichnet (Plotabriss)).
+Das obige Kombination der Attribute führt also dazu, dass ein Event erzeugt wird, wenn der neue Wert wirklich abweichend vom alten Wert ist '''oder''' mindestens ''min-interval'' Sekunden seit dem letzten Event vergangen sind.
+Achtung: dies löst wie oben beschrieben ggf. Konstrukte wie <code><nowiki>… notify GeraetXXXX:wert …</nowiki></code> aus.
-Shelly1-pm als MQTT2_DEVICE und aktiviertem ''statistics''-Modul für Verbrauchsdaten:
+Falls ein Reading namens "unwanted" KEINE Events erzeugen soll, lässt sich das mit
+:<code><nowiki>attr <device> event-on-change-reading (?!unwanted).*</nowiki></code>
+unterdrücken.
- defmod Muster_Shelly1pm MQTT2_DEVICE shelly1pm_123456789012
+Wenn KEIN Event bei einem Gerät erzeugt werden soll, lässt sich das mit
- attr Muster_Shelly1pm event-on-change-reading state,temperature:0.2,online,loadState,overtemperature,Verbrauch_Total_kWh,relay_0_.*,relay0,input0
+:<code><nowiki>attr <device> event-on-change-reading $</nowiki></code>
- attr Muster_Shelly1pm event-on-update-reading stat[ERT].*
+erreichen.
- attr Muster_Shelly1pm readingList shellies/shelly1pm-123456789012/relay/0:.* state\
-   shellies/shelly1pm-123456789012/relay/0:.* relay0\
+Um ein Threshold für nur ein Reading zu setzen:
-   shellies/shelly1pm-123456789012/input/0:.* input0\
+:<code>attr <device> event-on-change-reading Temp.*:0.4,.*</code>
-   shellies/shelly1pm-123456789012/online:.* online\
+Alle Readings, die mit Temp beginnen, erzeugen nur ein Event, wenn die Änderung >0.4 Grad ist. Alle anderen Readings erzeugen bei jeder Änderung ein Event.
-   shellies/shelly1pm-123456789012/announce:.* { json2nameValue($EVENT) }\
-   shellies/shelly1pm-123456789012/relay/0/power:.* relay_0_power\
+Nur ein Reading mit Threshold berücksichtigen:
-   shellies/shelly1pm-123456789012/relay/0/power:.* { my $compare = $EVTPART0 < 100 ? "off":"on";; ReadingsVal($NAME,"loadState","off") ne $compare ? { 'loadState' => $compare } : return }\
+:<code><nowiki>attr <device> event-on-change-reading Temp.*:0.4</nowiki></code>
-   shellies/shelly1pm-123456789012/temperature:.* temperature\
+Alle Readings, die mit Temp beginnen, erzeugen nur ein Event, wenn die Änderung >0.4 Grad ist. Alle anderen Readings erzeugen keine Event, auch nicht bei Werteänderung.
-   shellies/shelly1pm-123456789012/overtemperature:.* overtemperature\
-   shellies/shelly1pm-123456789012/relay/0/energy:.* relay_0_energy\
+Mit [[event-on-update-reading]] und [[event-min-interval]] kann das Verhalten verfeinert werden.
-   shellies/shelly1pm-123456789012/relay/0/energy:.* {'relay_0_kWh' => sprintf("%.2f",$EVENT/60/1000)}\
-   shellies/shelly1pm-123456789012/longpush/0:.* longpush_0\
-   shellies/shelly1pm-123456789012/temperature_f:.* {}\
-   shellies/shelly1pm-123456789012/input_event/0:.* { json2nameValue($EVENT) }
- attr Muster_Shelly1pm setList relay0:on,off,toggle shellies/shelly1pm-123456789012/relay/0/command $EVTPART1\
-   off:noArg shellies/shelly1pm-123456789012/relay/0/command off\
-   on:noArg shellies/shelly1pm-123456789012/relay/0/command on\
-   x_update:noArg shellies/shelly1pm-123456789012/command update_fw\
-   x_mqttcom shellies/shelly1pm-123456789012/command $EVTPART1
- attr Muster_Shelly1pm setStateList on off
- attr Muster_Shelly1pm timestamp-on-change-reading state,online,loadState,overtemperature
- attr Muster_Shelly1pm userReadings relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum("$name","relay_0_energy",0)}, Verbrauch_Total_kWh:relay_0_kWh:.* monotonic {ReadingsNum("$name","relay_0_kWh",0)}
 == Siehe auch ==
+*{{Link2Forum|Topic=26694|Message=196955|LinkText=Forenbeitrag}}
 *[[event-on-update-reading]]
 *[[event-min-interval]]
 *[[event-aggregator]]
-== Links ==
 * Benutzungstipps (''Best Practice'') für das Attribut in {{Link2Forum|Topic=36522|LinkText=diesem Forenthread}}
 [[Kategorie:Attribut (allgemeingültig)]]