YAMAHA_AVR Steuerung

Begonnen von dev0, 11 September 2015, 12:17:40

Vorheriges Thema - Nächstes Thema

dev0

Bevor ich zu meinem Anliegen komme, erst einmal ein herzliches Dankeschön für das Yamaha_AVR Modul. Es läuft bei mir schon seit einiger Zeit mit einem DSP-Z7 ohne rumzuzicken.  :)

Vor ein paar Wochen habe ich angefangen ein paar Abläufe, im Zusammenhang mit Sonos Playern, weiter zu automatisieren. Dabei ist mir aufgefallen, dass Befehle an den Verstärker teilweise verloren gehen (oder vom Amp nicht abgearbeitet werden), wenn sie zu schnell hintereinander geschickt werden. Zu schnell heißt in dem Zusammenhang auch, dass ich es sogar manuell über eine GUI schaffe, wenn ich drei Zonen nacheinander einschalte, dass nur eine eingeschaltet wird. Im Log (verbose 3) erscheint dazu nichts, es sei denn, dass der Amp noch nicht zurückgemeldet hat, dass er eingeschaltet ist und schon ein "set volume" aufgerufen wurde..

Ist das bekannt, gibt es Workarounds oder muss ich mir eigene Subs schreiben um Abläufe wie z.B: "Amp on / set volume / sonos speak / set volume back / amp off" mit einem Delay zu versehen?

@Markus: Oder würdest Du ggf. versuchen, das im Modul abzufangen? Vorrausgesetzt natürlich, dass du das nachvollziehen kannst oder mir einfach glaubst  ;)

/Uli

Markus Bloch

Hallo Uli,

dieses Problem kenne ich. Bei mir ist das genauso, wenn ich den Receiver per FHEM einschalten möchte und dann sofort auf einen Input umschalten möchte und die Lautstärke anpassen möchte. Leider antwortet der Receiver, sobald man eine Zone einschaltet für ca. 2 Sekunden nicht. Dabei antwortet er zwar auf die Anfragen, führt sie aber intern nicht durch.

Daher kommt man nicht umrum, solche Aktionen mit einigen Sleeps zu verzögern. Dabei sollte man jedoch KEINERLEI sleep()-Funktionsaufrufe im Perl-Code nutzen, sondern den FHEM-eigenen sleep-Befehl. Da dieser dafür sorgt, das alle nachfolgenden Kommandos in einer Kommandokette zum jeweils späteren Zeitpunkt intern durchgeführt werden.

z.B.:

in 99_myUtils.pm:

sub startNetRadio()
{
  fhem("set AV_Receiver on;
        sleep 5;                                #  <- 5 Sekunden warten, bis AV-Receiver einsatzbereit ist
        set AV_Receiver input netradio;         #  <- dann auf Internetradio umschalten     
        sleep 4;
        set AV_Receiver remoteControl enter;    # durchs Favoritenmenü durchklickern. Nach jedem Enter wird das Menü aus dem Internet geladen. Hier muss wieder gewartet werden, bevor das Menü aufgebaut ist
        sleep 2;
        set AV_Receiver remoteControl enter;
        sleep 2;
        set AV_Receiver remoteControl enter");
}

oder als zusammenhängender Befehl im notify:

define TV_an notify TV_Steckdose:on set AV_Receiver on;sleep 5;set AV_Receiver input av3;set AV_Receiver volumeStraight -37



Anders geht es leider nicht, da der Receiver beim einschalten, als auch beim durchlaufen der Internet-Radio Menüs nach einer Aktion intern mit sich beschäftigt ist und in dieser Zeit keine anderen Befehle durchführt.

Ich hoffe das hilft soweit.

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

dev0

Hey Markus,

ahh, mir war noch nicht klar, dass z.B. das Schalten der Zonen verstärkerintern sogar bis 2 Sekunden dauern kann. Das erklärt das eine oder andere bei mir, ich hatte bisher mit Verzögerungen im Bereich von 100-200 ms gerechnet. Das reichte zumindest um Input und Volume bei einem DSP-Z7 zu schalten.
Ich hatte gehofft, dass man "irgendwie" erkennen könnte ob der Amp für neue Befehle bereit ist, durch ein Ack oder sonst etwas... aber wenn da nichts kommt, kann man auf nichts triggern...

Zitat von: Markus Bloch am 11 September 2015, 13:15:20
Dabei antwortet er zwar auf die Anfragen, führt sie aber intern nicht durch.
Das heisst, man bekommt "realistische" Antworten auf Abfrangen wie "get volume", aber neue Befehle werden nocht nicht ausgeführt? Hattest du dich damit ausführlich beschäftigt oder siehst du noch eine Chance, dass (man|ich) (s|m)ich damit noch einmal beschäftig(t|e)?

/Uli

dev0

Hat der Developer oder oder Leser beim 1500-ten Beitrag drei Wünsche frei? :) :) :)

