HMInfo vs. event-on-change-reading

[martinp876]

- wenn ich die beiden readings so lösche (klappt, hab nachgesehen, sind weg) und event-on-change-reading .* für hminfo gesetzt habe, kommt korrekterweise:

gut - haben sich geändert, trigger kommt

- readings nochmal so löschen; jetzt vorher event-on-change-reading auf .*overload.* gesetzt:

gut - haben sich geändert, trigger kommt

- das gleiche nochmal mit event-on-change-reading overload - also direkt den reading-namen, ohne regex:

auch gut.
In allen 3 Fällen haben sich die Readings geändert - und mussten einen trigger auslösen - das haben sie.

Event-on-change-reading hättest du auch weglassen können. Das filtert nur Events, wenn sich NICHTS ändert. Es ist ein
Event-only-if-there-is-a-change-in-the-reading.
oder
No-Event-if-reading-does-not-change-its-value

Ist wohl also echt das Anlegen des Readings!?

verstehe ich nicht - sind doch alle gekommen, wie sie sollten. Und Angelegt wurde immer, was ein "change" ist.

Sehen kannst du etwas wenn du

attr system.hminfo event-on-change-reading .*
{delete $defs{"system.hminfo"}{READINGS}{ERR_overheat};;return ""}
{delete $defs{"system.hminfo"}{READINGS}{ERR_overload};;return ""}
set system.hminfo update

=> Trigger kommen

jetzt noch einmal (keine Änderung)

set system.hminfo update

=> kein Trigger


Gruss Martin

[peterk_de]

Jut. Dann ist mir jetzt die Wirkung von event-on-change-reading hoffentlich im Detail klar:

1. Wenn sich ein Reading ändert, dass auf keinen Regex im event-on-change-reading Attribut matcht, wird kein Event erzeugt. --> so isses beim Dimmer
2. Wenn ein Reading neu angelegt wird, dass auf keinen Regex im event-on-change-reading Attribut matcht, wird ein Event erzeugt. --> wie bei HMInfo gesehen

Wenn mans weiß ist das gut und kann es in Notifies etc. berücksichtigen ^^

[peterk_de]

OK das gehört nun nicht mehr wirklich hier her sondern eher in FHEM allgemein aber ich konnte das mittels eines Dummys tatsächlich so reproduzieren:

Code Auswählen Erweitern


define test DUMMY
attr test event-on-change-reading temp
{readingsSingleUpdate($defs{"test"},"temp","1",1)} --> Event kommt
{readingsSingleUpdate($defs{"test"},"hum","1",1)} --> Event kommt
{readingsSingleUpdate($defs{"test"},"hum","2",1)} --> Event kommt nicht


Martin, kann man das Bug nennen?

[martinp876]

Martin, kann man das Bug nennen?

hätte ich schon gesagt - aber man kann ja im Commandref nachlesen. Die Semantik hat sich m.E. geändert. Evtl um erreichen zu könnnen, dass man auch Events abschalten kann. Das geht jetzt implizit - und daher auch die Änderung.
Aber lesen bildet

1    If both attributes are not set, any update of any reading of the device creates an event.
2    If any of the attributes is set, no events occur for updates or changes of readings not listed in any of the attributes.
3    If a reading is listed in event-on-update-reading, an update of the reading creates an event no matter whether the reading is also listed in event-on-change-reading.

Alle Trigger bei jeden Update

Code Auswählen Erweitern

deleteattr test event-on-change-reading .*
deleteattr test event-on-update-reading .*
oder

Code Auswählen Erweitern

attr test event-on-update-reading .*

Alle Trigger nur bei Änderung

Code Auswählen Erweitern

attr test event-on-change-reading .*

Alle Trigger bei Änderung, nur xxx bei Update

Code Auswählen Erweitern

attr test event-on-change-reading .*
attr test event-on-update-reading xxx

Alle Trigger bei update, nur xxx bei Änderung ist schwierig. Must du einmal selbst testen.

Code Auswählen Erweitern

???

Keine Trigger (unterdrücke andere) ausser xxx bei update und yyy bei change

Code Auswählen Erweitern

attr test event-on-change-reading yyy
attr test event-on-update-reading xxx