Codevorschlag für das YAMAHA_NP Modul

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

Vorheriges Thema - Nächstes Thema

konrad8

Noch 'ne Frage:
Ich habe inzwischen meine CDs in ein paar Stunden zu mp3 gemacht und auf dem Server (QNAP) gelegt. Vom CRX kann ich drauf zugreifen. Im Display ist mir das zu mühsam :-), also habe ich mit dem (neuen) FHEM/YAMAHA_NP draufgeschaut. FHEM läuft auf dem QNAP, PC mit Firefox auf Standard FHEM Interface, ich kann auswählen:
Serverwahl
Music
Artist
ich bekomme von Baum (1-3), A-ha (4) bis Ella Fitzgerald auf (96)  alles angezeigt, mit etwas Verzug und nachlesen, OK. Greife ich per Yamaha NP APP von iPhone oder Android auf den CRX direkt zu, bekomme ich 398 Einträge, der letzte mit "Z..." , vermutlich ist das der ganze Satz.

Also den Ethernet Link mit Wireshark angeschaut, ich kann sehen, dass bei FHEM blockweise (immer 8) Einträge der Liste gelesen werden. Das geht wie gesagt bis 96. Im Request steht kein Offset drin, sondern es scheint immer das nächste anliegende Paket vom CRX zu kommen. In der Antwort steht eine Cursor_Line (89)  und Max_Line (398) drin.

Wie die Signatur (-> Newbie) schon sagt, darf ich fragen ... Ich finde die Begrenzung im Yamaha_NP Modul nicht, noch nicht einmal die Schleife. Könnte man die Schleife aufbohren? Ich glaub in Summe hab ich sowas wie 1500 Songs auf dem Server... hab schon die ganzen Kinderhörspiele aus dem Server rausgenommen.

martinp876

Nun, es dauert etwas. Leider.
Ich habe die Liste auf 2 stellen begrenzt, also 100 Einträge.
Ich kann das auf 1000 erhöhen. Das sind jede Menge. Für eine grosse Bibliothek reicht auch das nicht.
Wir reden hier nicht von einer Datenbank,.
Vielleicht kannst du die CDs gruppieren?
Ich werde einmal 1000 einrichten, also 3stellig

martinp876

so, einen neue Version.
Die maximale Anzahl "items" ist jetzt 999. Bei netradion new york komme ich auf 890... klappt, dauert.

Favoriten sind implementiert. favPlay, favDelete, favDefine und get favList
Sind sicher noch bugs drin.

Das Ansteuern eines Favoriten (auch directPlay, ist ja das gleiche)  kann es zu einem timeout kommen. z.B. wenn die 890n sender aus NY geladen werden müssen.
man kann die Anzahl versuche einstellen:
attr  searchAttempt

default 15, hat bei mir mit 50 funktioniert.
man kann, sollte das ziel nicht errelicht werden, das kommando neu absetzen. Dann geht die Suche weiter, startet nicht neu.


konrad8

Hallo Martin,
ich sehe  nun meine 398 Artists - danke
Die 1000 erreiche ich auch bei "All_Songs"
Um die Liste final zu bekommen bzw das Submenu für SelStream zu alignen, muss ich immer noch einen StatusRequest/PlayerStatus hinterherschicken. Vom Gefühl bei mir, 100 Mbit Link  zwischen CRX und QNAP, war das nicht so langsam. 

Eigentlich muss die Abfrage eine beliebige Anzahl können, der MediaServer auf dem QNAP veröffentlich auch eine Liste "All_Songs", und die kann beliebig groß werden - naja...
Auf der anderen Seite macht es wenig Sinn, 10000 Einträge durchzublättern.
Geht so was:
a) eine ABC sortierte Liste, die man dann auch entsprechend selektieren kann (evtl per Reiter, das wäre aber vermutlich ein neues Modul in FHEM, so eine Anzeige zu erzeugen)
b) ein Pattern, so dass FHEM die ganze Liste nochmal liest und nur die "matching Entries" in die Liste nimmt? (dito)

Ich denke, das Problem ist mehr die Präsentation der Daten und weniger das Retrieval.

konrad

martinp876

Hallo Konrad,
ich habe noch etwas nachgebessert...

