event-on-update-reading

Aus FHEMWiki
Zur Navigation springen Zur Suche springen


Mit dem Attribut event-on-update-reading kann für Readings eines Gerätes festgelegt werden, dass bei jeder Aktualisierung ein Event (und damit in der Regel auch ein Log-Eintrag) erzeugt werden soll. Da dies das Defaultverhalten von FHEM ist, ist event-on-update-reading nur dann sinnvoll einsetzbar, wenn das Defaulverhalten vorher mit dem Attribut event-on-change-reading eingeschränkt wurde.

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


Einführung

FHEM erzeugt für jedes gemeldete Reading ein Event, egal, ob das Reading sich geändert hat, oder nur Intervallweise per Update aktualisiert wurde. Dieses Verhalten kann Nachteile haben und daher mit event-on-change-reading für ein Gerät abgestellt werden.

event-on-update-reading dient nun dazu, für einzelne Readings des Gerätes das Defaultverhalten wieder herzustellen, sollte es für bestimmte Readings in einer gegeben FHEM Installation sinnvoll sein, doch bei jedem Update auch ohne Werteänderung ein Event zu erhalten. Dies kann z.b. bei der Erzeugung von Graphen notwendig sein.


Syntax

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

attr <device> event-on-update-reading reading1[,reading2...n]

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

Wechselwirkungen

Dieses Attribut steht in Wechselwirkung mit den Attributen event-on-change-reading und event-min-interval, bitte beim Einsatz berücksichtigen. Ein Einsatz ohne gleichzeitige event-on-change-reading ist idR. nicht sinvoll.

Sind bei einem Device weder event-on-update-reading noch event-on-change-reading spezifiziert, werden für alle Readings sowohl bei Aktualisierung (mit dem gleichen Wert) als auch bei der Änderung Events erzeugt, dies ist das Defaulverhalten. 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".

Beispiele

Hat man durch

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

erreicht, dass alle Readings des Gerätes nur noch bei Werteänderung eine Event erzeugen (und somit auch nur bei Werteänderung geloggt werden), kann mit

attr <device> event-on-update-reading temperature, humidity

dafür gesorgt werden, das Temperatur und Luftfeucht dennoch mit jedem Update (intervallweise Aktualisierung auch ohne Werteänderung) ein Event erzeugen und geloggt werden.

Praktische Anwendung

Da mit event-min-interval ebenfalls dafür gesorgt werden kann, dass Readings auch ohne Werteänderungen ein Event erzeugen, muss beim Einsatz geprüft werden, ob event-min-interval nicht sinnvoller als event-on-update-reading ist. Da die Updateintervalle einiger Geräte recht kurz sind, kann der Einsatz event-on-update-reading immer noch sehr viele (ggf nutzlose) Events für das gegebene Reading erzeugen.

Siehe auch

Links