event-ignore möglich?

[alanblack]

Hallo zusammen,

im Zusammenhang mit der Diskussion hier https://forum.fhem.de/index.php/topic,125831.0.html ist mir eine unerledigte Baustelle in meinem FHEM eingefallen. Die einfachste Lösung wäre ein "event-ignore"-Attribut - welches aber leider aktuell nicht gibt. Zumindest habe ich bisher nichts in der Richtung gefunden.

Das "event-ignore"-Attribut sollte - in der Art von event-on-change-reading - wenn gesetzt, Events für passende Readings komplett verhindern.

Vielleicht gibt es auch eine ganz andere Art, das zu lösen?!?! Auch ist mir ein ein echter Ausschalter mit

Code Auswählen Erweitern

attr <Gerät> event-ignore .*
lieber als ein Einschalter, der nur etwas nicht vorhandenes einschaltet wie

Code Auswählen Erweitern

attr <Gerät> event-on-change-reading $

Hintergrund ist das lastseen-Reading. Die Diskussion darum mit der nicht so schönen Lösung hier https://forum.fhem.de/index.php/topic,95288.msg1091903.html#msg1091903 habe ich gelesen. Zum einen gibt es HUEDevices, welche kein lastseen-Reading haben. Da wäre es unsinnig. Dann habe ich schon bei einigen event-on-change-reading manuell auf genaueres als .* gesetzt. Das würde überschrieben.

Ich war versucht, das Thema im Zigbee-Bereich zu posten. es hätte mir bei der Optimierung der bei Geräten mit state der Art "T: 20° H:49%" und Co. das Leben auch schon vereinfacht. Diese habe ich schon alle manuell im eocr "entfernt".

Danke im Voraus!

Grüße

[MadMax-FHEM]

Wenn du in event-on-change-reading nur Readings aufnimmst, von denen du Events willst, dann bekommst du auch nur von denen Events...
...von allen anderen nicht.

Und von denen auch nur bei Änderung.

EDIT: du kannst dort also auch "Quatsch" angeben, dann bekommst du erst mal keine Events

Wenn du auch Events willst, wenn sich der Wert nicht geändert hat: event-on-update-reading

EDIT: ja nicht genau was du willst, also ein "extra"/"eigenes" Attribut aber der UseCase geht doch?

Gruß, Joachim

[alanblack]

Danke für Deine Antwort!

Wenn du in event-on-change-reading nur Readings aufnimmst, von denen du Events willst, dann bekommst du auch nur von denen Events...
...von allen anderen nicht.

Das habe ich bei Geräten mit state der Art "T: 20° H:49%" und Co. so gemacht. War auch recht überschaubar, weil die dann je nach Model mit eocr="battery,temperature,humidity" oder ähnlichem schnell geändert waren. Zudem waren es nur gut 20 Stück.

Hier sind knapp 180, bei denen ich blöderweise schon über 30 aus anderen Gründen manuell gepflegt habe. Die würde ich mit einem attr TYPE=HUEDevice überschreiben.

Auch sind bspw. HUE-Lampen teilweise ziemlich verschwenderisch im Umgang mit Readings: "bri, ct, hue, onoff, pct, rgb, sat, state".

Ich habe halt nur nicht wirklich Lust den Rest von ~150 Geräten einzeln oder in kleinen Gruppen zu pflegen, nur weil ich zu spät über das 2020 eingeführte lastseen gestolpert bin.

Ich bin mit den vielen Geräten mit event-on-change, on-update (beide mit threshold), min-interval und aggregator ziemlich detailiert eingestellt.

Grüße

[Benni]

Die einfachste Lösung wäre ein "event-ignore"-Attribut - welches aber leider aktuell nicht gibt.

Das wäre ja einfach nur eine Umkehrung von eocr. Und das zusätzlich würde es nicht einfacher machen!

Vielleicht ist ja auch die intelligente Vorlagenverwaltung (++) mittels archetype ein möglicher Ansatz für dich.
Dort ist jeder Tester sicher gerne gesehen

https://forum.fhem.de/index.php/topic,125930.msg1205212.html#msg1205212

gb#

[Beta-User]

Nicht getestet, aber es ist eine Regex. Von daher könnte auch sowas wie (?!unwanted) gehen.

ABER: Viele triggernde Readings bedeuten noch lange nicht, dass für jedes auch die Eventverarbeitung _separat_ aufgerufen wird. Werden mehrere vom Modul auf einmal aktualisiert ("bulk"), spielt es nicht mehr die große Rolle, wenn eine Event-loop ausgelöst wird, ob es nun (übertrieben gesagt) 1, 5 oder 20 Readings sind, die zusammen verteilt werden.

Tester für archetype sind aber selbstredend trotzdem willkommen .

[alanblack]

Das wäre ja einfach nur eine Umkehrung von eocr. Und das zusätzlich würde es nicht einfacher machen!

Ich sehe ein, dass für viele Benutzer von FHEM die vorhandenen Mittel um eocr schon schwierig zu verstehen und um so schwieriger sinnvoll zu nutzen sind. Dennoch könnte es für manche derer auch mit einem event-ignore einfacher sein. "Du hast zu viele Events im EventLog? Schreib die, welche Du nicht brauchst in event-ignore!".

Vielleicht ist ja auch die intelligente Vorlagenverwaltung (++) mittels archetype ein möglicher Ansatz für dich.
Dort ist jeder Tester sicher gerne gesehen

https://forum.fhem.de/index.php/topic,125930.msg1205212.html#msg1205212