Die Reaktionszeit: Ich kann nicht erkennen, dass der Yamaha player am Tablet die Liten schneller erstellt - allerdings gefühlt nicht gemessen.
Das Problem ist nicht die Übertragungsrate sondern die Reaktionszeit des Players. Das könnte viel(!!!) schneller gehen, wenn der player ein ordentliches Interface hätte.
Meine Implementierung macht es kaum langsamer. Ich muss die Liste in Paketen zu 8 abholen. wenn die da sind hole ich die nächsten. schneller geht nicht - hier habe ich keine Wartezeit.
ZitatAuf der anderen Seite macht es wenig Sinn, 10000 Einträge durchzublättern.
ja... und nein. Ich sehe das Problem, habe aber keine Lösung. Alles zu lesen bei 10000 sprengt das vorhaben. Eigentlich müsste man filtern können. Kann ich aber nicht, da ich die Inhalten nicht kenne.
Mein Vorschlag ist, die Daten zu groupieren. Ich habe meine in ordnern untergebracht.

ZitatGeht so was:
a) eine ABC sortierte Liste, die man dann auch entsprechend selektieren kann (evtl per Reiter, das wäre aber vermutlich ein neues Modul in FHEM, so eine Anzeige zu erzeugen)
b) ein Pattern, so dass FHEM die ganze Liste nochmal liest und nur die "matching Entries" in die Liste nimmt? (dito)
nein. dazu muss ich erst alles gelesen haben - sonst kann ich nicht filtern. Die Sortierung muss von Server vorgenommen werden. Ich teste mit Kodi und Squeezebox auf der gleichen Datenbasis. Beispielsweise kann man hier nach Jahrgängen sortieren.

Fakt ist, dass man eine wirkliche Datenbank (>10k Lieder) so nicht managen kann oder konnte.

Wenn FHEM die Lieder kennt und man über ein Frontend dann diese ansteuern kann wäre dies eine Lösung.
Allerdings kenne ich hier kein interface. man muss sich runter hangeln.

Ich probiere gerade squeezebox. Hier kann ich bspw suchen. dann bekomme ich ein Lied mit Speicherort. über diesen sollte ich das Lied ansteuern können.

Also: Das Interface steht (sicher noch Bugs...)
Speed ist kaum zu verbessern
Timeout könnte ich auf timer umstellen - aktuell sind es retrys.
Frontend könnte Ansteuerung übernehmen. sollte ein Interface zu squeeyebox oder kodi geschaffen werden kann man über dies ein directplay basteln und abschicken.

Insgesamt sehe ich keine versclechterung zur vorversion (ausser die Doku - die werden ich nie erreichen)

wie machen wir weiter? Soll es einmal offiziell werden? Meine Meinung ist klar - aber was sagt die Nutzergemeinde?

Gruß Martin

ra666ack

Hi Martin,

interessanterweise habe ich keine Benachrichtigungen zu neuen Antworten im Thread bekommen!?
Teste das Modul.

Radek


tomster

Ich hätte schon reagiert, hab aber gerade keinen Laptop. Der reist seit einiger Zeit als Teil einer "lost baggage" in meinem Koffer irgendwo durch die Welt. Vom Handy aus mit putty isses wirklich nicht mal halbgeil um mit FHEM was zu machen...
Ich teste aber alsbald ich wieder kann, versprochen!

ra666ack

Hi Martin,

Habe beim Tuner zwein Sachen korrigiert, was auf fehlerhafte Firmware des NP zurückzuführen ist.

Sind keine Presets gespeichert, wird "tunerPreset" gelöscht.
Wird manuell andere Frequenz gewählt, meldet der NP trotzdem, dass es sich um ein Preset handelt. In diesem Fall wird der litItem_XXX Preset mit dem aktuell eingestellten verglichen und gelöscht bzw. richtig angezeigt.

Die max. Anzahl an "listItems" beim Server könnte man per Attribut erschlagen. Default-wert. Falls jemand mehr möchte, kann das gerne tun.

(TwonkyServer clustert die Musik von sich aus in kleinere Chunks z.B. ABC, DEF, usw.)

Radek


   

Ampheus

Ich nutze seit einigen Tagen erfolgreich das YAMAHA_NP Modul mit einem CRX-N560D. Erst mal herzlichen Dank für das Modul.
Die YAMAHA Anlage ist mit einer YAMAHA YWA-10 WLAN Brücke an Netzwerk angebunden und das funktioniert soweit eigentlich stabil (beim streaming). Allerding sehe ich im FHEM Protokoll sporadisch Fehlermeldungen wie

