Codevorschlag für das YAMAHA_NP Modul

[martinp876]

nun, dann muss ich mich selbständig machen.
Die App ist für mich zu umständlich und zu langsam. In FHEM kann ich das deutlich besser. Auch wenn mir noch ein paar Funktionen fehlen.
Geändert habe ich einiges mehr - hier ein paar Details:
- entschlacken der internals: Informationen welche man fast nie braucht werden entfernt. Die speichere ich in helper und geben sie per "get" aus
- entschlacken der Readings: Sinnlos ist es, leere Stationsspeicher auszugeben. Die Liste der Readings wird endlos - ohne Inhalt.
- entfernen ungültiger Einträge aus den Readings. Wenn der Player "leer" liefert muss man das Reading löschen. Es ist ungültig.
- Darstellen der kompletten auswahlliste (playerlist) - nicht nur 8. Ich will sehen, was es gibt, nicht raten.
- zusammenfassen der Information: Attibute gehören zu den Stationstasten (Container / Item) - ein extra Reading macht es unleserlich
- mitschreiben der Directory-tiefe. Hangelt man sich nach unten sollte man jede Stufe darstellen (also den Directory-pfad). Beispiel bei Radio

Code Auswählen Erweitern

playerListLvl1  NET RADIO
playerListLvl2  Locations
playerListLvl3  Europe

- Kommandos mit Angabe der Namen der Streams - hat man doch - also anzeigen
- direkte Anwahl von allen Entties in der Playlist - auch wenn sie 100 einträge groß ist (klappt seit heute - hat noch einen Bug in der geposteten Version)
- direkte Anwahl bei Dir-upward (muss ich morgen einbauen)
- Direkte Selektion des Radio Bands (DAB / FM) bei Input. Das macht auch Yamaha nicht - schlicht weil es DAB in der internationalen Version nicht gibt und somit diese Funktion stiefmütterlich eingebaut wurde. Kann man besser.
- Context - sensitiv Readings - löschen von Readings welche nicht zum Playmode gehören (Stationsspeicher bei input=CD)
- reduzieren der "get" funktion auf interessante inhalte. ReadingVal gibt mir den Inhalt von Readings - dazu braucht es kein get mit ellenlanger kommandoliste.
- zusammenfassen von informationen in einem Reading um die Liste klein zu halten ( Frequenz, Qualität,... kann man in einer Zeile ausgeben)
- weitere Optionen werden ich wie bei HM durch eine "attr expert" unsichtbar schaltbar machen. Die will ich quasi nie sehen.
- Speichern der DAB Sendernamen (geht schon fast - muss die Sicherung bei reboot noch verbessern)
- optimierung des Statusrequest nach Kommandoeingabe - das dauert zu lange
- Beachten des "ready" des Players vor dem Senden neuer Kommandos
- EIN Kommando zur Auswahl des Streams (selStream aktuell) - egal ob ich radio, net-radio, USB oder Server nutze. Damit kann man dann ein super einfaches Interface zur steuerung aufbauen

Code Auswählen Erweitern

webCmd volume:input:selStream
erlaubt - wenn ich es im "raum-view" aufmache einschalten/volume-control/input-control (incl DAB/FM)/Navigation durch Senderspeicher oder directories oder netradio--stationen. Das sind 95% der Tasten welch ich brauche.

Ich werden auch "sinnlose" komamndos entfernen.
A) kommandos nur kontest-sensitiv anbieten. Wenn ich den USB am laufen habe werden im webinterface keine Radio-stationstasten anbegoten. geht eh nicht. Die meisten sind schon raus.
B) Wenn das selStream komplett ist werden die cursor kommandos verschwinden. Das navigieren durch die Menues (ziemlich unfreundlich von Yamaha implementiert für Mensch oder Maschine) wird quasi das API erledigen. Ist noch offen.

Es wird am Ende noch alles einstellbar sein.

Ich werde es nicht weiter veröffentlichen - stiftet nur Verwirrung. Falls jemand interessen hat kann er sich an mich wenden.
Der aktuelle Ansatz (das Front-end - auch die reaktionszeiten,...) ist von meinen Vorstellungen und bedürfnissen sehr weit entfernt. Je mehr ich mich mit dem Teil befasse um so weiter.

