Denon AVR mit Echo dot steuern

AVR Geräte, Sonos, Bluetooth-Lautsprecher usw.
Benutzeravatar

Fonzo
Beiträge: 1690
Registriert: Fr 24. Feb 2017, 00:06

Do 11. Apr 2019, 08:28

Dieselwiesel hat geschrieben:
So 7. Apr 2019, 10:52
Da Alexa nicht direkt unterstützt wird, brauche ich hier auch einen Rasperry , oder? Gibt es hier jemanden der das mit dem 2100 schon gemacht hat?
Ja geht mit einem Raspberry oder auch einen NAS wenn vorhanden. Falls Du das ausprobieren willst der AVR-X2100W wird auch von IPSymconDenon unterstützt und kann mit allen Befehlen über Alexa gesteuert werden. Zum lauter und leiser stellen benutzt man als Typ bei Alexa Lautsprecher
.
0 x
Benutzeravatar

Inso
Beiträge: 3
Registriert: Mo 15. Apr 2019, 08:34

Mo 15. Apr 2019, 09:14

Ich bin über die Google-Suche hierüber gestolpert, und wollte daher noch kurz etwas ergänzen:

Die Denon AVRs lassen sich per HTTP und Telnet über das Netzwerk steuern (so macht es das IP-Syncom einen drüber ja bspw auch).
Das IP-Syncom ist sicherlich der weit einfachere Weg für jemanden der "bei null beginnt", wer jedoch eh mit Smart Home, NodeRed und Co rumspielt, wird ggf die folgende Lösung eher gebrauchen können.
Protokolle für das Netzwerk kann man direkt bei Denon herunterladen, hier sind dann die entsprechenden Befehle alle aufgeführt. Zu beachten ist, das die Telnet-Session jedes mal geschlossen werden muss, wenn ein Befehl abgesendet wurde, einen zweiten nimmt der Verstärker nicht mehr.
Die Befehle lassen sich dann wunderbar mit einer Node Red-Installation auf einem Raspberri PI o.ä. absenden, hier kann dann auch Alexa eingebunden werden. Wer sich damit nicht auskennt wird wohl nicht sehr glücklich damit da es nicht unbedingt trivial ist, wer mit sowas schon mal was gemacht hat sollte aber wenig Probleme bekommen.
Ich lasse einige Befehle über Telnet laufen (vor allem die bei denen man genug Zeit dazwischen hat), wer sich dafür interessiert wird bspw im NodeRed-Forenthread fündig, da hab ich mein Python-Script und die Node zur Ausführung mal gepostet.
Wenn man allerdings bspw die Lautstärke schnell ändern will, sind Telnet-Commands mit ihren ~250ms imo zu langsam. Genau so gab es bei mir Befehle, die zwar im Protokoll standen, der Verstärker aber nicht verstand. Unter diesem Link findet man entsprechende http-befehle, die man auch einfach als GET in Nodered absenden kann. so lässt sich bspw die Lautstärke um einiges schneller regeln, da man die Befehle schneller hintereinander weg senden kann. Auch konnte ich per Telnet den Kanal nicht ändern, jedoch per http.

Ich hab mir dann komplette Befehlsketten geschrieben, die mit 20ms Versatz gesendet werden, und bspw den Audio-Eingang von HDMI auf analog ändern, Audissey-Flat zu manual EQ, dazu Loudness off usw mit einem (bei mir) Tastendruck. So kann man sich wunderbar komplizierte Presets schreiben.

Die Function Node in NodeRed sieht dann bspw so aus (kann sicherlich noch schöner geschieben werden^^):

Code: Alles auswählen

var statOfDenonModeChange = flow.get('statOfDenonModeChange')||0;

function setPayLoad(pldToSend){
    msg.payload = pldToSend;
}

function checkPayLoadNotEqual(pldToCheck){
    if (msg.payload !== pldToCheck) return 1;
    else return 0;
}

function checkPayLoadIsEqual(pldToCheck){
    if (msg.payload === pldToCheck) return 1;
    else return 0;
}