2017.02.22 13:31:35 3: YAMAHA_NP (KUECHENRADIO) - could not execute command on device KUECHENRADIO. Please turn on your device in case of deactivated network standby or check for correct hostaddress.
2017.02.22 13:32:41 3: YAMAHA_NP (KUECHENRADIO) - device KUECHENRADIO reappeared


Es scheint so, also ob gelegentlich die polls ins leere Laufen. Gibt es da Erfahrungen? Wird ein poll wiederholt oder sofort das Gerät auf unerreichbar gesetzt? Ein retry-counter wäre gut .... Vermute aber fast es liegt am YWA-10...

Noch eine zweite Sache - ich schalte über ein Notify. D.h. der an/aus Zustand folgt dem Zustand der Schaltsteckdose des Subwoofers. Dabei möchte ich beim einschalten aber auch immer erst mal auf einen definierten Eingang umschalten (Alexa). Mit ist aufgefallen, dass dies nicht im gleichen notify funktioniert. Es kommt immer eine Fehlermeldung dass das Gerät noch aus ist. Auch ein sleep zwischen an und umschalten scheint nicht zu helfen. Es scheinen alle Befehle "on block" raus zu gehen, der Yamaha braucht aber wohl ein paar hundert Millisekunden nach dem Einschalten bis er auf Umschaltbefehle reagiert, richtig? Sende den Umschaltbefehl jetzt via Notify wenn der YAMAHA Zustand auf an geht. Leider passiert das halt wegen oben beschriebenem Problem gelegentlich auch mitten im laufenden Betrieb und der schaltet dann einfach den Eingang um (ärgerlich, wenn man z.B. manuell am Gerät auf etwas anderes geschaltet hatte).

Gruß
Thomas.

ra666ack

Hi Ampheus,

kann man davon ausgehen, dass du mit der eingecheckten Version arbeitest?
Aktuell wird das Modul massiv überarbeitet und noch benutzerfreundlicher gemacht (s. mein letzter Post).

Bei deinem ersten Problem fürchte ich spielt die WLAN Bridge eine Rolle. Der Timeout ist default auf 4 Sekunden gesetzt, was mehr als Genug sein sollte. Du könntest mit dem Attribut 'request-timeout' den Wert erhöhen. Sollte aber nicht die Lösung sein. Mit Wireshark könnte man den Traffic beobachten.

Auch hier gehe ich davon aus, dass aus dem Standby hochgefahren wird und nicht hart über die Steckdose eingeschaltet. Die Abfragefrequenz on/off wird durch die Parameter bei der Gerätedefinition bestimmt. Worst case kann es tatsächlich so lange dauern, bis der Zustand umgeschaltet wird. Ich denke, der NP muss auch noch booten, bis er nach den einschalten ansprechbar. Die Kommunikation ist asynchron und non-blocking. Heißt die Pakete gehen raus und der nächste Befehl kann abgearbeitet werden. Die Rückmeldung generiert einen Callback. Kommt innerhalb des timeouts nichts zurück, wird auf off/not available umgeschaltet.

Gruß

Radek

Ampheus

#85
Hallo Radek,

Danke für Deine Antwort. ja, ich arbeite mit der aktuell eingecheckten Version. Ebenso hängt die Anlage fest am Stromnetz, also es wird aus Standby eingeschaltet. Die Netzwerkbridge bekommt ihren Strom via USB von der Anlage (ist ja von Yamaha so vorgesehen)

Ich werde mal den Timeout erhöhen und schauen was passiert und vielleicht das ganze auch mal temporär an ein 15m Netzwerkkabel hängen. Denke auch es ist die Bridge.

Was ich beim anschalten halt versucht habe, ist so etwas

define N_KuechenRadioFollowSubWooferAn notify FS20_6e1c28:on {fhem("set KUECHENRADIO on");;("set KUECHENRADIO input aux1")}

Das führt immer zu einer Fehlermeldung (sinngemäß: Gerät ist aus oder nicht erreichbar). Der "an" Befehl wird ausgeführt, der AUX1 Umschaltbefehl aber nicht. Auch ein Sleep zwischen den beiden Befehlen hilft nicht.  Mache diese Verrenkung, weil der Subwoofer via Schaltsteckdose über Alexa gesteuert wird und das Radio dann einfach mit angehen soll. Habe es bislang nicht hinbekommen alles (Schaltdose und Yamaha) über Alexa-fhem (und dann Gruppenbildung in der Alexa App) zu steuern. Der Yamaha nimmt (noch?) keinen "AN"/"AUS" Befehl von Alexa, richtig?