gb#

Ich hatte archetype schon mal gelesen aber nicht wirklich verstanden, was das Modul tut. In diesem Kontext habe ich es noch zweimal gelesen und habe jetzt zumindest eine Idee. Das könnte in der Tat helfen - nicht "mal eben schnell bei lastseen" aber langfristig. Thx!

ABER: Viele triggernde Readings bedeuten noch lange nicht, dass für jedes auch die Eventverarbeitung _separat_ aufgerufen wird. Werden mehrere vom Modul auf einmal aktualisiert ("bulk"), spielt es nicht mehr die große Rolle, wenn eine Event-loop ausgelöst wird, ob es nun (übertrieben gesagt) 1, 5 oder 20 Readings sind, die zusammen verteilt werden.

Es geht ja nicht um viele triggernde Readings, sondern um EIN Reading lastseen, das an vielen Devices getriggert wird. Wenn ich das Eventlog neben "top" lege, gibt es immer wieder Blöcke von 5-20 Events "lastseen" und jedes Mal steigt die von fhem.pl erzeugte Last um 20-50%.

Grüße

[herrmannj]

Dann beseitige die Ursachen. Wenn bei 20 Events sowas passiert hast du ganz andere Probleme. Auf einer vernünftigen Installation schafft man locker vierstellig pro Sekunde. Jedes Attribut zusätzlich macht alles langsamer. Prüfe deine notify, deine DOIF, whatever

[alanblack]

Dann beseitige die Ursachen. Wenn bei 20 Events sowas passiert hast du ganz andere Probleme. [... ] Prüfe deine notify, deine DOIF, whatever

Notify und Watchdog: geprüft und bis auf sieben optimiert
DOIF: nicht vorhanden
eocr und Co.: nahe an "nur Events, die sichtbar sind, geloggt oder programmatisch verarbeitet werden sollen"
presence: minimiert
attr global verbose 5 mal eine halbe Stunde laufen lassen: finde im Log nichts auffälliges

aktuell kosten nur das Unify-Device und die lastseen-events nennenswert Rechenzeit - alles andere dümpelt bei 2-5%CPU rum.

Auf einer vernünftigen Installation schafft man locker vierstellig pro Sekunde. Jedes Attribut zusätzlich macht alles langsamer.

Da würde mich interessieren, was "eine vernünftige Installation" ausmacht?

Und ich habe nur gefragt, ob es eine Möglichkeit gibt, bei ~150 Devices Events auf ein Reading mit dem Namen "lastseen" zu verhindern. Die Beschreibung eines hypothetischen Attributs "event-ignore" diente nur der Verdeutlichung.
Leider hilft es ja bei den aktuell verfügbaren Attributen nicht, "lastseen" irgendwo anzuhängen; wenn doch würde ich das sofort auch manuell machen.
Ich war auch schon versucht, mal "deletereading TYPE=HUEDevice lastseen" auszuprobieren, ob das nennenswerten Schaden anrichtet.

Grüße

[betateilchen]

Ich war auch schon versucht, mal "deletereading TYPE=HUEDevice lastseen" auszuprobieren, ob das nennenswerten Schaden anrichtet.

Da wird durch das Löschen nix schlimmes passieren. Aber wenn das reading das nächste Mal vom device aktualisiert wird, ist das reading halt wieder da.

[frank]

wenn das reading lastseen trigger erzeugt, obwohl es in deinen event attributen nicht explizit genannt wird, wodurch es implizit ausgeschlossen sein sollte, funktioniert es scheinbar nach einem anderen mechanismus.

oder ich habe das problem immer noch nicht durchschaut.

[alanblack]

wenn das reading lastseen trigger erzeugt, obwohl es in deinen event attributen nicht explizit genannt wird, wodurch es implizit ausgeschlossen sein sollte, funktioniert es scheinbar nach einem anderen mechanismus.

Nee, soweit ist das "FHEM-technisch" alles i.O. Ich hatte bei vielen Devices

Code Auswählen Erweitern

attr ... event-on-change-reading .* gesetzt, weil dadurch die Events wegfallen wenn bspw. ein Reading auf "on" steht und mit "on" überschrieben wird. Es kommen mit event-on-change-reading=.* also weniger Events.
Wenn ich jetzt die Events von lastseen - bei dem sich der Wert (=Zeitstempel) jedes Mal ändert - loswerden möchte, müsste ich bspw. bei einem Device, welches die Readings "battery, state, lastseen" hat, ein

Code Auswählen Erweitern

attr ... event-on-change-reading battery,state setzen. Also alle Readings einzeln auflisten ohne die nicht mehr erwünschten.

Grüße

[betateilchen]

Noch jemand Popcorn?

[alanblack]

Noch jemand Popcorn?

Ja, ich!

Ich bin mal von dem Schlauch runtergegangen:

Code Auswählen Erweitern

attr TYPE=HUEDevice:FILTER=event-on-change-reading~.. event-on-change-reading (?!lastseen).*

Nebenbei gefragt: wie muss der Filter aussehen, der exakt auf die Zeichenfolge ".*" matcht?

Trotzdem hat die Idee von event-ignore für mich ihre Vorzüge.

Grüße

[betateilchen]

wie muss der Filter aussehen, der exakt auf die Zeichenfolge ".*" matcht?

\.\*

[alanblack]

Ich habe dies und "kein Event vom Device" mal als Beispiele ins Wiki eingetragen.

Danke an alle!

Grüße