Modul für Yamaha Musiccast

Begonnen von Pythonf, 20 Juni 2016, 10:28:46

Vorheriges Thema - Nächstes Thema

kilderman

Hallo zusammen,

ich habe für mein Problem nun einmal die Zeile, in der die API_Version gesetzt wird, (Zeile 2825) im Modul auskommentiert bzw. stattdessen durch

$url =~ s/v1/v2/g;

ersetzt und nun es geht nun in FHEM auch für meinen Musiccast 20. Prima, vorerst.... ;-) Aber da die Zeile bestimmt auch ihre Berechtigung hat, vielleicht kann man den Wert der API-Version noch zuvor mit ([v0-9]+)(?=\.) oder etwas ähnlichen bearbeiten, so dass nur der Wert vor dem Punkt genommen wird?

Viele Grüße

kilderman

Hallo Tobi73,

bei mir wird API_Version v2.02 angezeigt.

Viele Grüße und vielen Dank für's Anschauen

tobi73

Hallo kidermann,

ja, so würde ich es auch lösen. Evtl. ist die Rückgabe der API-Version nicht bei allen Yamaha-Geräten konsistent.  Bei mir klappt es, wobei vom Gerät als die System Version 2.09 ist und als API Version die 2 zurückkommt.
Kannst du mal posten was im im Browser die URL
http://xxx.xxx.xxx.xxx/YamahaExtendedControl/v1/system/getDeviceInfo
bringt?

Gruß
Tobi

kilderman

Hallo Tobi,

gerne doch. Das wird im Browser ausgegeben:

response_code 0
model_name "WX-021"
destination "G"
device_id "AC21D7944474"
system_id "0DA87303"
system_version 1.54
api_version 2.02
netmodule_generation 2
netmodule_version "0503    "
netmodule_checksum "17ACAA08"
serial_number "Z4Z2Z29TT"
category_code 6
operation_mode "normal"
update_error_code "00000000"


Hilft das?

Viele Grüße und vielen Dank
Marco

rubbertail

Hi Tobi,

sorry, war länger nicht da... so sieht das dann bei mir aus:


response_code 0
model_name "WX-021"
destination "G"
device_id "4C1B867E2D0A"
system_id "0DA87303"
system_version 1.54
api_version 2.02
netmodule_generation 2
netmodule_version "0503    "
netmodule_checksum "15ECEF06"
serial_number "Z430678VX"
category_code 6
operation_mode "normal"
update_error_code "00000000"


Danke!
Martin
FHEM auf Raspi, CUL433, CUL868, RFXTRX433e, CULCuBE
FRITZ: Fritzbox7590AX, 6xFritzDECT301, 10xFritzDECT200, FritzRepeater 6000
MAX!: Fensterkontakte
netatmo: Wetterstation & Thermostat
Milights, IT, Withings, HUE

tobi73

Hallo zusammen,

ok, sieht tatsächlich so aus, als dass bei einigen Geräten die API Version ein dot-release ist und das auch so gemeldet wird. 

Ich bin nicht der Autor des Moduls und sollte da nicht dran rumpfuschen. Hab's aber trotzdem mal gemacht und an den Stellen, an denen die URLs mit dem Internal ,,API_VERSION" zusammengebaut werden, kleine Korrekturen eingebaut. Simpel: der ,,." und alles danach wird abgeschnitten. Ich hoffe, dass diese Logik der Idee der Yamaha Entwickler entspricht...
Übrigens: Einen Befehl zum direkten Anwählen von Net-Radio Favoriten (setNetRadioPreset) habe ich auch aufgenommen.

@Leugi: einhängen will ich das hier nicht, weil: siehe oben (bin nicht Autor). Magst du die Version haben, dann kannst du sie weiterentwickeln und wenn's mal soweit ist offiziell ins git repository stellen? Du hattest ja die letzten Änderungen gemacht? Schick sie dir gerne per PM.