Markus Bloch

Zitat von: dev0 am 11 September 2015, 14:20:52
Hey Markus,

ahh, mir war noch nicht klar, dass z.B. das Schalten der Zonen verstärkerintern sogar bis 2 Sekunden dauern kann. Das erklärt das eine oder andere bei mir, ich hatte bisher mit Verzögerungen im Bereich von 100-200 ms gerechnet. Das reichte zumindest um Input und Volume bei einem DSP-Z7 zu schalten.
Ich hatte gehofft, dass man "irgendwie" erkennen könnte ob der Amp für neue Befehle bereit ist, durch ein Ack oder sonst etwas... aber wenn da nichts kommt, kann man auf nichts triggern...

In meinen anfänglichen Versuchen hatte es sich so dargestellt, dass mein Receiver nach dem einschalten sofort keine Schaltbefehle ausgeführt hatte. Sie wurden zwar entgegen genommen, aber nicht ausgeführt. Erst nach ca. 2 Sekunden hatte der Receiver die Befehle angenommen, sie aber erst nach dem Abschluss des Startvorgangs (insgesamt ca. 5 oder 6 Sekunden) tatsächlich auch durchgeführt. So in etwa lief das. Die Zeiten können auch leicht variieren, aber so grob war das Bild, als ich mich mit der Schnittstelle das erste mal beschäftigt hatte.

Das gleiche Phänomen kann man mit der Yamaha AV App nachstellen. Erst, wenn der AV Receiver gestartet ist und nach einem Status-Request der AV Receiver "on" meldet, werden die Eingabemöglichkeiten freigeschaltet.

Wenn man den AV Receiver einschaltet wird der Request sofort vom AV Receiver beantwortet (Return-Code: 0 ; Befehl erfolgreich) und der Receiver startet, was mehrere Sekunden dauert. Eine Meldung sobald er fertig ist mit hochfahren gibt es nicht. Hier hilft nur ein statusRequest. Im Modul behandle ich das so: wenn der on-Befehl mit einem Return-Code 0 vom AV Receiver quittiert wird, gehe ich davon aus, da der Befehl erfolgreich war, wird der AV Receiver nun an sein und setze den Status "on" bereits im Vorraus, auch wenn der Receiver gerade beim hochfahren ist. Erst beim nächsten regulären statusRequest wird der power-Status explizit abgefragt, wo er dann auch mit "on" gemeldet wird.

Zitat von: dev0 am 11 September 2015, 14:20:52
Das heisst, man bekommt "realistische" Antworten auf Abfrangen wie "get volume", aber neue Befehle werden nocht nicht ausgeführt? Hattest du dich damit ausführlich beschäftigt oder siehst du noch eine Chance, dass (man|ich) (s|m)ich damit noch einmal beschäftig(t|e)?

/Uli

Die get-Befehle machen nichts anderes als die Readings-Werte auszugeben. Es erfolgt dabei kein erneuter Request an den Receiver. Das möchte ich auch nicht mit einem Request koppeln, da man dann auf die Antwort warten muss. Sollte der AV-Receiver nicht antworten, dann würde FHEM auf eine Antwort warten (max. 5 Sekunden). In dieser Zeit steht dann aber das gesamte FHEM System und wartet auf diese eine Antwort, was sich dann negativ auf das gesamte restliche FHEM-System auswirken würde. Daher nur die aktuell bekannten Readings.

Zitat von: dev0 am 11 September 2015, 14:41:25
Hat der Developer oder oder Leser beim 1500-ten Beitrag drei Wünsche frei? :) :) :)

Wer ruft mir Shenlong? 8)

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

dev0

#5
Markus, vielen Dank für deine sehr ausführliche Antwort, aber ich möchte nochmals nachfragen.
Zitat von: Markus Bloch am 11 September 2015, 15:19:36
Die get-Befehle machen nichts anderes als die Readings-Werte auszugeben. Es erfolgt dabei kein erneuter Request an den Receiver.
Mit "get volume" meinte ich auch nicht die Anfrage an das Modul, sondern ob eine Anfrage an den Amp "wie ist die aktuelle Laustärke" in dem Moment etwas realistisches liefern würde und man vielleicht darüber an den "echten" Status des Amps kommen könnte.

