Modul für Denon (Marantz) AV Receiver

[olwaldi]

Aha... warum liefert das Schreiben auf ein ungesetztes Reading ein Problem?
Readings werden ja erst angelegt, wenn sie geschrieben werden - da liegt es doch in der Natur der Sache, dass sie gelegentlich ungesetzt sind...

Hast du schon mal disconnect und dann reconnect versucht?

Code: [Auswählen]

defmod DenonRS232 notify Denon:state:.absent get Denon disconnect;;get Denon reconnectJe nachdem, wo du das ausführst, darf uU nur ein Semikolon ; verwendet werden.

Evtl mit ein paar Sekunden Verzögerung dazwischen (temporären Timer anlegen)

Das soll laut FHEM-Doku ein normales Verhalten sein, vor einem bulkupdate muß man readingsBeginUpdate aufrufen. Vielleicht ist das nicht passiert? Vgl. auch mein Link im ursprünglichen Post.

Ich habe vor einem Jahr viel probiert, aber jeder Zugriff via DevIo-Aufrufen ist gescheitert, da DevIo die Verbindung nicht wiederhergestellt hat. Merkwürdig ist auch, daß trotz Verbindungsabbruch manche Befehle an den Denon "durchkommen", etwa Mute tut, aber Unmute nicht. D. h. hier muß irgendwieso der Denon initialisiert werden, was das STANDBYOFF wohl kann. Ich werde jetzt noch was Googlen bzgl RS232 / Raspi / perl / Denon, wie man etwa durch direkten Zugriff auf /dev/ttyUSB? was schicken kann.


Grüßle, Michael

[olwaldi]

@Martin: Ich habe vermutlich eine Idee, warum das neuere DevIo.pm viele Fehlermeldungen aus 70_DENON_AVR erzeugt. Wenn ich den Code richtig interpretiere, sollte der state auf opened stehen. Bei meinem Denon steht state aber auf on oder off. Hier ein Auszug aus DevIo.pm:

Code: [Auswählen]

