event-on-change-reading
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.
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.
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
event-on-change-reading .*
Dies führt dazu, dass alle Readings noch Events erzeugen, aber nur wenn diese sich im Wert ändern.
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!
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.
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 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
Um alle Readings eines Gerätes nur bei Änderungen zu protokollieren, sollte das Attribut folgendermaßen gesetzt werden:
attr <device> event-on-change-reading .*
Shelly1-pm als MQTT2_DEVICE und aktiviertem statistics-Modul für Verbrauchsdaten:
defmod Muster_Shelly1pm MQTT2_DEVICE shelly1pm_123456789012 attr Muster_Shelly1pm event-on-change-reading state,temperature:0.2,online,loadState,overtemperature,Verbrauch_Total_kWh,relay_0_.*,relay0,input0 attr Muster_Shelly1pm event-on-update-reading stat[ERT].* attr Muster_Shelly1pm readingList shellies/shelly1pm-123456789012/relay/0:.* state\ shellies/shelly1pm-123456789012/relay/0:.* relay0\ shellies/shelly1pm-123456789012/input/0:.* input0\ shellies/shelly1pm-123456789012/online:.* online\ shellies/shelly1pm-123456789012/announce:.* { json2nameValue($EVENT) }\ shellies/shelly1pm-123456789012/relay/0/power:.* relay_0_power\ shellies/shelly1pm-123456789012/relay/0/power:.* { my $compare = $EVTPART0 < 100 ? "off":"on";; ReadingsVal($NAME,"loadState","off") ne $compare ? { 'loadState' => $compare } : return }\ shellies/shelly1pm-123456789012/temperature:.* temperature\ shellies/shelly1pm-123456789012/overtemperature:.* overtemperature\ shellies/shelly1pm-123456789012/relay/0/energy:.* relay_0_energy\ 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
Links
- Benutzungstipps (Best Practice) für das Attribut in diesem Forenthread