Zitat von: Markus Bloch am 11 September 2015, 15:19:36
Sollte der AV-Receiver nicht antworten, dann würde FHEM auf eine Antwort warten (max. 5 Sekunden). In dieser Zeit steht dann aber das gesamte FHEM System

Es sei denn, man würde diesen Prozess forken und die bis dahin empfangen Befehle in eine Queue stellen. Oder?
Ich erwarte nicht, dass du das implementiert, ich frage nur so genau nach, weil ich mir vorstellen kann das zu übernehmen und dabei weiter in fhem/perl einzusteigen. Learning by doing, wenn es erfolgsversprechend seinen könnte. Daher sind mir deine Erfahrungen/Einschätzungen wichtig um zu entscheiden ob ich das versuche.

Nameste,
Uli


Markus Bloch

Zitat von: dev0 am 11 September 2015, 15:53:27
Markus, vielen Dank für deine sehr ausführliche Antwort, aber ich möchte nochmals nachfragen.Mit "get volume" meinte ich auch nicht die Anfrage an das Modul, sondern ob eine Anfrage an den Amp "wie ist die aktuelle Laustärke" in dem Moment etwas realistisches liefern würde und man vielleicht darüber an den "echten" Status des Amps kommen könnte.

Das bringt nichts. Die aktuelle Info würde er zurückliefern, auch wenn er mitten im Startvorgang ist. Ganz zu Anfang des Moduls hatte ich das auch so implementiert. Der Receiver wird eingeschaltet und sofort nach erfolgter Rückmeldung wird ein statusRequest durchgeführt um die Readings zu aktualisieren. Leider brachte das nichts, da der Power-Status kurz nach dem Einschalten noch mit "off" vom Receiver zurückgemeldet wird, obwohl er gerade am hochfahren ist. Erst nach erfolgtem hochfahren wird der Power-Status auch als "on" gemeldet. Prinzipiell beantwortet der AV-Receiver während des Starvorgangs Status-Anfragen (Lesen von Status-Werten). Was er nur nicht macht ist das ausführen von Befehlen (Schreiben von neuen Einstellungen). Dies wird in dieser kurzen Zeit ignoriert. Genauso auch, wenn man durch das Internet-Radio menü sich klickt. Da kommt immer ein kurzes "Loading..." auf dem Display. In dieser Zeit führt er ebenfalls keine Kommandos aus, ist aber dennoch im Stande Abfragen zu beantworten.

Zitat von: dev0 am 11 September 2015, 15:53:27
Es sei denn, man würde diesen Prozess forken und die bis dahin empfangen Befehle in eine Queue stellen. Oder?
Ich erwarte nicht, dass du das implementiert, ich frage nur so genau nach, weil ich mir vorstellen kann das zu übernehmen und dabei weiter in fhem/perl einzusteigen. Learning by doing, wenn es erfolgsversprechend seinen könnte. Daher sind mir deine Erfahrungen/Einschätzungen wichtig um zu entscheiden ob ich das versuche.

Nameste,
Uli

Ein ähnliches Verfahren nutze ich heute bereits in meinen YAMAHA-Modulen. Immer wenn ein Request gesendet werden soll, wird eine Verbindung zum AV-Receiver aufgebaut und der Request abgeschickt. Das ganze geschieht dabei non-blocking und der Socket wird an die FHEM-weite Socket-Liste angehängt. FHEM prüft dann regelmäßig ob neue Daten auf diesen ganzen Sockets in der Liste vorliegen. Ist dies der Fall werden die Daten wieder an das YAMAHA-Modul gegeben, welches diese Daten dann auswertet. Es ist also bereits jetzt ein entkoppelter Vorgang, der auf ein forking verzichten kann.

Was ich in der nächsten Zukunft noch angehen möchte ist eine Art Kommando-Queue wo alle zu sendenden Requests reingeschoben werden und über eine einzige Verbindung zum AV-Receiver nacheinander durchgeführt werden, sobald die letzte Abfrage beantwortet ist.

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

dev0

#7
Hi Markus,

