Codevorschlag für das YAMAHA_NP Modul

Begonnen von ra666ack, 06 Januar 2015, 00:58:34

Vorheriges Thema - Nächstes Thema

ra666ack

Hallo Forum,

Inspiriert vom YAMAHA_AVR Modul (vielen Dank an Markus und das FHEM Team) möchte ich einen Vorschlag für ein YAMAHA_NP Modul für die Yamaha Network Player wie den CRX-560(D) bzw. MCR-N560(D) machen.
Darüber hinaus müssten Geräte unterstützt werden, die mit der Yamaha Network Player App für iOS und Android bedient werden können.

Mit dieser simplen Konfiguration kann das Modul eingebunden werden (Das Modul bietet mehr Funktionalität).
Die Definition benötigt die IP und das Intervall, mit dem die Readings upgedated werden.

Der Code kann z.B. als 71_YAMAHA_NP.pm im FHEM Verzeichnis gespeichert werden.

Getested mit CRX-N560D und Raspberry Pi B+ (fhem 5.6).


define NetworkPlayer YAMAHA_NP 192.168.1.15 10
attr NetworkPlayer alias Yamaha CRX-N560D
attr NetworkPlayer room Office
attr NetworkPlayer webCmd powerOn:powerOff:volumeStraight


Der Code kann sicherlich von Perl/FHEM Experten optimiert werden. Ebenfalls bei den FHEM eigenen Themen.
Nahezu alle (sinnvollen) Befehle aus der Android App wurden mit Hilfe von Wireshark ausgelesen und implementiert.

Gruß
ra666ack

Markus Bloch

Hallo ra666ack,

vielen Dank für die lobenden Worte. Ich hab mir mal dein Modul angeschaut. Leider habe ich persönlich nicht einen solchen Player, da die Netzwerkfunktionen bei mir direkt durch den AV-Receiver bereits gegeben sind ;-)

Die Umsetzung ist dir echt gut gelungen.

Das einzige was mir aufgefallen ist: Manchmal escapest du die Backslashes beim Aufruf von YAMAHA_NP_SendCommand und manchmal nicht

z.B.

In Zeile 130:   $result = YAMAHA_NP_SendCommand($hash, "<YAMAHA_AV cmd=\"GET\"><System><Power_Control><Saving>GetParam<\/Saving><\/Power_Control><\/System><\/YAMAHA_AV>");

wurden alle Backslash escaped.

In Zeile 317:     $result = YAMAHA_NP_SendCommand($hash, "<YAMAHA_AV cmd=\"PUT\"><System><Power_Control><Power>On</Power></Power_Control></System></YAMAHA_AV>")

wird nichts escaped.

Generell brauchst du dort nichts zu escapen, bis auf die Anführungszeichen.

Für die Zukunft sollte das Modul noch auf Non-Blocking HTTP Request umgestellt werden. Momentan, so wie es implementiert ist, steht FHEM komplett, sobald es auf eine Antwort durch den Player wartet. Sollte der Player (aus welchen Gründen auch immer) nicht mehr auf Requests antworten, so würde FHEM für die Dauer des HTTP Request Timeouts komplett still stehen und nichts mehr machen.

Ist so an sich erstmal nicht schlimm. Es gibt aber Module (z.B. die HomeMatic Familie) die darauf angewiesen sind, dass es keine starken Verzögerungen (im Sekundenbereich) gibt.

Falls du bereits bist, das Modul zu supporten und im Forum dazu Hilfestellung zu geben würde ich mich freuen, wenn du dieses Modul als Entwickler betreuen könntest und es in FHEM offiziell eingecheckt werden kann.

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)

ra666ack

#2
Hallo Markus,

zu allererst vielen Dank für die Blumen.