Dennoch - super, dass die Grundlagen erstellt wurden. Das ist eine gute Basis, meine Vorstellungen zu verwirklichen. Danke!!

[ra666ack]

Hallo Martin,

ich fürchte, ich habe mich nicht präzise genug ausgedrückt. Es war nicht als kategorisches "Nein" gemeint. Unglücklicherweise, sind genau die auf den ersten Blick "sinnlosen Listen" auf Wunsch von Usern nachträglich implementiert worden. Der web-basierte Ansatz ist nachvollziehbar.
Die Hauptaufgabe würde darin bestehen, die entgengesetzten Implementierungswünsche zu verheiraten. Wie schon angedeutet könnte man es evtl. mit Attributen erschlagen.

Vorschlag meinerseits: Wenn der Funktionsumfang deines "neuen" Moduls steht, würde ich es mir gerne anschauen. Kommentare im Quellcode sind willkommen.

Gruß

Radek

(Alternativ, kann man kann immer noch über eine Maintainer-Rolle des Moduls nachdenken.)

[Markus Bloch]

Hallo Martin,

B) Wenn das selStream komplett ist werden die cursor kommandos verschwinden. Das navigieren durch die Menues (ziemlich unfreundlich von Yamaha implementiert für Mensch oder Maschine) wird quasi das API erledigen. Ist noch offen.

Hierzu habe ich in YAMAHA_AVR bereits das set-Kommando navigateListMenu erstellt. Dieses führt ein Browsing durch die Menüs durch. Man gibt einen Pfad von einem Menüpunkt an (bspw. Radiosender aus Favoritenliste) und FHEM steuert dieses dann selbstständig an, egal wo sich der Cursor gerade befindet.

Ich bin gespannt, wie deine fertige Version aussieht. Generell würde ich es begrüßen, wenn alle Module der Yamaha-Famile eine einheitliche Bedienung aufweisen. Ich würde dann entsprechend YAMAHA_AVR/YAMAHA_BD nachziehen, sofern es mit den bisherigen Verhalten vereinbar ist.

Viele Grüße

Markus

[martinp876]

Hallo Markus,
Mein ziel ist nicht, mich abzukoppeln. Das webinterface ist m.E. ein hmi. Fuer automaten kann man ein mmi ueber sonstige funktionen zu verfuegung stellen.
Kommandos sollten schnell und einfach zu finden und auszufuehren sein. Der user soll moeglichst wenig mit deviceablaeufen zu tun haben. Das muss fhem leisten. Wenn du auch auf diesem weg bist koennen wir zusammen kommen.
Wenn ich die levelup noch in die selektliste eingebaut habe sind die wichtigsten bausteine enthalten.
Was ich nicht habe ist eine scan funktion welche dirs scanned ind darstellt. Das ist m.e. ein anderes modul, eine ebene hoeher.
Vielleicht werde ich heute mit der basis fertig, dann poste ich noch einmal.
Gruss Martin

[martinp876]

Hallo Markus,
hier einmal eine weitgehend funktionierende Version.
Gerne feedback und eine Disksusion. Wie vorhergesagt: Die interfaces sind aus meiner Sicht userfreundlich(er). u.a. habe ich die Schaltungen versucht zu harmonisieren (next/prev sollten immer gleich benannt werden, ob bei Tuner, CD oder Server).
Sorry, dass ich den Code umformatiert habe - so arbeiten eine tools am besten - insbesodere der Editor.

Achtung: Das Commandref ist noch (fast) nicht angetatet.

Gruß Martin

[ra666ack]

Hi Martin,

vielen Dank für deinen Verbesserungsvorschlag.
Versuche es heute Abend zu testen. Auch gegen das AVR Modul von Markus.

Übrigens, sehr schick.
Macht den Code schlanker und wesentlich übersichtlicher. Chapeau.

Code Auswählen Erweitern


my $di = "PUT:Tuner,Play_Control,Preset,Preset_Sel:Next"

my ($c,$x,$d) = split(":",$di);
my @xa = split(",",$x);
my $data = "<YAMAHA_AV cmd=\"$c\"><".join("><",@xa).">$d</".join("></",reverse @xa)."></YAMAHA_AV>";


Gruß

Radek

[martinp876]

achtung - ich habe noch einige Fehler eingebaut
Ich bessere gerade nach....

