Dispatch und readingsBeginUpdate - Bug oder Mißbrauch meinerseits

[olwaldi]

Ich bastel seit einigen Tagen am Modum 70_DENON_AVR bzw. 71_DENON_ZONE - eigentlich nur, um einen Bug zu fixen, hab' aber dann doch immer mehr geändert (macht ja auch Spaß). Konkret zu meinem Problem:

Zentral in DENON_AVR ist ein riiiiiesiger if-elsif-Parser mit vielen Rücksprungpunkten für all die verschiedenen Funktionen des zu steuernden AV-Receivers. Die vielen returns habe ich "wegoptimiert", um den $return-Wert nur an einer Stelle hinter dem letzten else zurückzugeben. Es gibt eigentlich immer nur genau eine wahre Bedingung, und für die werden 2..3 Readings mittels readingsBulkUpdate gesetzt. Um nicht ständig readingsBeginUpdate/readingsEndUpdate drumherumzupacken, hat schon der originale Modul-Autor mit einem readingsBeginUpdate VOR dem if und diversen readingsEndUpdate (manchmal erst in aufgerufenen Subfunktionen) erledigt. Insbesondere das Aufbrechen von Begin/End empfand ich als unschön, hat aber funktioniert.

Nun habe ich das Modul insbesondere bzgl. readingsBegin/EndUpdate umstrukturiert und gerade bei den Hauptfunktionen (wie z.B. DENON_AVR_Read) "einfach" den gesamten Funktionsboby in ein readingsBegin/EndUpdate verpackt. Hintergedanke: Dann kann man "gedankenlos" readingsBulkUpdate einfach verwenden.

Auch das funktioniert - selbst in aufgerufenen Subfunktionen bleiben Begin/End erhalten, der Code kürzer & m.E. lesbarer.

Aber, und das ist der Grund meiner Frage hier: Wird allerdings nach einem readingsBeginUpdate ein Dispatch aufgerufen, scheint das Begin "verloren" zu sein. Genauer:

Code Auswählen Erweitern

readingsBeginUpdate();
readingsBulkUpdate();
...
readingsBulkUpdate();
Dispatch();
readingsBulkUpdate();
...Das letzte readingsBulkUpdate liefert die Fehlermeldung

Code Auswählen Erweitern

2026.02.11 15:00:52 1: readingsUpdate(Denon,zone2,on) missed to call readingsBeginUpdate first.
2026.02.11 15:00:52 1: stacktrace:
2026.02.11 15:00:52 1:     main::readingsBulkUpdate            called by ./FHEM/70_DENON_AVR.pm (2234)
2026.02.11 15:00:52 1:     main::DENON_AVR_Parse               called by ./FHEM/70_DENON_AVR.pm (1671)
2026.02.11 15:00:52 1:     main::DENON_AVR_Read                called by fhem.pl (4007)
2026.02.11 15:00:52 1:     main::CallFn                        called by fhem.pl (789)
Aus meiner Sicht habe ich readingsBeginUpdate "brav" aufgerufen.

Man mag jetzt grundsätzlich diskutieren, ob man wie ich mit Begin/End umgehen sollte. Aber aus den zu Anfang genannten Gründen finde ich meine Lösung gut, zumal je Begin/End nur 3..4 Readings modifiziert werden.

In Summe jedoch hat DENON_AVR extrem viele Readings (über 100), kann die aber performant anzeigen. Lediglich die Aktualisierung der fhem-GUI funktioniert nur teilweise (genauer, trotz longpoll erst nach einem Browser-Refesh). Aber das diskutiere ich schon unter https://forum.fhem.de/index.php?topic=143797.msg1357568#msg1357568


Grüßle, Michael

[betateilchen]

Falls Du darauf eine technisch qualifizierte Antwort erwartest, solltest Du sowas nicht in die Anfängerfragen posten. Hier liest Rudi in der Regel nicht mit.

Die Themen Dispatch() und Reaading.*Update() gehören zu fhem.pl, dafür gibt es ein passendes Unterforum.

Den Button zum Verschieben des Themas dorthin findest Du auf der Seite unten links.

[olwaldi]

Hmm, ich würde das Thema ja verschieben, nur wohin genau? Und hätte ich dort überhaupt Zugriff?

Die Forumsregeln https://forum.fhem.de/index.php?topic=107904.0 geben mir eigentlich auch keinen weiteren Hinweis.

Grüßle, Michael

[Beta-User]

Code Auswählen Erweitern

help fhem.plergibt

Module: fhem.pl Maintainer: rudolfkoenig Forum: Sonstiges

Generelle Anmerkungen:
Es ist "unschön", wenn sämtliche Probleme, die letztlich mit einer unsauberen Konstruktion eines einzelnen Moduls zusammenhängen, je isoliert diskutiert werden, ohne dass die Querbezüge klar sind.
Bezugnehmend auf die heutige Modulfassung im svn hatte ich das hier mal geschrieben:

Das betreffende Modul ist "wild":

Beim Debuggen sieht man sofort, daß viele Geräte dem Denon-Receiver notifys zuschicken, z.B. meine Lampen oder Heizung. Was wäre hier eine sinnvolle Einschränkung? Aktuell nutze ich "unreflektiert"

Code Auswählen Erweitern

$hash->{NOTIFYDEV} = "global";Oder ist das schon "zu wenig"?

Grüßle, Michael

Eigentlich benötigt man für so eine Art Modul gar keine NotifyFn, sondern
a) eine AttrFn, die die dort im Moment enthaltenen Funktionen abbildet, und
b) einen durch das define ausgelösten Timer, der die ersten Infos vom Receiver holt.

Dispatch wird imo auch unnötig aufgerufen und macht vermutlich die Trigger durch Endupdate kaputt...

"Eigentlich" wäre es sinnvoll, wenn du einen Tester- oder Developer-Status anfragst, dann kannst du auch in der "Entwicklungsabteilung" schreiben.

Rudi bekommt Verschiebeaktionen übrigens häufig nicht mit, und er liest in einem anderen Thread bereits mit, der sich letztlich mit genau diesen Themen beschäftigt...

Ad Dispatch() noch: imo gehört das zu einer zweistufigen Modul-Konstruktion iSv. https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Zweistufiges_Modell_f%C3%BCr_Module. Zumindest in der svn-Version scheint es aber schon keine wiki.fhem.de/wiki/DevelopmentModuleIntro#Die_Client-Liste zu geben, und es gibt auch keine ParseFn() im Modul selbst, das sich selbst als Client zu verstehen scheint...