Dispatch und readingsBeginUpdate - Bug oder Mißbrauch meinerseits

[olwaldi]

Danke für den Tip.

Aber ich glaube, daß X_Attr ABSICHTLICH den $hash von fhem nicht bekommt. Letztendlich kann (und soll?) man das Ändern eines Attributs quasi als "globales" Notify "auffassen", und so funktionierts ja auch prima & logisch konsistent.

Beim Debuggen habe ich auch gesehen, daß jede Änderung eines Readings in DENON_AVR als notify in DENON_AVR_Notify vorbeikommt, und das sind ganz schön viele (trotz event-on-changed-reading). Könnte man auch als überflüssig empfinden, ist aber m.E. auch "richtig" im Sinne von fhem. Ich könnte das ja durch  readingsSingleUpdate(..., 0) vermeiden, aber dann fehlen die Events etwa beim Update in FHEMWEB.

Letztendlich ist das eine Stilfrage, da gibt's kein richtig oder falsch (daher meine Anführungszeichen).

Grüßle, Michael

[Beta-User]

Aber ich glaube, daß X_Attr ABSICHTLICH den $hash von fhem nicht bekommt. Letztendlich kann (und soll?) man das Ändern eines Attributs quasi als "globales" Notify "auffassen", und so funktionierts ja auch prima & logisch konsistent.

Das ist für Querschnitts-Module wie MQTT_GENERIC_BRIDGE (oder readingsWatcher etc.) vielleicht korrekt, aber für die Zwecke des hier in Rede stehenden Modul ist es "gefühlter Unsinn".

Primär ist AttrFn() dafür da, Attributänderungen im betreffenden Modul selbst zu verarbeiten, oder welchen Zweck sollte das sonst haben? Dass da aus irgendwelchen Gründen nicht direkt der Instanz-HASH referenziert wird, ist imo schlicht ein historischer Zufall, dem man keine überhöhte Beachtung zukommen lassen sollte.

Und nein, dass das Modul sich selbst triggert, ist nicht "richtig", sondern zu vermeidender overhead! Das Modul braucht weder eine NotifyFn(), noch sollte es sie haben!

Immer noch meine 2ct.

(Und auch bei dem anderen Thema mit dem ReadyFn() würde ich dafür plädieren, das Problem primär darüber zu lösen, und z.B. den anderen Timer dann darin auch immer wieder zu erneuern bzw. den auf eine längere Periode anzusetzen als die ReadyFn()).
Man sollte immer primär die vom framework bereitgestellten (Spezial-) Funktionen nutzen, statt selbst workarounds einzubauen.