if (statOfDenonModeChange === 0){
    setPayLoad("SI?");      // check input source
}
if (statOfDenonModeChange === 1){
    if (checkPayLoadNotEqual("SISAT/CBL")){ 	// falls die Source NICHT auf sat Cable steht (Befehle stehen in der Dokuentation der Netzwerkprotokolle auf der Denon-HP)
	setPayLoad("SISAT/CBL");     // den Kanal den man haben möchte an die Python Node übergeben
	statOfDenonModeChange = statOfDenonModeChange - 2;	// den Helper zurücksetzen, so das beim nächsten Durchlauf noch mal geshcaut wiurd, ob die Kanaländerung auch stattgefunden hat
	}
    else ++statOfDenonModeChange;	// falls der Kanal richtig eingestellt ist, direkt weiter mit dem nächsten Befehl
}

if (statOfDenonModeChange === 2){
    setPayLoad("SD?");      // check input source
}
if (statOfDenonModeChange === 3){
    if (checkPayLoadNotEqual("SDHDMI")) { 
	setPayLoad("SDHDMI");     
	statOfDenonModeChange = statOfDenonModeChange - 2;
	}
    else ++statOfDenonModeChange;
}

if (statOfDenonModeChange === 4){
    setPayLoad("MS?");      // check input source
}
if (statOfDenonModeChange === 5){
    if (checkPayLoadIsEqual("MSSTEREO")) { 		// hier check auf IsEqual statt auf Not Equal. ich schalte nur zwischen Stereo und Movie hin und her, und da Movie viele Modi zurück geben kann die ich nicht alle checken will (siehe Datenblatt Protokolle von Denon, da sind weiter hinten auch alle returns aufgelistet), schaue ich einfach ob es Stereo ist oder nicht, und wenn ja stelle ich wieder auf Movie.
	setPayLoad("MSMOVIE");      
	statOfDenonModeChange = statOfDenonModeChange - 2;
	}
    else ++statOfDenonModeChange;
}

if (statOfDenonModeChange === 6){
    setPayLoad("PSMULTEQ: ?");      // check input source
}
if (statOfDenonModeChange === 7){
    if (checkPayLoadNotEqual("PSMULTEQ:FLAT")) { 
	setPayLoad("PSMULTEQ:FLAT");     
	statOfDenonModeChange = statOfDenonModeChange - 2;
	}
    else ++statOfDenonModeChange;
}

if (statOfDenonModeChange === 8){
    setPayLoad("PSDYNEQ ?");      // check input source
}
if (statOfDenonModeChange === 9){
    if (checkPayLoadNotEqual("PSDYNEQ ON")) { 
	setPayLoad("PSDYNEQ ON");     
	statOfDenonModeChange = statOfDenonModeChange - 2;
	}
    else ++statOfDenonModeChange;
}

if (statOfDenonModeChange === 10){
    setPayLoad("PSDYNVOL ?");      // check input source
}
if (statOfDenonModeChange === 11){
    if (checkPayLoadNotEqual("PSDYNVOL HEV")) { 
	setPayLoad("PSDYNVOL HEV");    
	statOfDenonModeChange = statOfDenonModeChange - 2;
	}
    else { 
    ++statOfDenonModeChange; 
    msg.payload = "{ \"dtype\" : \"Display\", \"mode\" : \"scrollingText\", \"showText\" : \"PC abendmodus\", \"bright\" : 1 }"	// funktioniert nur bei mir, ist das was am zweiten Ausgang der Node ausgegeben wird
    return [null, msg];	// return am ersten Ausgang null, so wird nichts gesended und die Python-Node nicht mehr getriggert, das Skript bzw die Kette endet also. Früher wurde hier einfach weiter hoch gezählt, daher weiter unten auch noch die if-Anweisung vor dem return msg. Kann also schnell zurückgeschrieben werden. 
    }
}
    
