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
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.
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
help fhem.plergibt
ZitatModule: 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:
Zitat von: Beta-User am 11 Februar 2026, 12:42:58Das betreffende Modul ist "wild":
Zitat von: olwaldi am 11 Februar 2026, 10:23:11Beim 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"
$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...
Danke für die Tipps ... verschoben. Im Modulbereich für DENON_AVR stoße ich ja auch eher auf weniger Interesse - klar, dort sind die Anwender (bin ja selber eher auch einerr) unterwegs.
DENON_AVR ist ja auch gar nicht "mein" Modul - ich wollte nur einen "minibug" wegen XMLin finden und möglichst fixen (man sollte ja nicht nur Fordern:-). Und dann sieht man den nächsten Minibug usw.
Das Dispatch wird in DENON_AVR benutzt, um mit DENON_ZONE zusammenzuarbeiten. Da wollte ich eigentlich nicht genauer gucken...
Letztendlich "stört" mich aktuell nur noch, daß die Readings von DENON_AVR oft im Browser nicht aktualisiert werden. Daher stelle ich immer mal wieder Code etwas um. Gerade eben habe ich konsequent darauf verzichtet, daß DENON_AVR alle Readings immer "doppelt" gemoppelt schreibt, einmal in DENON_AVR_Set/Get, wenn eine Aktion ausgelöst wird, und zum zweiten, wenn der Receiver die Aktion in DENON_AVR_Read bestätigt. Hilft aber nicht bzgl. des nicht-automatischen Browser-Refresh.
Was mir auch noch unklar ist: Warum liest DENON_AVR_Read nur beim allerersten Mal nach einem fhem-Neustart mehrere Antworten in einem Rutsch mit 200.330bytes, ab dann (selbst bei gleicher Aktion) immer nur in Einzel-Botschaften a 10..15bytes?
Aber hier solls ja um updateBulkUpdate HINTER einem Dispatch gehen. Ich kann's durch Codeverschieben umgehen, aber vielleicht ist's ja doch ein Bug?
Grüßle, Michael
Zitat von: olwaldi am 12 Februar 2026, 10:59:32Das Dispatch wird in DENON_AVR benutzt, um mit DENON_ZONE zusammenzuarbeiten. Da wollte ich eigentlich nicht genauer gucken...
Ah, #1184 der svn-Version ist mir beim überblättern am Handy durchgerutscht...
Ich hatte nur - vor dem Hintergrund deiner Fragen an diversen Stellen - gesehen, dass das Modul insgesamt nicht ausgereift wirkt. Von daher finde ich es super, wenn du (optimalerweise mit dem Maintainer) da rangehst und das eine oder andere überarbeitest.
Zitat von: olwaldi am 12 Februar 2026, 10:59:32Aber hier solls ja um updateBulkUpdate HINTER einem Dispatch gehen. Ich kann's durch Codeverschieben umgehen, aber vielleicht ist's ja doch ein Bug?
Imo ist es schlicht so, dass sinnvollerweise immer nur ein einziges Device "offene" Readings im Rahmen eines bulkUpdate hat (von denen "singleUpdate" nur eine Kurzform ist!) Demnach macht es Sinn, erst das Triggern (endUpdate) auszuführen, und dann erst Dispatch() aufzurufen (das dann in der Regel ja wieder eigene Trigger im Rahmen von "bulkUpdate() auslöst).
Dass der Code - so wie er jetzt geschrieben ist - komplett unleserlich ist und eine (gefühlte) Unmenge an Doppelungen enthält und durch diese Reihung dann nicht wirklich einfacher lesbar wird, ist soweit klar.
Allerdings gibt es ziemlich sicher Wege, das zu verbessern...
PS: Das Wichtigste bei einem Modul ist erst mal, dass es im Großen und Ganzen tut, was es soll. Das ist für sich genommen ausdrücklich eine große Leistung, die ich auch nicht durch meine sehr kritische Rückmeldung im Rahmen einer sehr oberflächlichen Code-Durchsicht in irgendeiner Weise schmälern will.
Leider ist es (auch KI-unterstützt) häufig so, dass eben vorhandener funktionfähiger Code als Basis genommen wird, um erst mal überhaupt Ergebnisse zu erzielen, und das Bereinigen hinterher eher kurz kommt.
Das ist anders formuliert eher als Hilfsangebot von jemandem zu verstehen, der - ohne vorher tiefgreifende Programmiererfahrung gehabt zu haben - ein "paar" Module geerbt hat, die er eben zufällig in Benutzung hatte, und dabei entsprechende Erfahrungen gesammelt hat...
Danke für die Erläuterung - habe jetzt wieder immer ein readingsEndUpdate bevor Dispatch aufgerufen wird.
Grüßle, Michael
Noch eine "Entdeckung" meinerseits:
Offenbar muß man mit readingsBulkUpdate vorsichtiger umgehen, als ich dachte. Beim Debuggen der sub-Aufrufe in DENON_AVR ist mir solch eine Merkwürdigkeit aufgefallen:
2026.02.15 11:21:34 4: DENON_AVR Denon: entering DENON_AVR_Read, 5bytes read.
2026.02.15 11:21:34 4: DENON_AVR Denon: calling DENON_AVR_Parse PWON.
2026.02.15 11:21:34 4: DENON_AVR Denon: entering DENON_AVR_Notify (Denon).
2026.02.15 11:21:34 4: notify: power: on
2026.02.15 11:21:34 4: notify: on
2026.02.15 11:21:34 4: notify: stateAV: mainOff
2026.02.15 11:21:34 4: DENON_AVR Denon: leaving DENON_AVR_Notify (Denon).
2026.02.15 11:21:34 4: DENON_AVR Denon: entering DENON_AVR_Set (?).
2026.02.15 11:21:34 4: DENON_AVR Denon zoneMain: parsing <PWON> to <on>.
2026.02.15 11:21:34 4: DENON_AVR Denon: leaving DENON_AVR_Read.
Die 3 notify:-Meldungen stammen von DENON_AVR_Notify, und die Aufruf-Verschachtelung ist wohl
DENON_AVR_Read(
DENON_AVR_Parse(
readingsBeginUpdate()
...
readingsBulkUpdate( power )
readingsBulkUpdate( state )
readingsBulkUpdate( stateAV )
...
readingsEndUpdate()
DENON_AVR_Notify()
DENON_AVR_Set( ? )
)
)
Unverstanden ist von mir dann nur noch, wie sich ein "DENON_AVR_Set ?" dazwischen schieben kann, wohl direkt nach dem DENON_AVR_Notify. Der Aufruf selber stammt vermutlich aus FHEMWEB, um die GUI aufbauen zu können.
Nun wird aber in DENON_AVR_Notify selber wiederum readingsBegin/EndUpdate benutzt (Das kann m.M.n. nur funktionieren, wenn in fhem.pl als stack implementiert).
Grüßle, Michael
Zitat von: olwaldi am 15 Februar 2026, 16:03:17Nun wird aber in DENON_AVR_Notify selber
Wie bereits geschrieben, zumindest bei einer schnellen Durchsicht bin ich zu dem Schluss gekommen:
Zitat von: Beta-User am 12 Februar 2026, 07:44:47Eigentlich benötigt man für so eine Art Modul gar keine NotifyFn, sondern [...]
Bau das um in eine saubere AttrFn ;) .
Nee, nee, ich glaube schon, daß man das DENON_AVR_Notify braucht. Das tut auch gut - ich war nur überrascht über die Aufruf-Verschachtelung.
Das AttrFn könnte man nutzen, wenn man die übergebenen Attribut-Werte intern checken will. Habe ich allerdings momentan nicht zum Ziel.
Mir gings nur um die Anzeige der Attribute in FHEMWEB. Auch das funktioniert, nur springt das Dropdown-Menü immer auf den ersten slider, warum auch immer.
Ich habe jetzt sogar fast alle readingsBulkUpdate umgeändert in readingsSingleUpdate, wenn nur ein Reading zu aktualisieren ist (wie in 2/3 aller Fälle). Ansonsten hätte es readingsBegin/EndUpdate-Paare ganz ohne readingsBulkUpdate gegeben. Hat aber keinerlei Effekt:-(
Ich hoffe, daß das dann wirklich meine letzte Änderung war.
Grüßle, Michael
Zitat von: olwaldi am 16 Februar 2026, 14:39:36ich glaube schon, daß man das DENON_AVR_Notify braucht.
Zumindest in der jetzigen svn-Fassung kann ich das "brauchen" nicht sehen.
Warum ich das so deutlich anspreche? Es ist ineffizient und intransparent:
- Getriggert wird das durch ALLE Events (!), also keine Beschränkung auf global und den eigenen Namen (also in der Regel: Ausnahmen).
Geprüft wird dann, ob entweder
- (ausschließlich!) eigene Attribute gesetzt oder gelöscht wurden (um dann Timer-Funktionalitäten anzupassen). Das kann man (mindestens) genausogut in der AttrFn() machen (ganz ohne eine Gültigkeitsprüfung neu einzuführen, die vermutlich aber auch sinnvoll wäre...), oder
- eigene Events vorliegen... (Das ist imo ohne Worte, selbst, wenn es funktioniert! Komplett intransparent und imo auch nicht "FHEM-like").
Btw: ich habe durchaus vernommen, dass du nicht der Maintainer bist, aber anscheinend bist du nicht der einzige, dem Verbesserungen am Modul am Herzen lägen, und der derzeitige Maintainer hat sich seit über einem Jahr nicht mehr angemeldet, wenn ich das richtig sehe.
Es spräche doch nichts dagegen, zur Vermeidung von künftiger Verwirrung den Maintainer formal mal anzupingen, ob er was dagegen hätte, dich als 2. Maintainer aufzunehmen...? Und dann alle Überarbeitungen, auch von weiteren Usern mit zu übernehmen (wo es nachvollziehbar ist).
Sonst beginnt in 2 Jahren die Raterei, welche Fassung in diesem Thread (oder sonstwo in den Untiefen des Internets) denn nun die am wenigsten buggy version ist....
Just my2ct.
Zitat von: Beta-User am 16 Februar 2026, 18:58:25Warum ich das so deutlich anspreche? Es ist ineffizient und intransparent:
- Getriggert wird das durch ALLE Events (!), also keine Beschränkung auf global und den eigenen Namen (also in der Regel: Ausnahmen).
Hmm, und ich hatte bislang geglaubt, daß notify ein wesentliches Konzept von fhem sei und daher möglichst oft genutzt werden sollte. Andererseits war ich auch überrascht davon, daß alle Events von allen Devices in DENON_AVR_Notify vorbeikommen. Aber das habe ich mittlerweile auf global & "eigenes Device" eingeschränkt.
Ein Effizienzproblem sehe ich speziell in DENON_AVR eher nicht, da ja "normalerweise" gar nix passiert. Im Normalbetrieb ändert man ja z.B. nur hin und wieder die Lautstärke des Receiver, was DENON_AVR dann via notify merkt.
Ich wollte DelMar eh' mal anschreiben, aber erst wenn sich meine Änderungen "stabilisiert" haben. Mal gucken, was er vorschlägt.
Grüßle, Michael
Zitat von: olwaldi am 18 Februar 2026, 08:11:49Hmm, und ich hatte bislang geglaubt, daß notify ein wesentliches Konzept von fhem sei
Das ist durchaus richtig.
Nur deine Schlussfolgerung ist mAn. zu kurz gegriffen: notify dient v.a. dazu, dass "entities" miteinander kommunizieren können, ohne viel voneinander zu wissen.
Zitatmittlerweile auf global & "eigenes Device" eingeschränkt.
Das reduziert den unnötigen Aufwand von 100% auf ca. 70%.
Das Effizienz Thema wird durch notifydev nur im Modul selbst nicht mehr sichtbar...
Was das Modul intern schon weiß, braucht es sich jedenfalls nicht per notify mitzuteilen.
Just my2ct.
Zum Rest: ;)
Da hast Du natürlich Recht.
Habe nochmal geguckt, welche notifys aktuell genutzt werden, das sind Attribut-Änderungen, CONNECTED/DISCONNECTED und Player-Status. Das benötigt in der Tat nicht diesen Umweg. Speziell Meldungen vom Receiver kommen eben nicht via notify sondern via Read (auch die Lautstärkeänderung nutzt kein notify).
Und jetzt verstehe ich auch Deinen Hinweis auf AttrFn, da's sich ja tatsächlich meistens um Attributänderungen dreht. Da stand ich aufm Schlauch:-)
AttrFn erhält allerdings absichtlich nicht den $hash, man kann also nicht auf die Attribut-Änderung reagieren und z.B. Timer löschen, d.h. dann doch notify? Letztendlich soll AttrFn wohl nur zum CHECKEN genutzt werden.
Grüßle, Michael
Zitat von: olwaldi am 18 Februar 2026, 10:40:32AttrFn erhält allerdings absichtlich nicht den $hash, man kann also nicht auf die Attribut-Änderung reagieren und z.B. Timer löschen, d.h. dann doch notify? Letztendlich soll AttrFn wohl nur zum CHECKEN genutzt werden.
Hallo Michael,
einfach in AttrFn folgende Zeile einfügen:
sub DeineAttrFn($@) {
my ($cmd,$name,$aName,$aVal) = @_;
# $cmd can be "del" or "set"
# $name is device name
# $aName and $aVal are Attribute name and value
my $hash = $defs{$name};
...
}
Grüße Jörg
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
Zitat von: olwaldi am 18 Februar 2026, 15:59:40Aber 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.
Zitat von: Beta-User am 18 Februar 2026, 16:29:54Das 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".
...
(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.
Ich bin auch grundsätzlich Deiner Meinung, eher die vom framework bereitgestellten Funktionen zu nutzen statt eigene zu erstellen. Aber ich bin ja auch nicht der Modul-Autor, sondern will mit möglichst wenigen Änderungen ein sehr gutes Modul einen Tick wartbarer machen und ein paar Minibugs fixen.
Aus meiner Sicht (so lese ich das fhem-Wiki bzgl. Modulentwicklung) heißt das aber auch, daß AttrFn nur zum Checken gedacht ist, nicht zum Reagieren. Und der "selbstgebaute" ConnectionCheck funktioniert anders als ReadyFn "aktiv" und erkennt Verbindungsabbrüche direkt, was ich gerade vorgestern konkret beobachten konnte, als ich meinen Denon resetten mußte. Dann gibt es minutenlang kein TCP/IP, aber mit ReadyFn blieb der On-Button grün. Genau das hat mich veranlaßt, genauer nach den Checks zu gucken.
Vermutlich werden wir geide weiterhin unterschiedlicher Meinung sein, ist ja voll OK.
Grüßle, Michael
Zitat von: olwaldi am 19 Februar 2026, 07:52:12Aus meiner Sicht (so lese ich das fhem-Wiki bzgl. Modulentwicklung) heißt das aber auch, daß AttrFn nur zum Checken gedacht ist, nicht zum Reagieren.
Könnte man als Punkt für dich werten ;D .
Das "Problem": Das Wiki hat auch jemand geschrieben, und dort sein (ziemlich sicher mit Rudi abgestimmtes) Verständnis nachlesbar gemacht. Das bedeutet aber nicht, dass das abschließend und/oder vollständig ist. Na ja, vielleicht liest Rudi mit und wir ergänzen dann im Wiki z.B. sowas:
"Falls im Zusammenhang mit der Änderung von Attributen Aktionen auszulösen sind (z.B. InternalTimer zu setzen oder zu löschen), kann und sollte dies hier erfolgen."
Jedenfalls finde ich es nicht logisch, wenn man erst via AttrFn() nur die Gültigkeit prüft, um dann (ausschließlich zu diesem Zweck) per NotifyFn() zu checken, ob man denn jetzt noch irgendwas veranlassen muss (und dabei nochmal einen (denselben...) Attribut-if-elsif-Bandwurm kreiert).
Letztlich finde ich das auch sehr viel schwieriger zu warten.
Und man riskiert nicht, dass sich andere Module in der Eventverarbeitung weiter vorne einklinken und dann Situationen entstehen, die nicht zueinander passen (sowas ähnliches "durfte" ich mal rund um CUL_HM fixen, das man sicher zu diesem Zeitpunkt bereits als sehr ausgereift ansehen durfte!).
ZitatUnd der "selbstgebaute" ConnectionCheck funktioniert anders als ReadyFn "aktiv" und erkennt Verbindungsabbrüche direkt, was ich gerade vorgestern konkret beobachten konnte, als ich meinen Denon resetten mußte. Dann gibt es minutenlang kein TCP/IP, aber mit ReadyFn blieb der On-Button grün. Genau das hat mich veranlaßt, genauer nach den Checks zu gucken.
:P
Das leitet unmittelbar zu dem hier über:
Zitat von: olwaldi am 19 Februar 2026, 07:52:12Aber ich bin ja auch nicht der Modul-Autor, sondern will mit möglichst wenigen Änderungen ein sehr gutes Modul einen Tick wartbarer machen und ein paar Minibugs fixen.
Im Moment bist du vermutlich sehr viel besser im Code eingearbeitet als der Autor bzw. Maintainer. Mir geht es jedenfalls so: Wenn ich ein Modul mal 6 Monate nicht angefasst habe, beginne ich fast von vorne. Von daher habe ich bei fast allen Modulen, die ich in der Pflege habe in der Regel bei der Übernahme jeweils erst mal damit begonnen, alles "für mich" lesbarer zu machen - als Folge "heftiger Schläge" (v.a. seitens RichardCZ) zum vorgefundenen Code...
Es spricht m.E. sehr viel dafür, die Gelegenheit zu nutzen, nicht um ein sehr gutes Modul wesentlich zu verbessern, sondern schlicht, um das vorhandene Modulverständnis in (noch) besser wartbaren Code zu überführen. (Willige) Tester und Mitmacher scheint es ja zu geben, also why not?!?
Ich würde z.B. darauf tippen, dass das mit der ReadyFn() und dem internen Check eigentlich auf ein Logikproblem hinweist, das nicht optimal gelöst ist. Aber so tief bin ich nicht im Code, wie geschrieben: ich habe nicht mehr gemacht, wie 2-3 Mal die svn überflogen...
Hallo,
das Wiki ist nicht die Bibel, sondern eine Handreichung. Vieles hat sich Laufe der Zeit entwickelt, oft das Wiki nicht, das von Benutzern für Benutzer ist. Auch ich pflege als Maintainer nicht das Wiki, sondern nur die commadRef.
In vielen Modulen, auch in meinen, wird das Ändern von Attributen nicht nur validiert, sondern es werden auch Aktionen angestoßen.
Beispiel ist das Setzen des boxUser im FritzBox Modul. Erst mit setzen des Users und vorhandenen Passwort wird im Hash hinterlegt, dass ein Verbindungsversuch zur FritzBox gestartet wird.
Grüße Jörg
Letztendlich ist's für mich auch eine Frage von Aufwand/Nutzen, wieviel ich noch in DENON_AVR ändern will (abgesehen vom Coding-Spaß).
Bzgl. Notify: DevIo kommuniziert uA. via DoTrigger. Aber das müßte man nicht nutzen.
Ich habe auch die Vermutung, daß FHEMWEB seine GUI aufgrund von Notifys aktualisiert. Gerade gestern war ich überrascht, daß die Buttons von DENON_AVR in Chrome (trotz Notify) falsche Werte angezeigt haben. Da hat wohl Android16 die HTML-Seite "anders" gepuffert - Lösung ist dann immer ein Seitenreload. Ohne Notify sollte das eher noch "schlechter" sein. Hier würde ich durchaus noch nachbessern, hab' aber keine Idee.
Grüßle, Michael
Zitat von: olwaldi am 20 Februar 2026, 07:43:44(abgesehen vom Coding-Spaß).
Bisher hatte ich den Eindruck, dass du Spaß dabei hast zu verstehen, wie die Zusammenhänge sind, und das eben gleich beim bug-fixen nutzen willst.
Sonst hätte ich auch keine Freude daran gehabt, die Fragen (teils) zu beantworten und mich durch fremden Code zu wühlen...
ZitatBzgl. Notify: DevIo kommuniziert uA. via DoTrigger. Aber das müßte man nicht nutzen.
Das ist aber auch eher ein Querschnittsmodul im vorher genannten Sinn, und zudem interessiert es häufig auch den User, wenn seine IO nicht (mehr) funktionieren ;) .
ZitatIch habe auch die Vermutung, daß FHEMWEB seine GUI aufgrund von Notifys aktualisiert.
Die Vermutung ist korrekt, wie genau das umgesetzt wird, wird durch das longpoll-Attribut am FHEMWEB-Device bestimmt.
Wenn da was nicht klappt, liegt es in der Regel eher am Endgerät bzw. dessen Browser-Einstellungen. Afair akzeptiert z.b. Firefox nur 4 gleichzeitige longpoll-Verbindungen.
Ich glaube, ihr habt mich weichgeklopft:-)
Mich hat letzlich überzeugt, daß man in den subs typischerweise $name aus $hash holt, genausogut kann man $hash aus $name holen.
Grüßle, Michael
Zitat von: olwaldi am 20 Februar 2026, 08:37:33Ich glaube, ihr habt mich weichgeklopft:-)
:)
Kleine Anmerkung noch dazu:
Zitat von: olwaldi am 19 März 2026, 09:19:18Bei der Gelegenheit habe ich die Verwendung von defined auf defined(...) umgestellt - gab aber nur 2..3 Aufrufe von defined ohne Klammern.
"defined" ist built-in. Das darf man durchaus ohne Klammern aufrufen ;) , genaus "split" usw..
(Dafür klammere ich alle "Pseudo-built-ins" wie z.B. "fhem"-Aufrufe in myUtils ziemlich konsequent ein ;D .)