Zitat von: Markus Bloch am 11 September 2015, 17:02:57
Erst nach erfolgtem hochfahren wird der Power-Status auch als "on" gemeldet.
...
Was ich in der nächsten Zukunft noch angehen möchte ist eine Art Kommando-Queue wo alle zu sendenden Requests reingeschoben werden und über eine einzige Verbindung zum AV-Receiver nacheinander durchgeführt werden, sobald die letzte Abfrage beantwortet ist.

Vielleicht stehe ich ja immer noch aufm Schlauch, aber könnte man dann nicht, wenn z.B. ein "set Volume" an den Verstärker geschickt wird und der Power-Status noch "off" ist, das Kommando für x Sekunden in einer Queue halten und abschicken, wenn der Power-Status innerhalb der nächsten x Sekunden auf "on" wechselt? In der Hoffung, dass der Verstärker oder die Zone gerade erst eingeschaltet wurde. Oder habe ich die Logik immer noch nicht verstanden?

Davon abgesehen fände ich die Option klasse Bass und Höhen über dein Modul einstellen zu können. Wenn ich die Yamaha Doku richtig verstehe, dann sollte das so möglich sein:

<zone><Sound_Video><Tone><Bass><Val>
<zone><Sound_Video><Tone><Treble><Val>
oder
<zone><Sound_Video><Current_Tone><Bass><Val>
<zone><Sound_Video><Current_Tone><Treble><Val>

Min/Max: -/+6.0 db
Step: 0.5 db


Worin der Unterschied zwischen Tone und Current_Tone hat sich mir bisher nicht erschlossen. Beide Parameter sind angeblich r/w.

Edit: Laut der Doku direkt für den DSP-Z7 sollte der Aufruf so aufgebaut sein:
<zone><Tone><Bass><Val> -/+10 db / Step 1

/Uli

dev0

Hi Markus,

ich habe mich mal drangegeben und die Ton Steuerung (Bass und Höhen) für die DSP-Z und 3900er Modelle eingebaut. Hast du interesse dieses Feature in das Modul aufzunehmen? Falls ja, dann würde ich das geänderte Modul oder einen Patch hier anhängen. Der Patch ist aber recht groß, da mein Editor Leerzeichen am Zeilenende entfernt.

Markus Bloch

Hi Uli,

ich versteh zwar nicht so ganz, wozu man Tiefen und Höhen im Rahmen einer Haussteuerung kontrollieren müsste, aber kann ich gerne einfügen.

Patches sind immer willkommen ;-)

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

dev0

Hallo Markus,

da ich alles was mit HiFi/Video zu tun hat ausschließlich über FHEM/smartVISU steuere finde ich diese Steuerungsmöglichkeit gar nicht so abwegig. Zur reinen Automatisierung wäre es überflüssig, da hast du sicherlich recht.

Vorab zum Patch: Habe bitte ein wenig Nachsicht mit mir, wenn der Code nicht so elegant ist wie er vielleicht seinen könnte. Ich programmiere erst seit ein paar Monaten (versuche es zumindest ;) ) und würde mich über Kritik freuen, da ich auch bestehende Features erweitern würde, damit sie mit den DSP Modellen funktionieren (direct, dsp, enhancer, adaptiveDrc, ...)

Zum Patch selbst: ich habe die Tonsteuerung auch für die "normalen" Modelle eingebaut, kann sie aber nicht ausprobieren, habe selbst nur einen DSP-Z7. Würdest du das bitte testen?
Bei einer Kleinigkeit weiss ich noch nicht wie ich sie lösen soll: zur Tonsteuerung muss man bei den DSP Modellen die Crossover Frequenz mit angeben. Diesen Wert speichere ich in einem hidden Reading. Das funktioniert so weit, allerdings wird dieses Reading im Get-Selectmenu angezeigt was etwas unschön ist. Ich habe bisher auch nicht verstanden wie die einzelnen Readings überhaupt in diesem Selectmenu landen. Aber vielleicht gibt es ja auch eine elegantere Methode diesen Wert zu speichern?

/Uli

Bartimaus

Zitat von: Markus Bloch am 11 September 2015, 13:15:20
Hallo Uli,

dieses Problem kenne ich. Bei mir ist das genauso, wenn ich den Receiver per FHEM einschalten möchte und dann sofort auf einen Input umschalten möchte und die Lautstärke anpassen möchte. Leider antwortet der Receiver, sobald man eine Zone einschaltet für ca. 2 Sekunden nicht. Dabei antwortet er zwar auf die Anfragen, führt sie aber intern nicht durch.