Die Backslashes sind eine Angewohnheit aus Python. Die Zeilen ohne sind aus dem AVR modul. Ehrlich gesagt, ich denke, dies ist das kleinste Problem... Als Hobby-Scripter müsste ich mich in die FHEM Besonderheiten noch reinfräsen. Aber man wächst bekanntlich mit den Aufgaben. Unklar ist für mich auch, welche Dynamik in der Entwicklung eines FHEM Moduls steckt. Ich meine, die ersten Posts für das AVR Modul sind aus 2012. Vermutlich sind wir alle beruflich gut eingespannt. Jetzt einen Rückzieher zu machen, wäre etwas unfair dem Besitzer eines Yamaha Network Players gegenüber. Auch wenn der Teufel im Detail steckt, gehe ich davon aus, dass es klappen kann. Soll heißen, ich stelle mich der Aufgabe. Das gilt auch für den Support.

Einige Fragen hätte ich noch:

* Ich gehe davon aus, dass Perl/FHEM spezielle Fragen hier im Forum diskutiert werden können.
* FHEM wir zunehmend (überwiegend?) auf Embedded Systemen eingesetzt. Wie viel Perl Module können/sollten eingebunden werden? Hintergrund: Ein XML Parser würde das Modul robuster machen.
* Wo finde ich ein Beispiel Code für non-blocking HTTP request? Timeouts werden immer beim ECO Standby mode versetzt wird, also wenn der NP nicht mehr am Netz hängt. Zumindest erstmalig. Neue Version des AVR auf sourceforge gefunden.
* Gibt es grundsätzlich einen Leitfaden für die Code Qualität?
* Werden der Kommentarheader und der HTML Code am Ende des Moduls automatisch generiert, oder ist der Entwickler dafür verantwortlich?

Danke und Gruß

Radek

Markus Bloch

Hallo Radek,

kein Problem wegen den Backslashes, war nur ein Hinweis ;-)

Nunja, wenn ein Modul einmal "fertig" ist, gibt es da auch normalerweise relativ wenig zu tun. Generell geht es als Maintainer darum das Modul zu pflegen, aktuell zu halten und Neuerungen die durch die Entwicklergemeinde umgesetzt werde entsprechend nachziehen.

Die Rolle des Modulmaintainers umfasst also.

- Modulweiterentwicklung (je nach dem was dir vorschwebt, evtl. Spezialitäten für neue Modellreihen, usw.)
- Modulpflege (Neue Standards innerhalb FHEM nachziehen)
- Patches/Featurerequest von anderen Usern
- Fehlerbehebung
- Usersupport

Bei mir war natürlich ganz zu Anfang aufgrund der ersten Anfänge mit YAMAHA_AVR eine gewisse Grundlast da was Entwicklung/Usersupport anging. Aber jetzt momentan, wo das Modul mehr oder weniger "fertig" ist, habe ich da momentan nur noch selten was zu tun. Ich nutze es, es funktioniert. Laut Statistik kommt es auf über 180 Systemen zum Einsatz mit verschiedenen Modellen. Aktuell gibt es aber keine Beschwerden. Natürlich gab es mit der Zeit hier und da Probleme mit dem ein oder anderen Modell von Yamaha, aber das konnte auch gelöst werden.

Von daher bin ich momentan recht wenig ausgelastet was das angeht. Ist mir aber auch recht, da ich nun nebenbei studiere ;-)

Zu deinen Fragen.

Zitat von: ra666ack am 06 Januar 2015, 16:54:04
* Ich gehe davon aus, dass Perl/FHEM spezielle Fragen hier im Forum diskutiert werden können.
Generell ja, wobei hier unterscheiden wird zwischen Enduser und Modul-Autor. Enduser-Fragen werden in dem entsprechenden Themenberreich behandelt. Fragen die eher als Modulautor entwickluungstechnischer Natur sind, werden im FHEM Development-Bereich diskutiert: http://forum.fhem.de/index.php/board,48.0.html Wie man hier Schreibzugrif erhalten kann ist unter http://forum.fhem.de/index.php/topic,9658.0.html beschrieben.


Zitat von: ra666ack am 06 Januar 2015, 16:54:04
* FHEM wir zunehmend (überwiegend?) auf Embedded Systemen eingesetzt. Wie viel Perl Module können/sollten eingebunden werden? Hintergrund: Ein XML Parser würde das Modul robuster machen.

Hier kann zum Beispiel die FHEM Statistik weiterhelfen: http://fhem.de/stats/statistics.html