p.s.: Wo habt ihr das xml her? Mir fehlenin paar Informationen - cool wenn ich nicht loggen müssen.
Bei systemConfig liegt m.E. ein Fehler vor - es wird der Networkstatus gelesen.

[ra666ack]

Yamaha will das NP Protokoll nicht offenlegen, deswegen alles mit Wireshark gelogged.

systemConfig sollte so gehen: <YAMAHA_AV cmd=\"GET\"><System><Config>GetParam</Config></System></YAMAHA_AV>

EDIT: Sieht so aus. Der richtige Aufruf ist nur in der YAMAHA_NP_getModel().

[Markus Bloch]

Hi Martin,

vielen Dank für deinen Verbesserungsvorschlag.
Versuche es heute Abend zu testen. Auch gegen das AVR Modul von Markus.

Übrigens, sehr schick.
Macht den Code schlanker und wesentlich übersichtlicher. Chapeau.

Code Auswählen Erweitern


my $di = "PUT:Tuner,Play_Control,Preset,Preset_Sel:Next"

my ($c,$x,$d) = split(":",$di);
my @xa = split(",",$x);
my $data = "<YAMAHA_AV cmd=\"$c\"><".join("><",@xa).">$d</".join("></",reverse @xa)."></YAMAHA_AV>";


Gruß

Radek

Dem möchte ich mich anschließen. Die Idee mit  SendCmd() finde ich ebenfalls echt schick und würde ich bei Gelegenheit auch in YAMAHA_AVR/BD einbauen wollen. Dort müsste ich dann noch eine Erweiterung durchführen um mehrere XML-Knoten unterbringen zu können (für Volume bspw.)

Gruß
Markus

[ra666ack]

Hi Martin,

das neue Bedienkonzept finde ich gut. Exzellente Arbeit.

Könnte sein, dass einige bestehende Scripte bei Usern geändert werden müssten. Mit guter Doku sollte das eher ein Selbstläufer sein.

Einige Themen, die mir nach 15 Minuten auffielen:

* Muss im Reading unbedingt zwischen container 'c_' und item 'i_' unterschieden werden? Ich würde dazu tendieren, die Zeile "as is" aus dem Gerät zu übernehmen
* Die Player Readings (playerLists) müssen durch den html -> utf-8 Konverter
* Bedient man den NP mit einer IR-Fernbedienung, gerät das automatische Abscannen der playerList Zeilen ins Stocken. Auch die aktuelle Position(?) Das Display spielt Verrückt. Evtl. bei externen Display Änderungen das Abscannen unterdrücken.
* Hat man keine DAB/FM Presets definiert (wie bei mir ) wird eine 'et:' bzw. 'et_' im Preset ID angegeben, wenn der Sender manuell gewählt wurde

Wir sollten uns abstimmen, wie die Änderungen in den Code einfließen sollen.

Ciao R.

[martinp876]

Hallo Radek,

die vorige Version hatte Bugs - zu viele Abfragen (schlechte Arbeite - zu früh gepostet).
Hier eine Bessere - ich hofe die stockt weniger.
Hat sich noch einiges geändert - ein sicheres Zeichen, dass ich nicht durch bin.
- die maximale Liste der Playe ist auf unter 100 begrenzt (Netradio war ein guter Test!)
- CD kann ich die Tracks NICHT direkt anwählen
- bei tuner DAB funktioniert das "next/prev nicht

Das mit dem "c_" und "i_" finde ich schick, weil ich erkennen kann ob es ein Lied oder ein container ist. Gerne auch anders, aber erkennen würde ich es gerne.

Auch die aktuelle Position(?) Das Display spielt Verrückt

nun ja - logisch. Ich screene die Liste. Der Player ist ein desaster was die automatische steuerung betrifft. Ich muss immer in happen zu 8 einträgen lesen. Wenn ein dir also 20 einträge hat muss ich 1,9und 17 lesen um es darzustellen. Da zappelt das Display. Mache ich aber nur einmal beim Anwählen eines Level. Danach kann man schalten, wenn man weiss, was man will.

* Hat man keine DAB/FM Presets definiert (wie bei mir ) wird eine 'et:' bzw. 'et_' im Preset ID angegeben, wenn der Sender manuell gewählt wurde

