Hallo zusammen,
im Zusammenhang mit der Diskussion hier https://forum.fhem.de/index.php/topic,125831.0.html (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
attr <Gerät> event-ignore .*
lieber als ein Einschalter, der nur etwas nicht vorhandenes einschaltet wie
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 (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
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? 8)
Gruß, Joachim
Danke für Deine Antwort!
Zitat von: MadMax-FHEM am 04 Februar 2022, 19:33:01
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
Zitat von: alanblack am 04 Februar 2022, 19:05:25
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#
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 :) .
Zitat von: Benni am 04 Februar 2022, 22:40:32
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!".
Zitat
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!
Zitat von: Beta-User am 05 Februar 2022, 06:24:44
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
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
Zitat von: herrmannj am 05 Februar 2022, 15:46:43
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.
ZitatAuf 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
Zitat von: alanblack am 05 Februar 2022, 17:26:15
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.
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.
Zitat von: frank am 05 Februar 2022, 17:38:31
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
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
attr ... event-on-change-reading battery,state setzen. Also alle Readings einzeln auflisten ohne die nicht mehr erwünschten.
Grüße
Noch jemand Popcorn?
Zitat von: betateilchen am 05 Februar 2022, 18:08:53
Noch jemand Popcorn?
Ja, ich!
Ich bin mal von dem Schlauch runtergegangen:
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
Zitat von: alanblack am 05 Februar 2022, 18:28:25
wie muss der Filter aussehen, der exakt auf die Zeichenfolge ".*" matcht?
\.\*
Ich habe dies und "kein Event vom Device" mal als Beispiele ins Wiki eingetragen.
Danke an alle!
Grüße
nur zur info: die hue module erzeugen (fast) nur events für readings die sich tatsächlich geändert haben. d.h. irgendwelche event-on-change-reading klimmzüge kann man sich meist sparen.