Embedded Systeme sind durchaus stark vertreten. Genau aus diesem Grund, sollte man bei der Wahl von Perl-Modulen als Abhängigkeit folgendes Beachten:

- so wenig Perl Module wie möglich verwenden (Stichwort: RAM Verbrauch bei kleinen Systemen wie FritzBox, Raspberry,...)
- wenn überhaupt, nur Perl-Core Module verwenden (siehe dazu http://perldoc.perl.org/index-modules-A.html) denn diese sind bei jeder Perl-Installation mit dabei und müssen nicht via CPAN oder ähnliches nachinstalliert werden.
- sollten externe Perl-Module (z.B. von CPAN) notwendig sein, müssen diese in der Moduldokumentation explizit erwähnt werden und wie der User diese installieren muss

Dies ist auch ein Grund, warum ich kein XML-Modul für meine YAMAHA Module verwende. Dazu kommt noch, dass es bei einer falschen Benutzung des XML Moduls zu Memory-Leaks kommen kann. Eine gut gewählte Regexp kann daher hier durchaus die bessere Methode sein.


Zitat von: ra666ack am 06 Januar 2015, 16:54:04
* Wo finde ich ein Beispiel Code für non-blocking HTTP request? Timeouts werden immer beim ECO Standby mode versetzt wird, also wenn der NP nicht mehr am Netz hängt. Zumindest erstmalig. Neue Version des AVR auf sourceforge gefunden.

Schau auch mal ins Wiki: http://www.fhemwiki.de/wiki/HttpUtils#HttpUtils_NonblockingGet

Zitat von: ra666ack am 06 Januar 2015, 16:54:04
* Gibt es grundsätzlich einen Leitfaden für die Code Qualität?
Alles was hier im Wiki dazu festgehalten ist: http://www.fhemwiki.de/wiki/Kategorie:Development

Und das was im Forum FHEM Development so besprochen wird.

Zitat von: ra666ack am 06 Januar 2015, 16:54:04
* Werden der Kommentarheader und der HTML Code am Ende des Moduls automatisch generiert, oder ist der Entwickler dafür verantwortlich?

Nein, diese sind durch den Entwickler bereitzustellen. Der Header ist lizenrechtlich vorgeschrieben. Der HTML-Code am Ende eines Moduls ist die Moduldokumentation die später in der Commandref (http://fhem.de/commandref.html) entsprechend hinterlegt wird. Die Commandref wird aus allen Modulen erzeugt und bildet die gesammelte Dokumentation für FHEM. Nur, wenn ein Modul mind. eine englische Dokumentation besitzt, darf es in FHEM eingecheckt werden. Besser wäre natürlich eine englische und deutsche Dokumentation. Schau dir am besten mal die Commandref an, um ein Gefühl dafür zu bekommen, was man wie am besten dokumentieren sollte (Auf jedenfall Definition, Get-, Set-Kommandos, Readings und Attribute).

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)

ra666ack

#4
Hallo Markus,

danke für deinen Input. In den letzten Tagen habe ich den Code umgeschrieben (sehr stark an deiner trunk Version angelehnt, die mir vom Style her übrigens sehr gefällt). Die neue "non-blocking" getestete Version angehängt.

Die HTML Doku folgt.

Gruß

Radek

Markus Bloch

Hallo Radek,

sieht doch echt super aus. Daumen hoch dafür  ;)


Ich würde allerdings folgendes Konstrukt:

            for(my $i = 1; $i < 31; $i++)
            {
              if($data =~ /<Item_$i>(.+)<\/Item_$i>/)
              {
                readingsBulkUpdate($hash, "presetFMItem_$i", $1);
              }
            }

durch


              while($data =~ /<Item_(\d+)>(.+?)<\/Item_\d+>/gc)
              {
                readingsBulkUpdate($hash, "presetFMItem_$1", $2);
              }



ersetzen.  Man erreicht das selbe, nur einfacher. Nur als Vorschlag.

Noch die Doku dazu und man könnte es einchecken.

Weiter so!

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)

ra666ack

