Modul für Denon (Marantz) AV Receiver

[olwaldi]

War "fleißig" und habe wieder einige Änderungen an 70_DENON_AVR/71_DENON_ZONE eingebaut:

• Ein/ausschalten von unit verbessert
• Internal FVERSION über FHEM::Meta eingebaut
• neue Kommandos set/get delayTime
• HTML-Dokumentation erweitert.

Merkwürdig bleibt, daß die Anzeige einiger Readings/Internals in der fhem-GUI bei Änderungen nicht automatisch aktualisiert werden. Dazu muß man die fhem-GUI im Browser mit F5 aktualisieren, d.h. funktional sind beide Module OK.

Das neue Internal FVERSION gibt eine Versionsnummer aus, wie erwartet UNSTABLE und das Änderungsdatum der Moduldatei. Man muß natürlich die Subversion-Marke auf $Id$ abändern, damit Meta funktionieren kann.


Grüßle, Michael

[Bartimaus]

Moin und vielen Dank.
Die FVVERSION wird mir nach F5 nicht angezeigt.

[Shadow3561]

Moin,
erst nach FHEM Neustart wird die FVVERSION geladen

[olwaldi]

Das FVERSION steht ganz oben bei den Internals, nicht bei den Readings.

Und mittlerweile funktioniert FVERSION auch bei 71_DENON_ZONE wie erwartet. Gerade eben oben korrigiert.

Grüßle, Michael

[olwaldi]

Neuer Tag, neue Erkenntnis:

Ich wollte irgendwie 'rauskriegen, warum manche Internals oder Readings in der GUI nicht immer aktualisiert werden. Debuggen wäre somit eine gute Idee. Und dabei ist mir was ganz Anderes aufgefallen, nämlich daß DENON_AVR unnötig DoTrigger in DENON_AVR_Init absetzt. Das macht laut Doku schon DevIo_Open. Letztendlich hat somit DENON_AVR_Init eigentlich keine Aufgabe mehr.

Meine Sicht der Funktionsaufrufe beim "Starten" von DENON_AVR (z.B. nach einem fhem Restart):

• DENON_AVR_Initialize
• DENON_AVR_Define, ruft
•   DENON_AVR_Connect, ruft
•     DevIo_OpenDev, ruft
•       DoTrigger CONNECTED
• DENON_AVR_Notify verarbeitet CONNECTED Event, startet
•   InternalTimer, ruft nach 5s
•     DENON_AVR_UpdateConfig, ruft
•       DENON_AVR_StatusRequest

Stimmt das grob so - insbesondere mit den CONNECTED Event?

Ähnlich auch bzgl. DISCONNECTED: DENON_AVR_ConnectionCheck prüft regelmäßig, ob der Receiver noch erreichbar ist. Wenn nicht, wird DevIo_Disconnected aufgerufen, was den Event DISCONNECTED auslöst.

Ich habe ja mit dem Überarbeiten von readingsBegin/EndUpdate angefangen, am Code zu basteln. Das habe ich jetzt soweit getrieben, daß diese Aufrufe möglichst den GESAMTEN Body einer sub einpacken, z.B.:

Code Auswählen Erweitern

sub DENON_AVR_Notify($$) {
  my ($hash, $dev) = @_;
  my $name = $hash->{NAME};
  my $devName = $dev->{NAME};

  Log3 $name, 4, "DENON_AVR $name: entering DENON_AVR_Notify ($devName).";
  readingsBeginUpdate($hash);
...
  readingsEndUpdate($hash, 1);
  Log3 $name, 4, "DENON_AVR $name: leaving DENON_AVR_Notify ($devName).";
}
Zur Erleichterung vom Debuggen habe ich einige Log3-Meldungen überarbeite/ergänzt.

Und jetzt werden die Readings nicht mehr doppelt gesetzt, wenn man ein set-Kommando aufruft. Das passierte bislang, da durch die Bestätigungsmeldung vom Receiver die Readings erneut gesetzt wurden.


Grüßle, Michael
PS: Hier ist auch noch ein Tipfehler korrigiert für das get reconnect.
PPS: Alter Bug bzgl. unit in 71_DENON_ZONE gefixt.
PPPS: Überarbeitung der readingsBegin/EndUpdate Strukturen.