flow.set('statOfDenonModeChange', ++statOfDenonModeChange);	// hier das increment, so das immer einen Befehl weiter gegangen wird bei jedem Durchgang 
if (statOfDenonModeChange <= 11) return [msg, null];
Damit sende ich einen Befehl den ich direkt (bzw mit 20ms delay node) in die Python-Node gebe, den Python-Node-Ausgang gebe ich dann wieder zurück in die Function node so das diese mit der Rückgabe arbeiten kann. Immer mit einer extra Überprüfung ob die Änderung auch übernommen wurde.
"statOfDenonModeChange" sollte nach dem Durchlauf noch einmal separat auf 0 gesetzt werden, damit die Node wieder starten kann (oder das halt oben im Skript ergänzen).
Bei dieser node sind jetzt auch zwei Ausgänge (Outputs) gesetzt, so lasse ich mir nochmal eine andere msg auf den zweiten Ausgang geben wenn das Script durch ist, ist bei mir eine Anzeige am ESP32. Wer das nicht hat den zweiten Ausgang einfach leer lassen oder aus return [msg, null] bzw return [null, msg] einfach return msg machen und die node auf nur einen output setzen ;)
Dann nur den Ausgang der Alexa Node auf entsprechenden Befehl abklopfen, und bei true die oben gepostete Node einfach mit irgendeiner msg am Eingang starten. Natürlich muss man sich für jeden Befehl dann eine eigene function node erstellen und die passend triggern.
tn.read_some muss natürlich wie im NodeRed-Thread beschrieben im Pythonscript dann nach dem send noch eingefügt werden, um auch eine Antwort vom AVR zu erhalten und auswerten zu können.

Gruß
Inso
Zuletzt geändert von Inso am Mo 15. Apr 2019, 09:30, insgesamt 4-mal geändert.
0 x
Benutzeravatar

Fonzo
Beiträge: 1690
Registriert: Fr 24. Feb 2017, 00:06

Mo 15. Apr 2019, 10:14

Inso hat geschrieben:
Mo 15. Apr 2019, 09:14
Zu beachten ist, das die Telnet-Session jedes mal geschlossen werden muss, wenn ein Befehl abgesendet wurde, einen zweiten nimmt der Verstärker nicht mehr.
Das kann man machen die Session zu schließen, macht aber nicht unbedingt Sinn. Sinn ist es ja das der Socket dauerhaft offen bleibt, da über den Socket auch automatisch Rückmeldungen von dem Denon AVR an den Socket gesendet werden. Wenn der Socket nicht dauerhaft offen ist, bekommt man also auch nicht automatisch den Status vom Denon AVR mitgeteilt. Alternativ schaltet man halt per HTTP, das hat aber den Nachteil dass man halt ständig abfragen senden muss um den Status aktuell zu halten, da ja nicht automatisch der Status vom Denon selber gepusht wird. Es ist aber nur möglich eine Socketverbindung zum Denon dauerhaft aufzubauen, wenn ein System den Socket nutzt kann dann auch kein weiteres System mehr auf den Denon AVR über Port 23 zugreifen.
0 x
Benutzeravatar

Inso
Beiträge: 3
Registriert: Mo 15. Apr 2019, 08:34

Mo 15. Apr 2019, 17:53

