Events beschränken und "event-on-.* ist nicht soo billig"

[Ellert]

@rudolfkoenig: Ich möchte Deinen Hinweis aufgreifen https://forum.fhem.de/index.php/topic,62998.msg556509.html#msg556509

Bisher glaubte ich "event-on-.*" ist das Nonplusultra der Event-Beschränkung.

Wenn die "event-on-.*" Attribute das System signifikant belasten, so würde ich "nicht billig" deuten, sollten Modulautoren, deren Module eine große Anzahl Events am Tag erzeugt, eine Möglichkeit schaffen, die Events auf Benutzerwunsch im Modul zu beschränken, statt sich auf die Möglichkeit mit dem Attribut "event-on-.*" zu stützen?

Spontan fällt mir z.B. das Modul PROPLANTA ein, das 233 Events/Aktualisierung erzeugt, mit "forecastDays 4".

[rudolfkoenig]

Bisher glaubte ich "event-on-.*" ist das Nonplusultra der Event-Beschränkung.

Bitte meine Aussage nicht aus dem Kontext nehmen. Da ging es darum, dass DbLog bei jedem Event ein weiteres Event generiert, was wiederum per event-on* deaktiviert werden soll. Ich habe keine Zahlen, aber fuer jedes event-on-* Attribut werden bei der event-on-* Filterung etliche splits/greps/regexp-checks durchgefuehrt, und das fuer jedes Event. Falls jemand 500+ notifies hat (ja, das gibt es), dann ist definitiv billiger mit event-on-* die Events zu filtern, falls jemand nur ein notify hat, dann teurer. Wo das break-even ist, weiss ich nicht.

Wenn diese Filterung jeder Modulautor selber macht, dann wird es dadurch auch nicht schneller.

Eher sollte man darueber nachdenken, dass man per Voreinstellung nur die von jedem erwarteten Events generiert, und "unsinnige" (politisch korrekt: nicht fuer alle immer nuetzliche) Events nur auf extra Bestellung, z.Bsp. per Attribut, aktiviert werden.

[Thorsten Pferdekaemper]

Eher sollte man darueber nachdenken, dass man per Voreinstellung nur die von jedem erwarteten Events generiert, und "unsinnige" (politisch korrekt: nicht fuer alle immer nuetzliche) Events nur auf extra Bestellung, z.Bsp. per Attribut, aktiviert werden.

Wie bekommt man so etwas abwärtskompatibel hin? Ich würde mal davon ausgehen, dass wenn man ein Event per Default abschaltet, dass es dann mindestens eine Installation gibt, die sich auf genau dieses Event verlassen hat.
Gruß,
   Thorsten

[Ellert]

@rudolfkoenig:

Eher sollte man darueber nachdenken, dass man per Voreinstellung nur die von jedem erwarteten Events generiert, und "unsinnige" (politisch korrekt: nicht fuer alle immer nuetzliche) Events nur auf extra Bestellung, z.Bsp. per Attribut, aktiviert werden.

Das meinte ich mit:

eine Möglichkeit schaffen, die Events auf Benutzerwunsch im Modul zu beschränken

@Thorsten Pferdekaemper:
Bei bestehenden Modulen könnte man lassen wie es ist und zusätzlich abschaltbar machen.

Da DbLog überarbeitet wird, sind die neuen Events einschaltbar.

[rudolfkoenig]

@Thorsten:
1. Ankuendigen und Attribut beim define explizit setzen, dass man es leicht merkt/aendern kann.
2. Eine Methode finden, "alte" Installationen von Neuen zu unterscheiden, z.Bsp. weil per autocreate anders angelegt ist, usw. Dann je nach Typ das default anders waehlen.

Vielleicht faellt Anderen was eleganteres ein, ganz zufrieden bin ich mit diesen Vorschlaegen auch nicht.