Gruß
Thomas.

ra666ack

#86
Hi,

anbei eine aufgeräumte und etwas mehr kommentierte Version für "Hobby Coder" wie mich  :)
Inklusive Englischer Doku. Deutsch folgt.

Ampheus, ich habe vor, die Version 2 offiziell einzuchecken. Bevor wir an der alten rumdoktern, könntest du die angehängte bei dir installieren?
Die Usability is deutlich besser.

Danke und Gruß

Radek

tomster

#87
Das Modul lädet, aber beim Versuch das Device anzulegen, meldet FHEM nur "0". Es wird zwar angelegt, scheint aber keine Aktualisierungen zu bekommen.

Internals:
   CFGFN
   CHANGED
   DEF        192.168.5.25
   FIRMWARE   1.12/1.01
   FRIENDLY_NAME CRX-N560D 87ED4
   MODEL      CRX-N560D
   NAME       YAMAHA
   NR         319
   NTFY_ORDER 50-YAMAHA
   STATE      ???
   TYPE       YAMAHA_NP
   Readings:
   Helper:
     ADDRESS    192.168.5.25
     AVAILABLE  1
     DISABLED   0
     INPUTS     AUX1|AUX2|AirPlay|CD|DIGITAL1|DIGITAL2|NET RADIO|SERVER|Spotify|TUNER|USB
     OFF_INTERVAL 30
     ON_INTERVAL 30
     Dinfo:
       DEFAULT_GATEWAY 192.168.5.1
       DNS_SERVER_1 192.168.5.1
       DNS_SERVER_2 0.0.0.0
       FRIENDLY_NAME CRX-N560D 87ED4
       IP_ADDRESS 192.168.5.25
       MAC_ADDRESS 00:A0:DE:A8:7E:D4
       NP_ICON_1  http://192.168.5.25:8080/BCO_device_sm_icon.jpg
       NP_ICON_2  http://192.168.5.25:8080/BCO_device_lrg_icon.jpg
       NP_ICON_3  http://192.168.5.25:8080/BCO_device_sm_icon.png
       NP_ICON_4  http://192.168.5.25:8080/BCO_device_lrg_icon.png
       SUBNET_MASK 255.255.255.0
       SYSTEM_ID  02B984D3
       UNIQUE_DEVICE_NAME 5F9EC1B3-ED59-1900-4530-00A0DE1B0FFF
     Fav:
       Dab:
         input      DAB
         stream
       Fm:
         input      FM
         stream
       Airplay:
         input      airplay
         stream
       Aux1:
         input      aux1
         stream
       Aux2:
         input      aux2
         stream
       Cd:
         input      cd
         stream
       Digital1:
         input      digital1
         stream
       Digital2:
         input      digital2
         stream
       Netradio:
         input      netradio
         stream
       Server:
         input      server
         stream
       Spotify:
         input      spotify
         stream
       Usb:
         input      usb
         stream
     Pl:
     Statreq:
       getInputs  0
       mediaRendererDesc 0
       networkInfo 0
       systemConfig 0
Attributes:
   model      CRX-N560D
   searchAttempts 15


Beim Anlegen des Devices wurde anscheinend auch attr .DVBlist und .Favlist (oder so ähnlich) angelegt. Als ich diese beiden Zeilen aus der fhem.cfg gelöscht habe und neugestartet habe, ging es. Läuft jetzt. Werde testen und berichten.

tomster

Was mir im Bezug auf eine Einbindung in FTUI aufgefallen ist:

Wäre es nicht evtl. sinnvoll ein Reading zu haben, in dem der aktuelle Device-Status komplett steht? Soll meinen, dass z.B. in input auch der Status "off" erscheint, wenn der Yamaha aus ist, oder in STATE neben on/off FM, netradio, CD, etc.
Ich hab das bislang immer über ein eigenes UserReading gemacht. Ist aber jetzt weg nach Neu-Anlage ;-)

Ampheus

#89
Hallo Radek,

vielen Dank für die neue Version. Habe ich gleich mal ausprobiert.

Also, zum einen meine Leitung ist jetzt stabil. War tatsächlich das YWA10. Habe jetzt einen Fritz Repeater als Lan Brücke und es gibt keinerlei Abbrüche zum Radio mehr. (Auch schon im alten Modul).

