NOTIFYDEV, Vorschlag für ein neues globales Attribut overrideNotifydev

[PatrickR]

Hallo zusammen,

angestoßen durch eine Diskussion im DOIF-Forum möchte ich einen Gedanken diskutieren.

NOTIFYDEV ist ein sehr mächtiges Instrument, um Ressourcen zu schonen. Von 206 Modulen mit NotifyFn setzen nur 136 NOTIFYDEV*. Bestimmte Module sind derart komplex, dass (anwendungsfallabhängig) ein NOTIFYDEV breiter ausfällt als es sein müsste.

Mein Vorschlag ist, dem Nutzer ein mächtiges Werkzeug an die Hand zu geben, um in den o. g. Fällen und unabhänging vom jeweiligen Modul ein "handoptimiertes" NOTIFYDEV zu setzen, z. B. in Form eines globalen Attributs overrideNotifydev.

Mir ist natürlich bewusst, dass man sich mit dem Attribut auch das Leben schwer machen kann, aber FHEM verfolgt ja sonst auch nicht das Ziel, Nutzer vor sich selbst zu schützen.

Patrick

* Wenn ich auf die Schnelle nicht falsch gegrept habe, was vermutlich der Fall ist

[rudolfkoenig]

Da ich befuerchte, dass damit "Experten" ein Modul auch kaputtkonfigurieren koennen (Upps, ich wusste gar nicht, dass das Modul Events vom global benoetigt), will ich noch weitere Stimmen fuer den Einbau hoeren.

[PatrickR]

Hallo Rudi,

Da ich befuerchte, dass damit "Experten" ein Modul auch kaputtkonfigurieren koennen (Upps, ich wusste gar nicht, dass das Modul Events vom global benoetigt), will ich noch weitere Stimmen fuer den Einbau hoeren.

ggf. könnte man den Zwischenweg gehen und global explizit hinzufügen.

[Beta-User]

Das erinnert mich etwas an die Diskussion zu "fhem 4 nerds.."

Prinzipiell finde ich die Idee auch nicht schlecht, fürchte aber auch den erwarteten support-Aufwand. Helfer sollten auf alle Fälle sehen können, was das Modul "eigentlich" gesetzt hätte, wenn man es nur gelassen hätte. Dann kann man das wenigstens vergleichen (falls die User sich die Mühe machen, die Internals zu zeigen...).

[xenos1984]

Für welche Module ist das denn überhaupt relevant? Sollten nicht die meisten der 206 Module, die NotifyFn setzen, am besten wissen, von wem sie Events empfangen wollen / müssen und von wem nicht? Es gibt sicher Beispiele wie DOIF oder notify, wo es praktisch ausschließlich vom Benutzer abhängt, welche Events dieses konkrete Device verarbeiten soll. Allerdings würde ich es dann vermutlich eher als Aufgabe des Moduls ansehen, NOTIFYDEV so allgemein wie nötig und so spezifisch wie möglich zu setzen.

[PatrickR]

Hi!

Für welche Module ist das denn überhaupt relevant? Sollten nicht die meisten der 206 Module, die NotifyFn setzen, am besten wissen, von wem sie Events empfangen wollen / müssen und von wem nicht?

Zumindest 70 Module scheinen keine Vorstellung davon zu haben. Ansonsten könnte man NOTIFYDEV auch setzen. Oder es wird einfach nicht als wichtig angesehen. Dass die Mehrzahl dieser Module aus gutem Grund den großvolumigen Eventschlauch abonniert, würde ich erstmal nicht annehmen.

Es gibt sicher Beispiele wie DOIF oder notify, wo es praktisch ausschließlich vom Benutzer abhängt, welche Events dieses konkrete Device verarbeiten soll. Allerdings würde ich es dann vermutlich eher als Aufgabe des Moduls ansehen, NOTIFYDEV so allgemein wie nötig und so spezifisch wie möglich zu setzen.

