event-on-change-reading .* notwendig

Begonnen von Det20, 20 Februar 2022, 18:39:13

Vorheriges Thema - Nächstes Thema

Det20

Hallo,

ich habe mal ne ziemlich einfache Frage. Ist "event-on-change-reading .*" gleichbedeutend mit weglassen? Kann ich es mir also schenken und so ggf Ressourcen sparen? Habe das immer definiert, weil ich 'irgendwann mal irgendwo' gelesen habe, dass man das so macht. Nur, ist das wirklich notwendig?

VG

Benni

https://fhem.de/commandref_DE.html#attributes

Zitat
event-on-update-reading
Wenn nicht gesetzt, erzeugt jede Veränderung eines "readings" ein Ereignis, welches z.B. von notify oder FileLog berücksichtigt wird. Wenn gesetzt erzeugen nur Aktualisierungen der eingetragenen "readings" ein Ereignis.

event-on-change-reading
Dieses Attribut enthält eine durch Kommata getrennte Liste von "readings". Wenn gesetzt, erzeugen nur Veränderungen der gelisteten "readings" ein Ereignis. Wenn die aktualiserten Werte der gelisteten "readings" identisch sind, wird kein Ereignis generiert.
Wenn hinter dem Namen eines "readings" eine :Schwelle angegeben ist, wird das Event nur getriggert wenn die Änderung grösser als diese Schwelle ist.
Die unterschiedlichen Bedeutungen von event-on-update-reading und event-on-change-reading sind folgende:

  • Wenn beide Attribute nicht gesetzt sind erzeugt jede Aktualisierung eines jeden "readings" eines Gerätes ein Ereignis.
  • Wenn eines der Attribute gesetzt ist, erzeugen nur Updates oder änderungen von "readings" die in einem der Attribute gesetzt sind ein Ereignis.
  • Wenn ein "reading" in event-on-update-reading aufgeführt ist, erzeugt eine Aktualisierung ein Ereignis unabhängig ob das "reading" auch in event-on-change-reading aufgelistet ist.

Die Empfehlung event-on-change-reading generell auf .* zu setzen, zielt also darauf ab, die Systemlast durch auftretende Events zu reduzieren. Es werden dann nämlich nur Events zu readings erzeugt, wenn sich deren Wert geändert hat. Andernfalls wird für jede Aktualisierung eines Readings ein Event erzeugt egal, ob sich der Wert nun geändert hat oder nicht. (Es sei denn das ist durch event-on-update-reading eingeschränkt)

Per default sind beide Attribute nicht gesetzt und somit erzeugt quasi jede Reading-Aktualisierung auch ein event.

Besser ist es natürlich die Attribute so zu setzen, dass nur die Events zu Readings erzeugt werden, die auch tatsächlich benötigt werden.

gb#

betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Det20

Der Raspberry eiert eh schon am Limit, also lass ich das alles drin.
Vielen lieben Dank euch!

Beta-User

Zitat von: Det20 am 20 Februar 2022, 19:36:25
Der Raspberry eiert eh schon am Limit
Dann solltest du dich aber vertiefter mit den Ursachen befassen! Z.B. bei Sensoren, die häufig leicht schwankende Werte liefern, ist das Attribut mit .* vielleicht nicht optimal gesetzt und/oder man "braucht" weitere aus der "eocr-Familie"... (Ja, ist eine subjektive Bewertungsfrage ::) ).

M.E. allgemein ganz guter Einstieg: https://forum.fhem.de/index.php/topic,117075.0.html

Falls du CUL_HM im Einsatz hast, gibt es z.B. hier ein Attribut, das du setzen solltest: https://forum.fhem.de/index.php/topic,125930.msg1205833.html#msg1205833, interessant ist eventuell auch der folgende Beitrag von Benni und der Link da...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Sany

ZitatZitat von: Benni am Gestern um 18:50:17

    Besser ist es natürlich ...

Zitat von: betateilchen am 20 Februar 2022, 19:23:19
kann man glauben, muss man aber nicht.

wie meinst Du das?
fhem als LXC auf Proxmox auf einem minix Z100 , weitere LXC mit ZigBee2MQTT, MariaDB und Grafana. Homematic, FS20, mySensors, MQTT2, Tasmota, Shelly, Z-Wave  ....