muss ich mir ansehen.
Für die presets speichere ich die Sendernamen. Das mache ich in "." readings. Diese sind nicht sichtbar (ausser mit attr global showInternalValues 1). Macht man ein save werden diese gespeichert und wieder eingelesen.
Ist eine recht üble Angelegenheit, da Yamaha gelegentlich die Station ändert und die ID noch nicht. Habe ich jetzt abgefangen.  (schlechte FW von Yamaha!)
Man muss die Sender anwählen und warten - dann werden die Namen gesetzt.
Wenn du keine presets nutzt ist es wurscht.

Mir fallen sicher noch ein paar Dinge ein -habe mich noch nciht lange damit beschäfftigt.
Wer ist eigentlich der owner? Ich übergeben es bei gefallen selbstverständlich und reihe mich wieder bei den Usern ein.

Gruß Martin

[martinp876]

Hallo
StatusInfo:
ich überarbeite aktuell die Namen der Readings.
Auswählbare Items werden listItemd_xx benannt. Damit gibt es keine playerList_xx oder tunerPreset_xx mehr.
DAB funk/Sende infr werden tunerDAB... genannt. "Ensemble" ist m.E. nicht intuitiv - es ist wohl eigentlich die Sendestation.
Damit erscheinen alle Senderzugehörige Readings in einem Block. Beispiel:

Code Auswählen Erweitern

tunerDABChannel 10C
tunerDABMode DAB+
tunerDABSender Nuernberg
tunerDABSignal 213.360 MHz rate:80 q:89 Stereo

In dieser Richtung muss noch aufgeräumt werden (meine ich jedenfalls)

Falls jemand helfen kann, wie man "next/prev" wirklich nutzen kann ode rbei einer CD die tracks direkt anwählen kann wäre cool.

[ra666ack]

Hi Martin,

habe folgende Themen modifiziert:

* tunerSignalDAB -> 220.352 MHz, 99 %, 80 kbit/s, Stereo
* SendCmd: split habe ich auf 3 chunks begrenz, Es gab Probleme mit clockUpdate und timerSet Befehlen
* timerVolume Abfrage
* timerSet
EDIT: volume Slider korrigiert

Nachdem man timerSet durchgeführt hat, muss man noch die Reading (mit Zeitversatz) refreshen. Der NP muss es noch intern verarbeiten.

[ra666ack]

Hi Martin,

zum Thema Ownership:

Die Idee für das Modul ist vor ca. 2 Jahren entstanden. Da dieser NP eher ein Exot ist, bin ich davon ausgegangen, dass es nicht so schnell einen geben wird, der dieses in FHEM umsetzen würde. Nachdem die Grundfunktionen standen, war die FHEM-Community soweit zufrieden. Der Aufwand hat sich in den letzten 2 Jahren auf vielleicht 5..10 neue Anfragen beschränkt. Ich gehe nicht davon aus, dass die Userzahl zukünftig drastisch anziehen wird. Das NP Protokoll ist ein Ausläufer. Die Geräte werden nicht mehr verkauft.

Hinter deinem neuen Funktionsumfang verstecken sich viele FHEM Spezifika bzw. Perl Know-How.
Manchmal dauert es länger als eine Tasse Kaffee, um den Code zu reviewen

Mit deinem Enthusiasmus und dem "next-level-coding" hätte ich überhaupt kein Problem, das Ownership an dich zu übergeben.
Zumal meine Responsezeiten in 2017, aufgrund "anderer Hobbies", sich (wieder mal) verschlechtern werden.

Ich kann mich gerne nach wie vor als Beta-Tester anbieten und hätte noch das PHILIPS_AUDIO Modul, an dem ich mich austoben kann.

Ich denke, es wäre in Summe effizienter und für das FHEM Projekt qualitativ noch besser.

Gruß

Radek

[martinp876]

Hallo Radek,

anbei meine aktuelle Version. Ich denke ich bin ziemlich durch jetzt. Nachem meine Zeit wieder sehr begrenzt sein wird wird es auch erst einmal stabil bleiben.
Gerne kommentare schicken!!!
Das Commendref ist (schlecht) gepflegt von mir.
Man könnte es einchecken - wenn man die User entsprechend warnt!!!! wie das gehen kann verstehe ich nicht.

Gruß
Martin