Ich gebe Dir - bezogen auf eine heile Welt - Recht. Das Problem ist m. E. aber, dass bei komplexen Modulen die automatische Ermittlung perfekt optimierter NOTIFYDEVs nicht einfach ist. Und der Lösung dieses Mammutproblems muss man erstmal eine entsprechende Priorität einräumen. Mit dem Attribut könnte man das Problem global erschlagen.

Patrick

[Beta-User]

Manche der 70 Module stammen vermutlich aus der Zeit vor der Einführung dieser Beschleunigung - vielleicht würde es reichen, entsprechende patches einzureichen, das würde das Problem für alle User zentral erledigen, ohne dass sich jeder einzelne User dazu separat Gedanken machen müßte.

Bei einem Teil (rund um CUL_HM) gibt es NOTIFYDEF (iVm. noch ein paar Würgarounds zur Erreichung der richtigen Reihenfolge) nur, weil die FHEM-Initialisierung keine explizite Phase "Alle Devices definiert, alle Readings und Attribute eingelesen, aber sonst ist noch nichts passiert" kennt.

Und viele, die (nur) auf "global"-Events reagieren, machen das vermutlich nur wegen der Initialisierung und könnten das genausogut über einen Timer lösen => patches welcome (?)...

[PatrickR]

Hi!

Manche der 70 Module stammen vermutlich aus der Zeit vor der Einführung dieser Beschleunigung - vielleicht würde es reichen, entsprechende patches einzureichen, das würde das Problem für alle User zentral erledigen, ohne dass sich jeder einzelne User dazu separat Gedanken machen müßte.

Das erschlägt aber immer noch nicht den Fall des Power Users, der gezielt optimieren möchte und kann.

Man kann auch beides tun. Als Gegenargument habe ich bislang korrekterweise lediglich gehört, dass Nutzer damit ihr FHEM verbiegen können, konkret: Im Worst Case schalten sie ein Device taub. Da kann man mit vielen anderen Bordmitteln von FHEM mehr kaputt machen. Ich glaube, richtig greifbar wird diese Gefahr nur, wenn das Attribut in irgendwelchen Yotube-Videos empfohlen wird.

Patrick

/Edit: Klarer ausgedrückt.

[rudolfkoenig]

[...] weil die FHEM-Initialisierung keine explizite Phase "Alle Devices definiert, alle Readings und Attribute eingelesen, aber sonst ist noch nichts passiert" kennt.

Und ich dachte, genau dann wird "global INITIALIZED" generiert, und die ersten Timer-Funktionen werden aufgerufen.

[Beta-User]

Hi!

Manche der 70 Module stammen vermutlich aus der Zeit vor der Einführung dieser Beschleunigung - vielleicht würde es reichen, entsprechende patches einzureichen, das würde das Problem für alle User zentral erledigen, ohne dass sich jeder einzelne User dazu separat Gedanken machen müßte.

Das erschlägt aber immer noch nicht den Fall des Power Users, der gezielt optimieren möchte und kann.

Klar.

Man kann auch beides tun. Als Gegenargument habe ich bislang korrekterweise lediglich gehört, dass Nutzer damit ihr FHEM verbiegen können, konkret: Im Worst Case schalten sie ein Device taub. Da kann man mit vielen anderen Bordmitteln von FHEM mehr kaputt machen. Ich glaube, richtig greifbar wird diese Gefahr nur, wenn das Attribut in irgendwelchen Yotube-Videos empfohlen wird.
Patrick

Na ja, wenn man in der Initialisierung von IO's was falsch macht, betrifft das uU. auch mehr als ein Device, und "kritischer" ist der Fall von "teil-Taubheit", weil das uU. auch für die Power-User schwer zu entdecken ist, vor allem dann, wenn sich nachträglich irgendwas ändert (insbesondere Umbenennungen sind da "heiße Favoriten").
Aber im Kern ist es richtig, das Gegenargument ist das "kaputt machen können" und (vor allem!) der dadurch erwartete Support-Aufwand (oder auch Frust).