Daher kommt man nicht umrum, solche Aktionen mit einigen Sleeps zu verzögern. Dabei sollte man jedoch KEINERLEI sleep()-Funktionsaufrufe im Perl-Code nutzen, sondern den FHEM-eigenen sleep-Befehl. Da dieser dafür sorgt, das alle nachfolgenden Kommandos in einer Kommandokette zum jeweils späteren Zeitpunkt intern durchgeführt werden.

z.B.:

in 99_myUtils.pm:

sub startNetRadio()
{
  fhem("set AV_Receiver on;
        sleep 5;                                #  <- 5 Sekunden warten, bis AV-Receiver einsatzbereit ist
        set AV_Receiver input netradio;         #  <- dann auf Internetradio umschalten     
        sleep 4;
        set AV_Receiver remoteControl enter;    # durchs Favoritenmenü durchklickern. Nach jedem Enter wird das Menü aus dem Internet geladen. Hier muss wieder gewartet werden, bevor das Menü aufgebaut ist
        sleep 2;
        set AV_Receiver remoteControl enter;
        sleep 2;
        set AV_Receiver remoteControl enter");
}

oder als zusammenhängender Befehl im notify:

define TV_an notify TV_Steckdose:on set AV_Receiver on;sleep 5;set AV_Receiver input av3;set AV_Receiver volumeStraight -37



Anders geht es leider nicht, da der Receiver beim einschalten, als auch beim durchlaufen der Internet-Radio Menüs nach einer Aktion intern mit sich beschäftigt ist und in dieser Zeit keine anderen Befehle durchführt.

Ich hoffe das hilft soweit.

Viele Grüße

Markus

Wie Rudi in diesem Posting erklärt hat http://forum.fhem.de/index.php/topic,41077.0.html wird FHEM durch dieses Skript 23sek blockiert. Das kann dann beim KM-LAN zum disconnect führen. Eine Lösung hat Rudi in dem Posting aber direkt aufgezeigt.
LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

dev0

@Bartimaus: Deine Aussage ist zum Glück falsch. Ich habe jetzt zwar nicht in den Betrag geschaut, aber du verwechselst das fhem sleep mit dem perl sleep.

Markus Bloch

Zitat von: dev0 am 21 September 2015, 13:06:29
@Bartimaus: Deine Aussage ist zum Glück falsch. Ich habe jetzt zwar nicht in den Betrag geschaut, aber du verwechselst das fhem sleep mit dem perl sleep.

Oui, der FHEM-eigene Sleep-Befehl setzt sich alle nachfolgenden Kommandos auf Wiedervorlage in X Sekunden und führt diese dann im Hintergrund weiter aus. Steht auch so in der commandref.
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

gitarero

Hallo zusammen,
ich häng mich mal hier dran, da auch hier schon über die Bass/Treble Erweiterung geschrieben wurde.

Ich steuere derzeit meine PS3 (Bluray/Amazon) per CEC über meinen RX-V 771.

Mit dem AVR Modul funktionieren die Cursor Tasten und Enter auch einwandfrei. Jetzt benutze ich aber auch teilweise die Play/Pause/Vor/Zurück Tasten der Fernbedienung.

Ich habe derzeit noch eine App auf dem Handy laufen, welche eine Telnet-Verbindung zum AVR aufbaut. Per Telnet kann man nämlich IR bzw. RC-Codes an den AVR Senden. So habe ich dort aktuell die Steuerung realisiert.

Schön wäre es natürlich, wenn man alles zentral hätte. Ich habe schonmal versucht ein wenig zu recherchieren, allerdings zum Aufruf von RC-Codes über die XML Steuerung nicht wirklich viel gefunden. http://www.heimkino-praxis.com/2014/yamaha-netzwerk-steuerung/

<YAMAHA_AV cmd="PUT"><Main_Zone><Remote_Control><RC_Code>7C80</RC_Code></Remote_Control></Main_Zone></YAMAHA_AV>

Ob das allerdings funktioniert weiss ich nicht. Bin noch nicht zum testen gekommen. Hat denn zufällig hier jemand das schonmal gemacht?
Schön wäre ja, wenn man in FHEM noch die set Option hätte: set <YAM_AVR> RC-Code <code>

Falls jemand sachdienliche Hinweise hat - immer her damit  ;)

Vielleicht komme ich am Wochenende ja mal dazu das zu testen.

Grüße,
Ingo