Codevorschlag für das YAMAHA_NP Modul

tomster · 23 Februar 2016, 00:59:27

Uiii, *Vorfreude*
Check ich alsbald ich wieder Zugang zum FHEM über VPN hab. Irgendwas läuft da grad nicht. Aber spätestens am Wochenende.
Mindestens die näxte Halbe geht aber sowieso schomml auf mich! Danke!

ToKa · 20 November 2016, 11:42:45

Hallo zusammen,

hat das Modul schon mal jemand mit dem Yamaha CD-NT670D im Einsatz. Ich habe wie in der Comadref beschrieben, das Gerät mit der entsprechenden IP eingerichtet, bekomme es aber nur als "absent" angezeigt.

Im Log findet sich folgendes:

Code Auswählen

 YAMAHA_NP (E1.wz.AV.CDNT670D) - could not execute command on device E1.wz.AV.CDNT670D. Please turn on your device in case of deactivated network standby or check for correct hostaddress.

Das Gerät ist an und auch network standby ist aktiviert.

Beste Grüße
Torsten

ra666ack · 20 November 2016, 12:37:34

Hi ToKa,

dein Gerät scheint das neue Vernetzungsverfahren MusicCast und somit vermutlich auch ein neues Kommunikationsprotokoll zu verwenden.
Kann dein Gerät mit der Yamaha NP App angesprochen werden?
Mehr Infos im Header des YAMAHA_NP Moduls.

Gruß

ra666ack

ToKa · 20 November 2016, 13:19:12

Hallo ra666ack,

nein der Player lässt sich nicht über die Yamaha NP App steuern, sondern nur über die Yamaha MusicCast App. Insofern trifft Deine Vermutung wohl zu, dass ein anderes Kommunikationsprotokoll verwendet wird.

Ist denn geplant auch das MusicCast Protokoll zu unterstützen bzw. die entsprechenden Geräte?

Gruß
Torsten

ra666ack · 20 November 2016, 13:30:42

Hi ToKa,

da ich kein MusicCast-fähiges Gerät besitze, leider nicht...
Das Modul wurde aufwändig mit Hilfe von Wireshark reverse-engineered.

Gruß

ra666ack

ToKa · 20 November 2016, 15:14:20

Hallo ra666ack,

ich habe inzwischen hier ein paar threads gefunden, die sich mit MusicCast von Yamaha auseinandersetzen. Es gibt bereits erste Analyse bzgl. des Protokolls und auch eine Doku von Yamaha.

Wäre es technisch denkbar Dein Modul als Grundlage für ein MusicCast Modul zu benutzen? Wärst Du damit grundsätzlich einverstanden?

Gruß
Torsten

ra666ack · 20 November 2016, 16:10:12

Hallo Torsten,

in Bezug auf MusicCast habe ich keine Ahnung. Deswegen kann ich den Aufwand nicht abschätzen.
Es ist schon mal gut, dass Yamaha das Protokoll offensichtlich offenlegt. Bei den NP ist das nicht der Fall.

Ich bin nicht sicher, ob ich die Frage richtig verstehe.

Falls gemeint ist, auf Basis des YAMAHA_NP Moduls eine eigene Entwicklung zu starten, ja gerne. Nur zu.
Mein Modul hat sich auch Anfangs an YAMAHA_AVR von Markus orientiert.

Falls gemeint ist, auf Basis der Doku und ohne verfügbare HW das bestehende Modul von mir zu erweitern.
In diesem Fall muss ich leider verneinen. Erfahrungsgemäß funktioniert es nicht, weil keine Testmöglichkeit.

Solltest du diese Herausforderung angehen, kann ich gerne die grundsätzliche Funktionsweise des Moduls erklären.

Gruß

Radek

ToKa · 20 November 2016, 16:36:59

Hallo Radek,

ich meinte eine eigene Entwicklung auf Basis Deines Moduls zu starten. Vielleicht stelle ich es mir zu einfach vor. Aber ohne das NP-Protokoll zu kennen, hoffe ich doch, dass es grundsätzlich ähnliche Funktionen gibt und "nur" die benutzten http Aufrufe bzw. Parameter unterschiedlich sind.

Ich schaue mir mal Dein Modul an und werde in mich gehen, was meine Programmierkenntnisse anbelangt

Vielen Dank schon mal für Dein OK das YAMAHA_NP Modul benutzen zu dürfen und Dein Angebot mir die Funktionsweise zu erklären.

Beste Grüße

Torsten

Markus Bloch · 20 November 2016, 16:46:50

Hallo Thorsten,