#6
Hallo Markus,

Vielen Dank. ich schmücke mich nur ungerne mit fremden Federn. Die Hauptarbeit hattest du.
Das Modul ist nach bestem Wissen und Gewissen getestet. Ich hoffe, es kommen weitere kritische Benutzer dazu.

Das File jetzt mit HTML.

Gruß

Radek

domschl

Habe das Modul gerade an meinem Yamaha Pianocraft 560D ausprobiert und getestet: es funktioniert wirklich ausgezeichnet!

Hoffentlich wird es bald ins SVN eingechecked.

Danke!

ra666ack

Hey, das erste Feedback!
Freut mich, dass der erste Anwender begeistert werden konnte.
Habe das Modul zum Einchecken vorgeschlagen. Man bleibt gespannt.

Gernott

Hallo

Noch ein Feedback: Läuft bei mir bisher hervorragend!
Vielen Dank für die Arbeit.

Gruß
G.

ra666ack

Vielen Dank für das Feedback. Das Modul wurde offiziell eingechecked.

topfi

Auch von mir nach einem ersten heutigen Test: Großartig, Daumen hoch!

Die Schlafzimmeranlage war das einzige, was noch nicht über FHEM gesteuert wurde und woran ich deshalb täglich denken muss. Ausgerechnet davon lasse ich mich immer wecken. ;-) Das Wichtigste für mich ist also, dass Du an die Timereinstellungen über FHEM gedacht hast. Großen Dank dafür.

Eine Frage habe ich aber noch: Wie kann man einen netradio Sender abspielen? Wenn netradio als Input gewählt wird, landet man auf dem Player nur im Bookmark-Ordner und das Radio spielt noch nicht. Man müsste noch 2x ok drücken. Wie funktioniert das?

ra666ack

#12
Hi topfi,

vielen Dank für dein positives Feedback.

Zugegebenermaßen ein Premium-Wecker  :D

Die "Netradio/Bookmark" Play Funktion ist in der Tat (noch) nicht implementiert. Leider ist es nicht ganz trivial umzusetzen.
Das Netzwerk-Protokoll muss hierbei eine ganze Latte an Listen und deren Inhalten auswerten. Die Fernbedienung ist in der Tat wesentlich einfacher.

Vorstellbar wäre eine set-Funkion z.B. selectNetradioBookmark x nachdem man auf 'netradio' umgestellt hat.
Dabei müssten die Bookmarks allerdings im "Root-Verzeichnis" abgelegt werden und nicht wie bei mir in Unterordnern. Sonst wird die Funktion sehr umfangreich und bläst das Modul mE zu sehr auf.

Gruß


topfi

Nicht so schlimm, wie gesagt, das Einstellen des Weckers ist wichtiger. Bei mir läuft sowieso immer der gleiche Sender.

Ich schalte bewußt nicht über FHEM ein (dann würde mir die "Netradio/Bookmark" Play Funktion sehr fehlen) sondern über den internen Timer, damit ich nicht verschlafe, wenn FHEM mal abstürzen sollte. (Ist noch nie passiert ;-) FHEM macht das Licht an und Yamaha das Radio, perfekt. Und wenn ich aufgestanden bin, macht FHEM den Yamaha wieder aus. Großartig. :D

ra666ack

OK, die von die beschriebene Funktion ist bereits implementiert. Timer on/off aktiviert in der Tat den internen Timer, (sofern die Anlage im standbyMode normal ist).

Ich bin mir noch nicht ganz sicher, ob es sinnvoll ist, in FHEM die offizielle App nachzubilden. Schließlich geht es um Automatisierung z.B. Wecker am WE aus, "Digital 1-Eingang" an, falls TV an usw. Ohne optisches Feedback wird die Bedienung äußerst schwierig...

Ich habe noch kein Konzept hierfür. Muss mir noch paar Gedanken machen.

(Das 71_YAMAHA_NP Modul wurde bereits in FHEM offiziell eingecheckt. Falls noch nicht geschehen, bitte FHEM updaten. Dort wurde die Timer-Funktion nochmals intuitiver gestaltet.)