@rubbertail und kidermann: Kann sie euch auch gerne per PM senden zum Testen.  Aber alles ohne Gewähr – Perl und seine Regex sind nicht wirklich ,,meins" - Also bitte nicht schimpfen wenn's nicht richtig funktioniert ;D Im Zweifelsfall auf die letzte Version zurückfallen.

Gruß
Tobi

tobi73

Hallo zusammen,

entweder bin ich blind und finde die Funktion nicht, oder man kann per PM tatsächlich keine Anhänge senden.

Da einige von Euch direkt bei mir angefragt haben, häng ich das von mir geänderte Modul unten ein. Wie oben geschriebenem, ohne Gewähr. Bei Problemen (oder auch Erfolg  ;)) gerne melden - aber im Zweifele die alte Version wieder einspielen.
Vielleich liest das hier ja auch der Modul-Owner und nimmt die Änderungen in die dann irgendwann mal offiziell werdende Version auf...

Grüße
Tobi

nerdy

I read this thread 2 times and found that after registration there is a attachment visible! Great.
I'll checkout it now, and will use it instead of HTTPMOD (which is perfect for simple REST-api).
raspberry PI, FHEM (FritzBox, pilight, zwave, nut, amad, telegramBot, Kodi, smart)

ToKa

Guten Morgen,