als Hilfestellung bei der Modulprogrammierung kann ich dir unser Wiki ans Herz legen. Dort gibt es einen Artikel zur Modulentwicklung wo alle Grundlagen erklärt sind:

http://www.fhemwiki.de/wiki/DevelopmentModuleIntro
http://www.fhemwiki.de/wiki/DevelopmentModuleAPI

Für HTTP-Abfragen stellt FHEM ein eigenes Hilfsmodul HttpUtils bereit. Die entsprechende Dokumentation gibts ebenfalls im Wiki:

http://www.fhemwiki.de/wiki/HttpUtils

Gruß
Markus

ToKa · 20 November 2016, 17:34:47

Hallo Markus,

vielen Dank für die Links. Werde mir alles mal in Ruhe anschauen, ob ich mir das dann zutraue...

Gruß

Torsten

ToKa · 21 November 2016, 23:04:07

Hallo Markus, hallo Radek,

laut API Doku werden die Antworten im JSON Format geliefert:

Parameter information to be returned in the body of response (in JSON object format).

Bei einem ersten Versuch im Browser mit "/YamahaExtendedControl/v1/main/getStatus" erhalte ich folgende Antwort:

Code Auswählen

{"response_code":0,"power":"standby","sleep":0,"volume":31,"mute":false,"max_volume":63,"input":"tuner","distribution_enable":true,"link_control":"standard","disable_flags":3}

Eigentlich ganz gut leserlich... Gibt es ein JSON Modul / einer perl Funktion, die das parsen der Anworten durchführen kann oder müsste ich das selbst programmieren?

Ich hoffe, Ihr habt hier einen Tipp für mich.

Gruß

Torsten

ra666ack · 22 November 2016, 07:27:02

Hallo Torsten,

in der Tat gibt es ein JSON Modul. Diverse FHEM-module setzen darauf auf. Ich meine XBMC (Kodi) gehört dazu.
In der Vergangenheit wurde von Import-Exzessen jedoch abgeraten, um Ressourcen zu schonen z.B. wenn FHEM auf der FritzBox laufen sollte.
Zusätzlich, das Nachinstallierten von Perl-Modulen war auf solchen Geräten meines Wissens nicht ganz einfach.

Da JSON evtl. noch eleganter als XML formatiert ist (wie das NP Protokoll), könnte man es evtl. mit RegEx Ausdrücken versuchen. Perl ist an dieser Stelle sehr stark.

Radek

martinp876 · 01 Januar 2017, 22:49:29

Hallo, ich habe mir den NP eingerichtet. Echt cool und problemlos. Allerdings kann ich mich mit der Bedienung nicht anfreunden.
Das Konzept des Moduls ist offensichtlich, alle Kommandos einzeln einstellbar zu machen, was eine Bedienung nur über eine Maschine zulässt. Ich will meinen NP aber über das Webinterface bedienen, so wie meine anderen Module.
Daher habe ich begonnen die" Oberfläche" anzupassen. Bin schon Recht zufrieden mit dem Ergebnis. Es ist noch ein ihre zu tun. Die (sehr gute!) Dokumentation habe ich noch nicht angetast.

Mir klar, das es ein anderes Konzept ist. Falls es nicht übernommen wird kann ich es verstehen. Allerdings kann ich das bestehende können Konzept nicht nutzen. Schlicht zu weit weg.
Würde mich über Feedback freuen.

Markus Bloch · 02 Januar 2017, 10:31:43

Hallo Martin,

ich konnte jetzt so auf Anhieb keine Änderungen erkennen. Kannst du evtl. kurz erklären, was du geändert hast?

Vielen Dank

Gruß
Markus

ra666ack · 02 Januar 2017, 16:29:48

Hi Martin,

erstmal vielen Dank für Deinen Verbesserungsvorschlag.

In der Tat, die FHEM-Automatisierungsfreunde bestehen darauf, die volle Kontrolle über das zu bedienende Gerät zu haben. Daher die eher "maschinenfreudliche" Befehlsabarbeitung.

Wenn ich das beim ersten Überfliegen des Codes richtig sehe, werden im Browser einige Pull-Down Menüs abgeändert/weitere hinzugefügt, auf Basis aktueller Readings.
Grundsätzlich muss das Modul abwärtskompatibel bleiben.

Hab aktuell keine Möglichkeit, das Modul zu starten, voraussichtlich am WE erst.

Zum Schluss noch eine Frage zum Usecase: Wenn man den NP ohnehin mit dem Rechner/Tablet/Smartphone bedienen möchte, ist die Original App nicht die bessere und intuitivere Wahl?

Gruß

Radek