Fonzo hat geschrieben:
Mo 15. Apr 2019, 10:14
Inso hat geschrieben:
Mo 15. Apr 2019, 09:14
Zu beachten ist, das die Telnet-Session jedes mal geschlossen werden muss, wenn ein Befehl abgesendet wurde, einen zweiten nimmt der Verstärker nicht mehr.
Das kann man machen die Session zu schließen, macht aber nicht unbedingt Sinn. Sinn ist es ja das der Socket dauerhaft offen bleibt, da über den Socket auch automatisch Rückmeldungen von dem Denon AVR an den Socket gesendet werden. Wenn der Socket nicht dauerhaft offen ist, bekommt man also auch nicht automatisch den Status vom Denon AVR mitgeteilt. Alternativ schaltet man halt per HTTP, das hat aber den Nachteil dass man halt ständig abfragen senden muss um den Status aktuell zu halten, da ja nicht automatisch der Status vom Denon selber gepusht wird. Es ist aber nur möglich eine Socketverbindung zum Denon dauerhaft aufzubauen, wenn ein System den Socket nutzt kann dann auch kein weiteres System mehr auf den Denon AVR über Port 23 zugreifen.
HTTP hat (zumindest bei meinem AVR) noch die große Einschränkung, das viel weniger Befehle akzeptiert werden. Bei telnet funktionieren einige nicht, bei http ganze Seiten.
Klar kann man den Socket auch einfach offen halten nachdem man einen Befehl gesendet hat, aber gerade keinen neuen verschicken will, und so weitere status updates erhalten und verarbeiten. Dann kann man ihn aber trotzdem doch fix schließen bevor man eine neue Verbindung aufbaut, und so sowohl steuern als auch die Datensätze abfragen, ist doch per Python-Script keine große Sache. Wichtig ist halt nur einmal der reset der Schnittstelle, damit ein neuer Datensatz akzeptiert wird, der dauert ja max 200ms.
Wenn man dann doch mal gerade nen Status braucht, kann man ihn ja auch wieder einfach per Telnet abfragen, es ist ja eig alles direkt zu erfragen - warum zwischenspeichern..
Ging mir bei der Info primär da rum, das da keiner sitzt und fünf telnet-commands in den Verstärker jagt, und sich dann wundert das der nach dem ersten auf Durchzug schaltet. Auch mein Script ist ja genau auf dieses Verhalten ausgelegt. Wie man dann damit umgeht ist ja wieder ne ganz andere Sache.
Ob der gerade gesendete Befehl akzeptiert wurde, wird in meinem Script ja auch immer abgefragt bevor die Verbindung geschlossen wird. Wo soll denn die Anzeige des Status bzw dessen Verarbeitung erfolgen, das sich eine dauerhaft aktive Telnet-Verbindung rechnet? Ich kann mir grad das Szenario nicht wirklich vorstellen, daher antworte ich halt relativ allgemein..

Bei mir ist es allgemein so, das ich die original IR-FB komplett weggelegt habe, und wirklich alle Befehle incl der Lautstärkensteuerung über telnet und http realisiert habe. Da brauche ich die ganzen Statusmeldungen vom Verstärker nicht, da sie eh nirgends verarbeitet oder angezeigt werden. Die frage ich einfach ab wenn ich sie wirklich mal brauche um was umzustellen, ansonsten wird die einfach verworfen.
Zuletzt geändert von Inso am Mo 15. Apr 2019, 17:54, insgesamt 1-mal geändert.
0 x
Benutzeravatar

Fonzo
Beiträge: 1690
Registriert: Fr 24. Feb 2017, 00:06

Di 16. Apr 2019, 11:14

Inso hat geschrieben:
Mo 15. Apr 2019, 17:53
Dann kann man ihn aber trotzdem doch fix schließen bevor man eine neue Verbindung aufbaut, und so sowohl steuern als auch die Datensätze abfragen, ist doch per Python-Script keine große Sache.
Das kann man natürlich machen und steht ja jedem frei, der Sinn vom Denon Control Protocol ist ja aber gerade nicht ständig eine Anfrage an den AVR schicken zu müssen, das ist unnötiger Netzwerktraffic und unnötige Anfragen an den AVR. Der AVR schickt ja über den Socket den aktuellen Status, das ist an sich ja der Vorteil gegenüber HTTP bei dem man auch zyklisch abfragen muss.
Inso hat geschrieben:
Mo 15. Apr 2019, 17:53
Wo soll denn die Anzeige des Status bzw dessen Verarbeitung erfolgen, das sich eine dauerhaft aktive Telnet-Verbindung rechnet?
Das ist halt eine Frage des Anwendungszwecks, wenn man halt außer Alexa noch eine App bzw. eine Remotesteuerung nutzt, dann sollte in der Remoteoberfläche der Status stets aktuell sein und mit dem tatsächlichen Wert des AVR übereinstimmen ohne das ständig zyklisch Anfragen an den AVR geschickt werden. Die Verarbeitung erfolgt dabei meist zentral von einer Hausautomation, die den Datenpunkt des AVR allen angeschlossenen Remotesteuerungen zur Verfügung stellt, da ja nur eine einzige Instanz dauerhaft eine Socketverbindung zum Denon aufrecht erhalten kann.
0 x
Benutzeravatar