ich habe folgende Fehlermeldung im fhem Log:
2019.01.20 10:19:33 2: YAMAHA_MC: E1_wz_AV_CDNT670D YAMAHA_MC_httpRequestParse last cmd=getPlayInfo failed with error: read from http://192.168.6.33:80 timed out
2019.01.20 10:19:33 2: YAMAHA_MC: E1_wz_AV_CDNT670D YAMAHA_MC_httpRequestParse guessing device is absent, setting state and power to off
2019.01.20 10:19:33 2: YAMAHA_MC (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.


Ich kann mir das nicht erklären, da das Gerät aktuell in Betrieb ist und Musik läuft. Auch Network Standby ist aktiviert.

Hat jemand eine Idee,was da schief läuft bzw. Wie ich die Meldung los werde?

Beste Grüße
Torsten
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

tobi73

Hallo Torsten,

funktioniert die Seuerung über FHEM grundsätzlich und kommt dieser Fehler nur sporadisch?
Wenn von FHEM gar nichts funktioniert: Ist das Gerät vom Netz aus überhaupt erreichbar? Also kommst du auf die Weboberfläche unter
http://192.168.6.33

Und wenn ja, was bringt:
http://192.168.6.33/YamahaExtendedControl/v1/system/getDeviceInfo

Gruß Tobi

ToKa

Hallo Tobi,

ja das Gerät lässt sich über fhem ansprechen und steuern. Da die Meldung ca.alle 5 Minuten protokolliert wird, bläht sich das Log auf. Das Ergebnis der Abfrage lautet
{response_code":0,"model_name":"CD-NT670D","destination":"BG","device_id":"00A0DED60BCC","system_id":"03EA7FA3","system_version":2.10,"api_version":2.00,"netmodule_generation":1,"netmodule_version":"1784    ","netmodule_checksum":"11679F74","operation_mode":"normal","update_error_code":"00000000"}


Grüße Torsten
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

tobi73

Hall Torsten,

ok, dann funktioniert es ja prinzipiell. Das Problem, dass das Gerät hin und wieder nicht erreichbar ist, habe ich auch. Ich weiß nicht, ob das ein prinzipielles Problem der Yamaha Geräte ist oder mit meinem bzw. unserem Setup zusammenhängt. Vermute aber eher ein prinzipielles Thema.

Das FHEM-Modul arbeitet scheinbar so, dass beim ersten nicht-Erreichen des Gerätes davon ausgegangen wird, dass es nicht mehr am Netz hängt und als ,,absent" und ,,off" gemeldet wird. Entsprechend wird der Logeintrag produziert.

Ich habe mir via Wireshark den IP Verkehr zwischen Yamaha und der Music Cast App auf dem Smartphone mal kurz angesehen Die Music Cast App bei Android arbeitet da ,,penetranter" und fraget viel öfter den Status ab.  Auch, wenn mal keine Antwort vom Gerät kommt. Um sicher zu sagen wie das funktioniert, müsste man den Verkehr aber genauer auf TCP und IP Layer analysieren.

Um das prinzipiell zu lösen, müsste jemand das Modul umstricken, so dass es bei einmaliger Nichterreichbarkeit kein ,,absent" annimmt – so ähnlich wie es die App macht. Leider scheinen die Autoren den Thread nicht zu verfolgen, daher weiß ich nicht ob dass je gemacht wird und das Modul überhaupt noch weiterentwickelt wird. Mal sehen...

Wenn's erstmal "nur" darum geht, die Logeinträge zu vermeiden, kannst Du das Attribut "verbose" des Moduls (nicht global!) auf 0 stellen. Dann sollte das Modul log mäßig stumm sein und diese Meldungen nicht mehr kommen. Natürlich auch keine anderen.  Löst das Grundproblem aber natürlich nicht.

Gruß
Tobi

ToKa

Hallo Tobi,

die Meldung kommt nur, wenn das Gerät an ist und ich darüber Musik abspiele. Scheinbar versucht das fhem Modul dann regelmäßig alle 5 Minute mit getPlayInfo etwas abzufragen.

Werde mit verbose das ganze etwas eindämmen und hoffe, der Modulautor liest mal wieder bzw. hoffe, das ansonsten tolle Modul wird weiterentwickelt.

Beste Grüße
Torsten
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

tobi73

Hallo Torsten,

ja, wenn im Define nichts anderes eingestellt wurde, pollt das Modul den aktuellen Status des Gerätes im eingeschalteten Zustand alle 60, im ausgeschalteten alle 120 Sekunden. Wenn du bspw. am Gerät oder per App die Lautstärke änderst oder eine andere Quelle auswählst, merkt das FHEM im worst case erst nach 60 Sekunden. Und ein Einschalten des Gerätes erst nach 120 Sekunden.

Diese Statusabfrage geht -bei mir auch- ab und zu schief. Heißt, es kommt keine Antwort auf den Request. Insbesondere wenn ich Musik über das Netz höre (vom Server, Naptser oder NetRadio). Bei DAB, Bluetooth, AUX weniger. Könnte damit zu tun haben, dass der Prozessor bzw die Software der Yamaha bei hoher Last den Datenverkehr für die Musik priorisiert und eine Statusabfrage einfach mal unbeantwortet bleibt. Und könnte auch der Grund sein, dass das Navigieren per FHEM durch die Menüs manchmal träge und unzuverlässig funktioniert. Interessant wäre, ob andere Nutzer auch dieses Problem haben.

Aber wie geschrieben, dazu muss man das auf Protokollebene mal genauer analysieren und mit dem Verhalten der Yamaha APP vergleichen. Habe ich mir mal vorgenommen, aber im Moment fehlt mir leider die Zeit. Und Erfahrung hab ich damit leider auch nicht viel...

Ich experimentiere gerade etwas rum, am Modul Änderungen zu machen, die bei Timed-out Fehlern eine bestimmt Anzahl retrys macht, bevor das Modul ein absent des Gerätes annimmt. Ist momentan aber noch nicht wirklich soweit, als dass ich es irgendwem als Lösung anbieten möchte.

Gruß
Tobi

RockThisParty

Moin in die Runde!

Toll, dass hier gerade etwas Leben in die Entwicklung kommt  :)

Ein kleiner Hinweis: Ich hatte auf der Suche, nach Möglichkeiten das Modul zu optimieren, irgendwo den Hinweis gefunden, dass Geräte den Status abonnieren können und dann per ?UDP? geschickt bekommen, ohne überhaupt pollen zu müssen.

Einerseits würde das die Befehls-Queue von FHEM deutlich entlasten, andererseits wäre damit wohl das Modul fast komplett neu zu schreiben. Dafür reichen bei mir leider derzeit weder Zeit noch Perl-Kenntnisse  :-\

Viele Grüße,
Stefan