NOTIFYDEV, Vorschlag für ein neues globales Attribut overrideNotifydev

Begonnen von PatrickR, 21 August 2023, 14:59:54

Vorheriges Thema - Nächstes Thema

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 :)
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

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,

Zitat von: rudolfkoenig am 22 August 2023, 08:46:16Da 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.
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

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...).
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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!

Zitat von: xenos1984 am 22 August 2023, 13:41:22Fü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.

Zitat von: xenos1984 am 22 August 2023, 13:41:22Es 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
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

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 (?)...
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

PatrickR

Hi!

Zitat von: Beta-User am 22 August 2023, 15:06:54Manche 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.
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

rudolfkoenig

Zitat[...] 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

Zitat von: PatrickR am 22 August 2023, 15:10:08Hi!
Zitat von: Beta-User am 22 August 2023, 15:06:54Manche 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.

ZitatMan 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...
Zitat von: rudolfkoenig am 22 August 2023, 15:18:49
Zitat[...] 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...
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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

Zitat von: rudolfkoenig am 22 August 2023, 16:32:13Vorschlag:
- 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!
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

betateilchen

#12
Zitat von: rudolfkoenig am 22 August 2023, 16:32:13Das 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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Habs eingebaut, dokumentiert, kurz getestet und eingecheckt.

ZitatDas 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

#14
Zitat von: rudolfkoenig am 24 August 2023, 14:53:00Ich 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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!