Am 13. Januar hatte ich einen 4fach-Zigbee-Taster in FHEM eingebunden (MQTT).
```
Readings
IODev mqttBroker
Kaminzimmer4fachTaster_action 3_double
...
Kaminzimmer4fachTaster_battery 100
availability online
```
Mittels notify habe ich das einzige relevante Reading abgefragt (Kaminzimmer4fachTaster_action).
Es hat auch grundsätzlich das getan, was ich erwartet habe. Nur war der Schalter unerwartet zickig.
Aus heiterem Himmel ging plötzlich das Licht an oder aus.
Zuerst hatte ich das manchmal sehr langsame abarbeiten im Verdacht.
Aber dann war es plötzlich unerwartet einfach und ich habe zum ersten Mal das Attribut "event-on-change-reading" begriffen.
Diesem Attribut habe ich das Reading "Kaminzimmer4fachTaster_action" zugewiesen (siehe Readings-Auszug oben). Und schon verhielt sich die Zicken-Biene nicht mehr zickig.
Was macht das Attribut?
Nun, es sorgt dafür, dass nur dann ein Event ausgelöst wird, wenn sich das Reading wirklich (!) ändert. Notify war ja auf genau das Reading angesetzt. Sprich: wenn sich das Reading ändert, soll die im Notify programmierte Funktion abgearbeitet werden (Kurzgefasst, das jeweilige Licht an- oder ausschalten)
Jetzt ist der Taster Batteriebetrieben. Das bedeutet, er geht regelmäßig in den Energiesparmodus. Und jedesmal wenn er aufwacht und die Readings per MQTT übermittelt, glaubt das notify: "Oh, eine Änderung, dann leg ich jetzt los". Und schaltet das Licht aus, wenn es an war oder umgekehrt.
Und hier kommt das gesetzte Attribut ins Spiel: Jetzt wird das notify-Event nur noch ausgelöst, wenn sich das Reading WIRKLICH ändert. Ein Aufwachen aus dem Sleep-Modus löst damit kein notify-relevantes Event mehr aus.
Der Spuk ist vorbei.