sub
DevIo_getState($)
{
  my ($hash) = @_;
  return ReadingsVal($hash->{NAME}, "state", "disconnected")
}
...
sub
DevIo_Expect($$$)
{
  my ($hash, $msg, $timeout) = @_;
  my $name= $hash->{NAME};
 
  my $state= DevIo_getState($hash);
  if($state ne "opened") {
    Log3 $name, 2, "Attempt to write to $state device.";
    return undef;
  }
Scheinbar sind state und STATE irgendwie identisch (hab' die entsprechenden perl-Kommandos direkt in FHEM ausgeführt). D.h. DevIo_Expect kann nicht funktionieren. Und genau bei der state-Behandlung hat sich DevIo.pm geändert (um nicht exportierte, interne Funktionen).

Bitte prüfen, was aktuell die von FHEM erwarteten Werte für state/STATE sind und ggf. in 70_DENON_AVR anpassen. Vermutlich kann man danach das aktuelle DevIo.pm wieder verwenden. Siehe hier https://forum.fhem.de/index.php/topic,120940.0.html

Das ist aber m.M.n. unabhängig von meinem RS232-Problem.

Grüßle, Michael

[tomcat.x]

Das Verhalten des Status ist vermutlich auch unterschiedlich, je nachdem ob die Netzwerkverbindung im Standby an bleibt oder nicht. Selbst bei meinem neueren X4400H habe ich das wegen zu hohem Verbrauch aus. Zum Einschalten nutze ich allerdings eine Harmony und dann später zum Reagieren auf den Status die Netzwerkverbindung. Problem dabei ist die Dauer, bis das Netzwerk aktiv ist, sowohl für die Verbindung zu fhem als auch zum Webradio hören. Habe mich aber entschieden, damit zu leben.

Bisher habe ich nach dem Einschalten nach "einiger Zeit" oder auch mehrfach dann die Lautstärke situationsabhängig von fhem aus gesetzt. Als ich das jetzt optimieren wollte, indem ich (per notify) erst mal auf die Verbindung warte und dann nur noch einmalig die Lautstärke setze, ist mit folgendes aufgefallen. Ohne Netzwerk-Standby geht das Gerät einige Zeit nach dem Einschalten in den Status "connected". Das aber nur ein paar Sekunden. Danach dann auf "on". Nach dem Ausschalten dann erst mal auf "off" und nach ein paar Minuten auf "disconnected". Als ich jetzt mal zum Test während "off" (vor "disconnected") wieder eingeschaltet habe, hat fhem das gar nicht mehr mitbekommen. Das Gerät blieb auf "off", ohne Verbindung zu fhem.

Den Status "opened" habe ich nicht gesehen. Dafür gibt es Einträge im Log "Attempt to write to on device.", die zur Abfrage nach "opened" im obigen Coding passen dürften.

Das Ganze hier nur, um vielleicht bei anderen Problemen zu helfen. Für mich ist die Funktion in Ordnung. Am meisten störend ist die lange Dauer bis zur Netzwerkaktivierung, aber das ist ein Denon und nicht fhem Problem.

[olwaldi]

Das Ganze hier nur, um vielleicht bei anderen Problemen zu helfen. Für mich ist die Funktion in Ordnung. Am meisten störend ist die lange Dauer bis zur Netzwerkaktivierung, aber das ist ein Denon und nicht fhem Problem.

Genau deswegen habe ich zu RS232 gewechselt, da diese Verbindungsart ähnlich wie Infrarot ständig verfügbar ist, unabhängig vom Netzwerk. Im Wesentlichen nutze ich auch eine Harmony für die Fernbedienung. Aber mir gefällt die "ungenaue" Lautstärkeregelung vom Denon nicht. Daher steuere ich die Lautstärke meines Denon via 70_DENON_AVR in 5dB-Schritten wesentlich komfortabler und definierter. Selbst beim Wechsel zwischen TV und Radiobetrieb erkennt FHEM das und steuert die Lautstärke entsprechend mit (erforderlich, da AAC bei AC3-Transcodierung wegen AC3-Offset um 4dB abgesenkt ist, wo ich mit FHEM gegensteuere).


Grüßle, Michael

[Shadow3561]

Moin,
ich habe gestern Abend mal ins Modul geschaut und eine Kleinigkeit geändert. Jetzt wird im state statt on-off opened-disconnected angezeigt.
Seit dem habe ich auch kein "Attempt to write to on device." mehr im Log.

evtl hilft es ja auch mit dem rs232-Problem

[Stonemuc]

Nur mal eine kleine kosmetische Info - da wor vorher immer das grüne Quadrat bei mir im WebInterface war, steht jetzt nur noch opened - kann das mit nem Update zusammenhängen? Dass irgendwie der STATE geändert wurde?

devSTateIcon wäre nämlich im standart angelegten Device so:

Code: [Auswählen]

on:rc_GREEN:main_off main_off:rc_YELLOW:main_on off:rc_STOP:main_on absent:rc_RED:main_on muted:rc_MUTE@green:muteT playing:rc_PLAY@green:pause paused:rc_PAUSE@green:play disconnected:rc_RED
aber der STATE ist bei mir jetzt opened

[delMar]

Moin,
ich habe gestern Abend mal ins Modul geschaut und eine Kleinigkeit geändert. Jetzt wird im state statt on-off opened-disconnected angezeigt.
Seit dem habe ich auch kein "Attempt to write to on device." mehr im Log.

evtl hilft es ja auch mit dem rs232-Problem

Danke dir dafür.

Ich hab gesehen, dass du auch den Port 8080 bei DeviceInfo hinzugefügt hast.
Bei meinem alten Marantz geht das noch ohne 8080.
Da muss ich mir was überlegen, ob man das automatisch erkennen kann, welches das Richtige ist.

Michael, kannst du mal testen, ob die Version von Shadow eine Verbesserung bringt?
Dann kann ich die gern einchecken.

Stonemuc, das tritt bei mir auch auf.
Kann durchaus mit verändertem Schreiben des States begründet sein.
Kommt auf die Todo-Liste

[Shadow3561]

Ich musste auf Port 8080 wechseln weil es seit meinem letzten Softwareupdate das Model-Reading nicht mehr angezeigt wurde. Ohne Port kommt nur ein 404 zurück.
Das Thema mit den verschiedenen url zur Abfrage des Models hatten wir ja schon einmal ausführlich diskutiert.

MfG

[olwaldi]

Ich habe mir die Änderungen von Shadow3561 angeguckt. Ich glaube allerdings, daß diese Änderungen nicht zur internen Logik von 70_DENON_AVR paßen.

Ich bin nochmal auf die Idee gekommen, die Doku von 70_DENON_AVR anzugucken, und dort steht klar, welche Stati dieses Modul verarbeiten kann/soll:

Code: [Auswählen]

state   -   state of AV reciever (on,off,disconnected)
stateAV   -   state of AV reciever (on,off,absent,mute) [BTW, kleiner Tippfehler in der Doku bei receiver]
Die Fehler aus DevIo_Expect sollten nur auftreten, wenn der state beim Aufruf nicht "opened" ist. Aber eigentlich setzt 70_DENON_AVR beim  DENON_AVR_ConnectionCheck vollkommen korrekt auf "opened" vor dem Aufruf von DevIo_Expect:

Code: [Auswählen]

sub
DENON_AVR_ConnectionCheck($)
{
my ($hash) = @_;
my $name = $hash->{NAME};

Log3 $name, 5, "DENON_AVR $name: called ConnectionCheck.";
my $connectionCheck = AttrVal($name, "connectionCheck", "60");

if ($connectionCheck ne "off") {

$hash->{STATE} = "opened";

RemoveInternalTimer($hash, "DENON_AVR_ConnectionCheck");

my $connState = DevIo_Expect( $hash, "PW?\r", $hash->{TIMEOUT} )
Und ich glaube, die Fehlerursache entdeckt zu haben: Das alte DevIo hat STATE in GROSSBUCHSTABEN gelesen, das neue state in Kleinbuchstaben. D.h. ich teste jetzt mal, ob eine Änderung von Zeile 3439 von STATE in 70_DENON_AVR zu state das DevIo-Problem löst.

Grüßle, Michael

[olwaldi]

Hat leider nicht geklappt - ich bekomme trotz der Änderung von STATE zu state beim Einschalten

Code: [Auswählen]

2022.02.24 09:45:48 2: Attempt to write to on device.bzw. ähnlich beim Ausschalten. Ursache könnte in DevIo.pm liegen. Dort gibt's nämlich ein internes DevIo_setStates, das wiederum STATE schreibt:

Code: [Auswählen]

sub
DevIo_setStates($$)
{
  my ($hash, $val) = @_;
  setReadingsVal($hash, "state", $val, TimeNow());
  if($hash->{devioNoSTATE}) {
    evalStateFormat($hash);
  } else {
    $hash->{STATE} = $val;
  }
}
Dann werde ich mal bei DevIo.pm nachfragen, welche Schreibweise "richtig" ist.


Grüßle, Michael

Nachtrag 10:25: Wenn ich sowohl state als auch STATE auf "opened" setzte, sind die Fehlerrmeldungen von DevIo.pm wohl nachhaltig weg. Dafür verharrt mein Denon-Device im STATE "opened", bis ich ein Kommando via 70_DENON_AVR absetze. Vermutlich scheitert bei meinem Denon AVR 3808 das PW? Kommando in Zeile 3443 manchmal.
Als workaround habe ich das Attribut connectionCheck auf off gesetzt.Das unterbindet den regelmäßigen Verbindungscheck.

[delMar]

Man kann unterdrücken, dass STATE automatisch gesetzt wird (zB um stateFormat nicht ständig zu überschreiben).

Wenn ihr denkt, dass würde helfen, dann kann ich da heute Abend mal was einchecken.

[Shadow3561]

Ich hätte nichts dagegen.
Der state kann bleiben wie er ist, Aber in STATE sollte opened und disconnect stehen. Das Modul funktioniert für mich perfekt, nur das ständige " Attempt to write to on device" nervt mich halt.
Nach meiner Änderung habe ich diese Meldung seit 2 Tagen nicht mehr gesehen.
Ich kann mir nicht erklären warum sie bei @olwaldi nach meinen Änderungen noch erscheint.


Des Weiteren habe ich noch nicht ganz verstanden warum es so viele Readings für den Status des AV-Receivers gibt. Viele ,z.B. on-off-absent, stehen dann je nach Status in mehreren Readings.

state   -   Status des AV-Recievers (on,off,disconnected) stateAV   -   stateAV-Status des AV-Recievers (on,off,mute,absent) power   -   Einschaltzustand des AV-Recievers presence - nicht dokumentiert (zeigt bei mir present,absent)

Nach meinem Verständnis sollte ein

STATE - opened, disconnected state   -   kann entfallen state-av - kann entfallen power   -   Einschaltzustand des AV-Recievers (on, off) presence -  present,absent

oder eben bei

state-av - on, off, present, absent, mutetd

Mit freundlichen Grüßen

[olwaldi]

Ich hoffe noch auf Antwort bzgl. Schreibweise von STATE/state in DevIo.pm Bislang hatte ich immer geglaubt, daß beide Schreibweisen funktionsidentisch seien.

Durch das Attribut connectionCheck auf off wird der "kritische" Beteich von 70_DENON_AVR gar nicht mehr aufgerufen. Ich hätte erwartet, daß danach in der WebGUI von FHEM der Denon-Eintrag nicht mehr aktualisiert würde. Aber der funktioniert auch ohne connectionCheck.

D. h. für mich scheint das Setzen dieses Attributs schon hinreichend zu sein. Vielleicht ist der connectionCheck bei TCP/IP-Verbindung wichtiger?

Auf jeden Fall habe ich jetzt seit heute Vormittag keine Fehlermeldung der Art "Attempt to write to... device.", obwohl das aktuelle DevIo. pm aktiviert ist. Und 70_DENON_AVR funktioniert wie erwartet.

Ich berichte, wenn ich Neues bzgl DevIo. pm erfahren sollte oder wenn sich Fehlfunktionen zeigen sollten.

Im Übrigen Danke für dieses Modul. Ich nutze es insbesondere zur Lautstärke-Steuerung meines Denon. Die "normalen" Volume-Tasten habe schon eine Ewigkeit nicht mehr benutzt. D. h. dieses Modul ist in wirklich intensiver Benutzung meinerseits.

Grüßle, Michael

[olwaldi]

Ich hätte nichts dagegen.
Der state kann bleiben wie er ist, Aber in STATE sollte opened und disconnect stehen. Das Modul funktioniert für mich perfekt, nur das ständige " Attempt to write to on device" nervt mich halt.
Nach meiner Änderung habe ich diese Meldung seit 2 Tagen nicht mehr gesehen.
Ich kann mir nicht erklären warum sie bei @olwaldi nach meinen Änderungen noch erscheint

Ich hab' mir Deine Änderungen nur angeguckt, aber nicht ausprobiert. Du hast z. B. bzgl. zone einige Zeilen auskommentiert. Ich nutze aber auch Zone2 (für den Kopfhörerbetrieb). Wenn ich sowohl state als auch STATE vor dem Aufruf von DevIo_Expect beide auf opened setze, sind die Fehlermeldungen von DevIo komplett weg, aber leider bleibt dann manchmal der state auf opened stehen. Und dann habe ich ja dieses Attribut entdeckt, wodurch der ganze kritische Codebereich komplett deaktiviert werden kann. D. h. für mich sollte 70_DENON_AVR ohne jegliche Patches mit aktuellstem DevIo. pm tun (nicht getestet - noch setze ich STATE & state, bin aber sehr sicher).

Unklar ist natürlich noch, warum die RS232-Verbindung bei mir manchmal abreißt. Inwieweit hier auch das neu gesetzte Attribut connectionCheck hilft, kann ich noch nicht sagen. Dieser Fehler tritt (Gott sei Dank) nur selten auf - gerechnet in Wochen.

Letztendlich weiß nur der ursprüngliche Autor dieses Moduls, warum es so viele scheinbar redundante state-Größen gibt. Daher habe ich ja auch versucht, mit möglichst wenig Änderungen (eben genau nur eine Zeile zusätzlich) hinzukommen, um Seiteneffekte zu vermeiden.

Grüßle, Michael

[delMar]

Muss meinen check-in auf morgen verschieben, es fehlt einfach schon an Konzentration.

einen schönen Abend noch, danke für euren Input