Dispatch und readingsBeginUpdate - Bug oder Mißbrauch meinerseits

Begonnen von olwaldi, 11 Februar 2026, 16:04:08

Vorheriges Thema - Nächstes Thema

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:
readingsBeginUpdate();
readingsBulkUpdate();
...
readingsBulkUpdate();
Dispatch();
readingsBulkUpdate();
...
Das letzte readingsBulkUpdate liefert die Fehlermeldung
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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!