Inso
Beiträge: 3
Registriert: Mo 15. Apr 2019, 08:34

Mi 17. Apr 2019, 03:14

Okay, ich bin was den Traffic angeht wohl eher der Praktiker. Ein Telnet-Command kommt auf max 135 bytes, in meinem Fall ist der Verstärker per Gigabit-Lan angebunden (dürfte mittlerweile überall Standard sein), das entspricht einer Bandbreite von ~1,25 * 10^8 bytes - da kann ich hundert Verstärker parallel abfragen, und trotzdem kommt mein Netflix-4K-Stream nicht mal in die nähe eines Bandbreitenproblems. Bei WLan das gleiche. Telnet ist einfaches TCP, ohne das vorher ne Verschlüsselung ausgehandelt wird oder so, das ist ja nix an Traffic. Wenn ich jetzt nen Bus-System mit 9600 baud oder so hab bin ich bei dem Gedanken der Trafficbegrenzung auf jeden Fall voll dabei, aber im lokalen Netzwerk halte ich das für Vernachlässigbar.
Auch den Verstärker juckt es nicht wenn er nen Status zurückgeben muss, das rennt ja über ne ganz eigene Einheit und beeinflusst den AVR sonst nicht.

Was Apps bzw Remotes angeht die den AVR noch bedienen: wenn es eine externe App ist, wird sie (zumindest die die ich so kenne) den Telnetport selbst nutzen - da bietet es sich sogar explizit an, die Verbindung zum AVR selbst auf ein Minimum zu begrenzen.
Alles was man ansonsten selbst beeinflussen kann bzw sich selber schreibt, würde ich eh über NodeRed und die eigene telnet-Verbindung jagen - so kann man die Statusupdates dann direkt mit allen Geräten sharen, und es entgeht einem nichts, auch wenn die Verbindung jetzt nicht dauerhaft ist.
Wo ich auf jeden Fall zustimme ist, wenn man jetzt die Kombi eigenes Display das einem immer aktuell den AVR-Status anzeigen soll + IR-FB-Nutzung, ohne das man die Apps nutzen will die es so gibt. Da wären ohne dauerhafte Verbindung natürlich die Daten am Display nicht immer ganz aktuell, wenn man nicht dauerhaft am AVR lauscht, und sofern man keine externe App nutzt die den Port auch braucht tut es ja auch nicht weh.

Wer btw hier mit liest, man kann das ganze natürlich noch erweitern, und wirklich alle Fälle abdecken. Einerseits mit Arduino bzw besser ESP826 bzw noch beser ESP32 am RS232-Port, da gibt es komplette Adapter. der RS232 gibt genau so alle Statussachen raus wie telnet, und kann auch genau so Befehle entgegen nehmen.
Genau so kann ein Microcontroller mit IR-Receiver ausgestattet werden, und in der nähe des AVR lauschen. Bedient man den AVR dann, Timer ablaufen lassen, kommt bspw 2 Sekunden kein Befehl mehr, Befehl zum Statusabfragen an NodeRed senden, so ist man auch aktuell ohne den Telnet-Port zu belegen und damit bspw die App zu blocken.
Ob eine App den Verstärker bedient kann man herausfinden, indem man den kompletten Traffic über den Raspi rennen lässt, wie es bspw bei einem Pi-Hole und Co auch passiert. Hier NodeRed triggern wenn die AVR-IP auftaucht, gibts schon passende Nodes für, so ist auch immer aktuell und lässt Kommunikation zu. Alles eine Frage des Aufwandes ;)
0 x
Antworten

Zurück zu „Sound und Anlagen“

  • Information