Entwicklung Plugin für Denon / Marantz Receiver

[Orion]

Das wird dann der entscheidende Punkt sein. Wenn du einenplaylist abspielen kann, dann ist wireshark gefragt, um genau diesen Befehl herauszulösen. Ich habe im Plugin logischerweise keinen vollständigen DLNA oder SOAP Stack eingebaut. Kann ich auch gar nicht. Insofern wird es dann etwas experimentell werden.

Michel

[psilo]

Orion den dlna pfad sieht er in der receiver oberfläche zumindest. was ich mich frage ist, ob er selbst wenn ich es schaffe die m3u abspielt oder nur darin in der oberfläche landet.. naja. ich schaue mal was die app kann, vielleicht ist das ein ansatzpunkt

[Orion]

Hallo,

das mit den Pfaden ist ein schwieriges Thema. Im Grunde muß der Receiver darauf zugreifen können. Ich habe das auch schon versucht, meine Kiste der X3000 ist wohl schon zu alt. Ich wolle auf die gleichen Playlisten der SqueezeBoxen zugreifen (damit eine Quelle mit gleichen Latenzen usw.) Ich habe es mit Bordmitteln nicht hinbekommen. Bin also auch sehr daran interessiert.

Michel

[psilo]

Ich bin mal wieder zu blöd.. Nachdem das mit Radiostreams wie bspw {{ multimedia.station('mm.denon.radio.04', 'mm.denon.main.seturi', 'pics/station/brklassik.png', 'http://streams.br.de/br-klassik_2.m3u', 'midi') } super klappt, versuche ich gerade m3u playlists von meinem NAS einzubinden.

DLNA Server würde laufen, aber bzgl. der Location-Angabe bin ich gerade schlichtweg zu doof.. Normales Netzwerkshare geht nicht, die DLNA URL finde ich irgendwie nicht raus. Hat das schon jemand am Laufen?

[psilo]

Gibt es aktuell noch bei anderen Probleme mit dem Plugin? Warum auch immer liest er zwar noch Werte wie die Lautstärke aus, aber das Senden schlägt fehl? Vielleicht ein Firmware Update?

Update: hat sich erledigt. visu_acl =rw hatte gefehlt. trotzdem seltsam dass es früher ohne ging. evtl hat sich bei uns im smarthomeNG die Prüfung verhärtet...

[Orion]

Ja, bekomme ich auch bei intensiver Nutzung des Denon. Wie schon gesagt habe ich das Gefühl, dass sich der Denon Webserver unter Last ab und zu verschluckt. Die UTF-8 Decodierung habe ich seit Beginn (bis es funktioniert hatte) nicht mehr angepackt. Ist aus meiner Sicht nicht kritisch. Ich könnte mal bei nächster Gelegenheit das Plugin auf das neue Logging umstellen und unter develop einstellen. Evt. kannst Du etwas mit der Zykluszeit der Abfragen spielen (denn die bringen Last drauf).

[psilo]

Ich kriege leider sporadisch seit der neusten Version ohne Ende UTF8 Fehler, hast Du das auch?

[psilo]

Ja, ich hatte auch schon Plugins an denen ich gescheitert bin.. Bspw. weil unter Synology die bluez lib irgendwie nicht vernünftig verfügbar war...

PS: Neuste Version funktioniert jetzt wieder! Danke. Damit ist die Grundfunktionalität wieder da..

[Orion]

Ich würde auch nur das Thema requests als Standard sehen. Den core umzustellen eher nicht. Wichtig ist, wie ein Neunutzer sinnvoll aus dem Repo die Installation machen kann, ohne dass er etwas vergisst oder lange Listen durcharbeiten muss.

[psilo]

Für mich ist wahrscheinlich dann das AVRX4000_PROTOCOL(10.3.0)_V01.zip interessant.. Zumindest ein Ansatz. Ich diskutiere auf Gitter mal das Thema "Requests". Den Core darauf umstellen weiß ich aber nicht.. Würde nur die Entscheidung als Standard "verwenden oder nicht verwenden" sinnvoll sehen. Grundlegend ist im Plugin aber irgendwo auch frei. Aber für Core Plugins wäre es ne gute Sache..

Ich bohre im Plugin gerne dann Features auf, die ich selber benötige. Bei den AVM Geräten ging es darüber hinaus, einmal reicht aber

[Orion]

psilo

Im Grunde hatte ich das so gemacht. Da über ein Befehl (der auch implementiert ist) im Grunde (fast) der gesamte Telnet Umfang emuliert werden kann ist der Umfang von AVRX3000_PROTOCOL(10.2.0)_V01.pdf (findest Du im Internet oder melde Dich, wenn Du das brauchst) bedienbar.

Jetzt kommt das aber: die Weboberfläche verwendet das nicht direkt, sondern andere Elemente. Teilweise gleiche Inhalte mit verschiedenen Bezeichnen (es gibt mal Zone 0, mal heißt diese Main Zone usw.). Nicht gerade freundlich. Auch die Stati kann man nicht mehr alle Abfragen (Höhen und Tiefen kann man setzen, aber nicht über diese Schnittstelle auslesen). Zumindest habe ich das bislang nicht geschafft.

Sofern request bei smarthome.py Einzug hält, dann würde ich den heutigen Stand noch auf requests umstellen. Habe ich schon an andere Stelle verwendet, sehe keine Performance Probleme. Mich Tiefer in die UPNP Thematik einzuarbeiten oder die SOAP Themen noch weiter zu nutzen, dazu habe ich keine Zeit, Du kannst aber gerne dort weitermachen.

Michel

[psilo]

@Orion: ich habe für AVM ja auch "requests" genommen. Fand die Bibliothek ansich super und war bei mir sowohl unter Synology als auch unter dem "standard" Python Installer für Windows glaube ich dabei. Fand auch das Handling recht angenehm. Und auch keiner der bisherigen Tester hatte da größer Probleme (außer einem, der updaten musste)

Bin daher gerne dabei das als Standard für uns zu etablieren. Kann nur nicht viel zur Performance im Vergleich zu einer mehr "low level" Implementierung sagen. Ich hatte kurzzeitig schon überlegt, das Denon Plugin mit Requests gleich als nächstes Projekt neu zu schreiben, kann aber leider auch nicht alles machen. Steuerbar müsste ja noch deutlich mehr sein. Über das Abhören der App bzw die Web-GUI müsste man doch gut auslesen können. Ich dachte auch schon Datenblätter direkt von Denon gefunden zu haben.

[Orion]

OK, das mit der tools.py ist eine grössere Sache. Meine Erweiterung bislang ist OK, deckt nicht alles ab. Wenn ich weiter mache, verliere ich die Kompatibilität und das Restsystem nutzt die auch. Aus meiner Sicht wäre die requests Bibliothek langfristig die richtige Variante.

Aktuelle soweit behoben v0.63 aus dem Repo sollte es tun.

Michel

[Orion]

OK, die Doku ist beim Denon einProblem, das ging nur mit Reverse Engineering. Es gibt nur eine beschränkte Beschreibung der Seriell Protokolls, das auch auf dem Telnet Interface des Denon drauf ist. Hierzu gibt es auch ein Plugin, allerdings ist dieses Interface nur für einen Teilnehmer möglich (bei Telnet klar) und die Verbindung ist instabil. Also viel Wireshark verwendet. Und ich hatte mit mal ein Paar UPNP Tools geschrieben (ist auch bei mir auf Github) um die UPNP Schnittstellen und Services von Mediageräten zu finden. BTW: Da wir auch ganz viel auf der AVM Seite der FB sichtbar. Ich hatte das mal als Alternative zum TR064 Protokoll zum Ausbau des FB Plugins angefangen. Aber das hattest Du ja dankenswerter Weise übernommen.

Der aktuelle Fehler kann dadurch entstanden sein, dass ich die Webrequests wie beim HUE Plugin gewünscht von einer lokalen Implementierung auf die von Tools.py zur verfügung gestellten Lösung umgestellt habe. Vielleicht ist mir dort ein Fehler reingerutscht. Ich hatte nur die ersten Schritte bei mir getestet. Ich glaube aber, dass ich weis, woran es liegen kann. Hier muß ich die Tools.py noch etwas aufbohren. Wahrscheinlich ist die Umsetzung von Headers noch nicht drin.

Als Alternative zu tools.py kann man ja auch die requests Bibliothek nutzen. Ist ganz schön, weiss aber nicht, ob die beim standard python mit dabei ist und wenn nicht, wie man die sinnvollerweise zu smarthome.py dazubekommt. Deine Meinung ?

Ich schaue mir das mal an.

Michel

[psilo]

@Orion: aktuell kriege ich beim Senden einer Streaming URL folgendes (SOAP Body ebenfalls anbei). Ideen? Muss ich den 8080er erst irgendwie aktivieren? Früher hatte das aber alles wunderbar funktioniert.. Kenne leider die ganzen Services und URLs von Denon noch nicht so gut, wie jetzt von AVM... Auf welcher Doku baust Du auf?

2016-04-09 10:56:45,287 DEBUG Main <?xml version="1.0" encoding="utf-8"?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body><u:SetAVTransportURI xmlns:u="urn:schemas-upnp-org:service:AVTransport:1">
<InstanceID>0</InstanceID>
<CurrentURI>http://www.radiodenon.com/pls/pls14570.m3u</CurrentURI>
<CurrentURIMetaData></CurrentURIMetaData>
</u:SetAVTransportURI>
</s:Body>
</s:Envelope>
-- __init__.py:_upnp_set_uri:343
2016-04-09 10:56:45,290 WARNING Main Problem fetching http://192.168.178.29:8080/AVTransport/ctrl: 400 Bad Request -- tools.py:fetch_url:90

PS: Verwende die aktuellste Version v 0.6 aus dem GIT, da die davor hier das Thread Lock nicht aufgelöst hat, da es 2mal gesetzt wurde...