Aber korrekt: das eine hat mit dem anderen nur bedingt was zu tun, wobei patches - da wo es sinvoll ist - ggf. eben der Weg wären, wie man das Thema für einzelne Module (vermutlich mehr wie die Hälfte der hier in den Raum geworfenen 70) bereits abgefrühstückt sein dürfte, weil schlicht auch für Power-User kein Optimierungsbedarf mehr bestünde...

Ansonsten haben wir nicht "immer" in der Hand, was in irgendwelchen Youtube-Videos so "angepriesen" (oder kritisiert) wird...

[...] weil die FHEM-Initialisierung keine explizite Phase "Alle Devices definiert, alle Readings und Attribute eingelesen, aber sonst ist noch nichts passiert" kennt.

Und ich dachte, genau dann wird "global INITIALIZED" generiert, und die ersten Timer-Funktionen werden aufgerufen.

Etwas genauer formuliert: Man ist zu diesem Zeitpunkt sicher, dass nicht bereits irgendein anderes Device auf dieses Event lauchst und dann _unkontrolliert_ bereits das eben gerade noch nicht fertig konfigurierte Modul nutzen will.

"global INITIALIZED" steht also nicht nur für "alle Infos da", sondern für "alles ist funktionsbereit". Und insbesondere CUL_HM&Co. braucht  eben genau die Phase unmittelbar VOR diesem Event, um die IO's fertig zu initialisieren...

[rudolfkoenig]

Vorschlag:
- das Attribut wird eingefuehrt und dokumentiert
- man muss es selbst durch "attr XXX userAttr" aktivieren, damit bleibt es etwas versteckt.
- falls vorhanden, dann wird es anstelle von $hash->{NOTIFYDEV} verwendet. Das vom Modul gesetzte NOTIFYDEV ist weiterhin sichtbar, aber wirkungslos.

[PatrickR]

Vorschlag:
- das Attribut wird eingefuehrt und dokumentiert
- man muss es selbst durch "attr XXX userAttr" aktivieren, damit bleibt es etwas versteckt.
- falls vorhanden, dann wird es anstelle von $hash->{NOTIFYDEV} verwendet. Das vom Modul gesetzte NOTIFYDEV ist weiterhin sichtbar, aber wirkungslos.

Gefällt mir!

[betateilchen]

Das vom Modul gesetzte NOTIFYDEV ist weiterhin sichtbar, aber wirkungslos.

Das finde ich bedenklich. Man sollte zumindest irgendwie auf einen Blick (!) und am Internal sichtbar machen, dass es nicht wirksam ist.

[rudolfkoenig]

Habs eingebaut, dokumentiert, kurz getestet und eingecheckt.

Das finde ich bedenklich. Man sollte zumindest irgendwie auf einen Blick (!) und am Internal sichtbar machen, dass es nicht wirksam ist.

Ich finde es zwar auch bedenklich, allerdings glaube ich nicht, dass ein Zusatztext am Internal daran was aendert.
Ich habe 'ne Weile damit experimentiert, und das Ergebnis ist meiner Ansicht nach noch verwirrender.
Es ist selten, dass im Forum das Internal ohne das Attribut gezeigt wird, und wenn wir ein Problem mit NOTIFYDEV untersuchen, muesste das Attribut auffallen.

[betateilchen]

Ich finde es zwar auch bedenklich, allerdings glaube ich nicht, dass ein Zusatztext am Internal daran was aendert.

Immerhin sehen mindestes 7 Leute das als bedenklich an. Und das einfach zu ignorieren, finde ich wiederum bedenklich.

Was ist so schwer daran, das Internal beim Setzen des Attributes einfach durch "(replaced by attr)" oder ähnliches zu ergänzen?

Oder noch einfacher: den Wert des Internals einfach in Klammer setzen. Es geht schlichtweg darum, als Helfender sofort  erkennen zu können, dass jemand am NOTIFYDEV geschraubt hat, auch wenn nicht das komplette device gelistet wird.