Beim neuen Modul ist mir aufgefallen, dass der Regler für die Lautstärke sich komisch bewegt. Wenn ich ihn auf eine neue Lautstärke ziehe, dann bewegt er sich zwar langsam auf den neuen Wert, aber er alteriert ständig rum, sieht aus wie ein hin und herfahren (also der Slider "wackelt" so langsam zum neuen Wert). Das passiert auch, wenn der Wert per set Kommando geändert wird. Manchmal kommt er auch nicht exakt auf dem geforderten Wert zum stehen sondern ein oder zwei Werte daneben. Das war vorher nicht. Das ging viel flüssiger. 

Das neue Modul verhält sich leider in meinem Use-Case genau wie das alte. Es scheint zu schnell zu sein. Eigentlich denke ich, dass ich keinen komplizierten use case habe. Ich möchte das Radio anschalten und zusätzlich Lautstärke und Input setzen. Ich habe es extra schon in zwei Notifies auseinandergenommen in der Hoffnung etwas Zeit zu schinden.

Also, wie gesagt, ich möchte mit dem Küchenradio dem Zustand einer Schaltsteckdose folgen. Das sollte eigentlich gehen wie folgt:

define N_KuechenRadioFollowSubWooferOn notify FS20_6e1c28:on {fhem("set KUECHENRADIO on");;;;fhem("set KUECHENRADIO input aux1");;;;fhem("set KUECHENRADIO volumeStraight 30");;;;fhem(Log 1, "Kuechenradio on Macro ausgeführt")}
define N_KuechenRadioFollowSubWooferOff notify FS20_6e1c28:off set KUECHENRADIO off


Leider funktioniert es nicht. Ich muss 3 mal den an Befehl an die Schaltsteckdoes senden, bis alles ausgeführt ist (also Radio an , auf richtigem Eingang und Lautstärke). Das Logfile liefert:

2017.02.25 09:56:58 3: FS20 set FS20_6e1c28 on
2017.02.25 09:56:58 3: set KUECHENRADIO volumeStraight 30 : Power on the device first.
2017.02.25 09:56:58 1: Kuechenradio on Macro ausgeführt
2017.02.25 09:56:58 3: YAMAHA_NP (KUECHENRADIO) - Could not execute "input aux1"
2017.02.25 09:57:00 3: FS20 set FS20_6e1c28 on
2017.02.25 09:57:00 3: set KUECHENRADIO volumeStraight 30 : Power on the device first.
2017.02.25 09:57:00 1: Kuechenradio on Macro ausgeführt
2017.02.25 09:57:02 3: FS20 set FS20_6e1c28 on
2017.02.25 09:57:02 1: Kuechenradio on Macro ausgeführt




Mein Workaround sieht im Moment aus wie folgt:

define N_KuechenRadioFollowSubWoofer notify FS20_6e1c28 set KUECHENRADIO $EVENT
define N_KuechenRadioAnInputAUX1 notify KUECHENRADIO:an {fhem("sleep 0.5");;;;fhem("set KUECHENRADIO input aux1");;;;fhem("set KUECHENRADIO volumeStraight 30");;;;fhem(Log 1, "Kuechenradio AUX1/Vol Macro ausgeführt")}


Damit funktioniert es. Das Logfile wirft allerdings auch einiges an Warnungen

2017.02.25 10:02:38 3: FS20 set FS20_6e1c28 on
2017.02.25 10:02:38 1: WARNING: sleep without additional commands is deprecated and blocks FHEM
2017.02.25 10:02:39 3: set KUECHENRADIO volumeStraight 30 : Power on the device first.
2017.02.25 10:02:39 1: Kuechenradio AUX1/Vol Macro ausgeführt
2017.02.25 10:02:39 1: WARNING: sleep without additional commands is deprecated and blocks FHEM
2017.02.25 10:02:40 1: Kuechenradio AUX1/Vol Macro ausgeführt
2017.02.25 10:02:40 3: YAMAHA_NP (KUECHENRADIO) - Could not execute "input aux1"


Was ich nicht verstehe, warum das Macro offenbar zwei mal ausgeführt wird. Das scheint vermutlich am Sleep zu liegen. Wenn ich den weg lasse, dann funktioniert es nicht.

Wäre schön, wenn wir die erste Variante zum Laufen bekommen könnten. Vielleicht ist ja auch nur mein Code falsch. Weil die halt auch unabhängig davon ist, ob das Radio zwischendurch mal kurz den Connect verliert.

Viele Grüße
Thomas.