[olwaldi]

So langsam scheinen meine Änderungen zuverlässiger zu funktionieren...

Habe nochmal die readingsBegin/EndUpdate stellenweise hin- und herverschoben und die notify- und Timer-Verarbeitung überarbeitet.

Und einen Tippfehler in DENON_AVR_StatusRequest korrigiert (statt VSMONI? stand bei mir MONI?) und die Kommandos dort alphabetisch sortiert. Jetzt wird die Anzeige der Readings in der Web-GUI automatisch aktualisiert.


Grüßle, Michael

[olwaldi]

Nachtrag: Doch noch einen Fehler entdeckt - ein readingsBeginUpdate war zuviel, oben korrigiert.

[Bartimaus]

Helau,

danke. Geladen, installiert, funktioniert und für gut befunden 

[olwaldi]

Danke für's Testen und die Geduld. Aber ich lerne wohl immer noch dazu, siehe
https://forum.fhem.de/index.php?topic=143889.msg1357893#msg1357893
Da wird dann für mich fraglich, wie mit readingsBulkUpdate überhaupt umgegangen werden darf/soll.

Und natürlich habe ich nochwas in DENON_AVR_Parse geradeziehen können - ohne funktionale Auswirkung, aber Verbesserung der Code-Lesbarkeit des Riesen if-elsif-else, das finale else ist jetzt wirklich ein else:-)

Grüßle, Michael

[Bartimaus]

Moin

diese Meldung hatte ich heute Morgen im Log:

Code Auswählen Erweitern

2026.02.16 09:31:49.126 0: DENON_AVR (Marantz_NR1200) - Error while requesting https://IP-Adresse/goform/Deviceinfo.xml - Error 403: Forbidden
Funktioneinschränkungen habe ich jedoch keine....

Sehe jedoch gerade, das ich diese Fehlermeldung auch vor dem gestrigen Update habe.... also jeden Morgen wenn ich den Receiver per Timer [set Marantz_NR1200 on] einschalte

[olwaldi]

An der Stelle habe ich vor eingen Tagen was geändert, so daß DENON_AVR die IP-Adresse selbständig ermitteln kann. Guck' mal nach, was bei Dir im Internal IP drinsteht - sollte die IP-Adresse Deines Marantz' sein. Und mit der richtigen IP-Adresse kannst Du die URL in einem Browser austesten.

Meine Änderung wird allerdings nur aktiv, wenn das fhem-Device über den DNS-Namen angelegt wird. Und das funktioniert erst wieder seit meiner Änderung.


Grüßle, Michael

[Bartimaus]

Hi,

die Adresse in den Internals ist korrekt, und ich kann den Receiver darüber manuell aufrufen. Jedoch nur über https !

Code Auswählen Erweitern

Meine Änderung wird allerdings nur aktiv, wenn das fhem-Device über den DNS-Namen angelegt wird. Und das funktioniert erst wieder seit meiner Änderung.
Was meinst Du damit ? Ich habe das Device "damals" über die IP-Adresse angelegt....

[olwaldi]

Ganz ursprünglich konnte man den Namen des Receivers eintragen. Das wurde ausgebaut mit dem Einbau der deviceinfo.xml, um den Modelltyp ermitteln zu können. Das ist mir jetzt aufgefallen, und ich habs angepaßt.

In der originalen Version von DENON_AVR gabs je nach Alter des Receivermodells zwei verschiedene Methoden, um den Modelltyp automatisch zu ermitteln. Die habe ich beide übernommen. Ist den der Modelltyp im Internal model trotzdem richtig? Dann hätte nämlich die Fallback-Lösung funktioniert.

Grüßle, Michael

[Bartimaus]

Der Modelltyp ist in den Internals korrekt ermittelt

[olwaldi]

Dann hat Alles richtig funktioniert. Ich könnte noch den Fehlerlevel bzgl. deviceinfo.xml hochsetzen. Aber dann erfahren die, die den deviceinfoport auf 8080 setzen müssen (ich z.B., das nicht.

Man muß das dann wohl als Warnung lesen ... Wenn der Receiver dauernd an Stromnetz und Netzwerk hängt, sollte die Meldung nur 1x beim Starten von fhem kommen.

Grüßle, Michael