Hallo Markus! ;)
Hallo alle anderen! :)
ich versuche gerade das Yamaha AVR Modul zum laufen zu bekommen. Leider funktioniert es nicht.
Das Modell ist ein Yamaha RX-A 1030.
Eingerichtet über:
define WZ_AVR YAMAHA_AVR 192.168.11.41
define WZ_AVR YAMAHA_AVR 192.168.11.41 mainzone
define WZ_AVR YAMAHA_AVR 192.168.11.41 mainzone 60 10
alle Varianten führen zu dem gleichen Ergebnis.
Eingesetzte Versionen:
# $Id: 71_YAMAHA_AVR.pm 6074 2014-06-05 21:53:17Z markusbloch $
# $Id: HttpUtils.pm 6067 2014-06-05 08:04:57Z rudolfkoenig $
Nun zu den Fehlern die ich bekomme:
Der AVR ist immer absent. Das Modul scheint keine Verbindung herstellen zu können.
Dazu kommt wenn das Modul läuft, dann habe ich keinen Zugriff mehr auf das Web Interface des AVR. Ich bekomme dann immer Timeouts bis ich das Device in FHEM lösche. Ca. 5 Minuten später reagiert das Web Interface wieder normal.
Im Log sehe ich immer folgende Zeilen
2014.06.20 16:18:07 5: HttpUtils url=http://192.168.11.41/YamahaRemoteControl/ctrl
2014.06.20 16:18:07 5: YAMAHA_AVR (WZ_AVR) - could not execute command "statusRequest unitDescription": connect: A non-blocking socket operation could not be completed immediately.
2014.06.20 16:18:07 5: YAMAHA_AVR (WZ_AVR) - execute nonblocking "statusRequest systemConfig" on WZ_AVR: <YAMAHA_AV cmd="GET"><System><Config>GetParam</Config></System></YAMAHA_AV>
Das Webinterface zeigt folgenden Fehler in der Textbox:
Can't find string terminator '"' anywhere before EOF at (eval 195) line 1.
(http://i.imgur.com/CvKdDx5.png)
In der Dropdownbox steht folgendes:
(http://i.imgur.com/hFlTXX3.png)
Vielleicht hilft das ja beim Debuggen. Ich habe leider nichts gefunden, aber meine Perl Kentnisse sind auch unterirdisch ;)
Wenn ich noch weitere Informationen liefern kann einfach bescheid sagen.
Vielen Dank im voraus,
Sascha
P.S.: Ich hoffe das ist das richtige Forum hier. Ansonsten bitte ich um Entschuldigung!
Hallo Sascha,
dass kann mehrere Gründe haben:
- Dein Receiver ist aus (standby) und "Network Standby" ist nicht aktiviert. Dann wird die Netzwerkschnittstelle runtergefahren und der Receiver ist nicht mehr erreichbar
- Die IP-Adresse ist falsch (evtl. Tippfehler)
- Der Receiver ist komplett stromlos
Schau doch einfach nochmal nach.
Gruß
Markus
Hallo Markus,
leider alles nicht.
Der Receiver ist an, lässt sich pingen und auch über EventGhost steuern. Wenn es so einfach wäre hätte ich mir nicht die Mühe gemacht Dir die ganzen Infos rauszusuchen ;)
In meinem ersten Post schrieb ich:
ZitatDazu kommt wenn das Modul läuft, dann habe ich keinen Zugriff mehr auf das Web Interface des AVR. Ich bekomme dann immer Timeouts bis ich das Device in FHEM lösche. Ca. 5 Minuten später reagiert das Web Interface wieder normal.
Lass mich das noch ein wenig präzisieren.
Ich gehe auf das Webinterface vom Verstärker bevor ich den AVR im FHEM define. Da funktioniert alles.
Sobald ich den define im FHEM abgesetzt habe, kann ich das Webinterface nicht mehr bedienen. Der Browser zeigt mir dann auch Time outs. Erst nachdem ich im FHEM alles wieder gelöscht habe und ca. 5 Minuten warte, reagiert das Webinterface wieder normal. Ein PING geht die ganze Zeit.
Gruß,
Sascha
Hallo Sascha,
das bringt mich leider alles nicht weiter,
basierend auf dem Logoutput, was du in deinem ersten Post erwähnt hast:
2014.06.20 16:18:07 5: HttpUtils url=http://192.168.11.41/YamahaRemoteControl/ctrl
2014.06.20 16:18:07 5: YAMAHA_AVR (WZ_AVR) - could not execute command "statusRequest unitDescription": connect: A non-blocking socket operation could not be completed immediately.
2014.06.20 16:18:07 5: YAMAHA_AVR (WZ_AVR) - execute nonblocking "statusRequest systemConfig" on WZ_AVR: <YAMAHA_AV cmd="GET"><System><Config>GetParam</Config></System></YAMAHA_AV>
Sehe ich, dass FHEM keine Verbindung zum Receiver aufbauen kann. Warum das so ist, kann ich so nicht erkennen. Ich weis aber, dass der RX-A1030 mit meinem Modul funktioniert.
Evtl. veraltete Firmware? Evtl. veraltetes Perl?
Gruß
Markus
Komische Sache...
also mein PERL ist Strawberry Perl PDL 5.20.0.1-32bit (ist die aktuelle)
die Firmware vom Yamaha habe die Tage erst geupdated. Das sollte Verion 1.41 sein.
Ich habe noch eine EGPMLAN Steckdose die über LAN auch funktioniert. Das Interface dort ist eigentlich auch HTTP, weswegen ich bis jetzt das PERL als solches nicht im Verdacht hatte.
Gruß,
Sascha
Mach doch mal ein "telnet <IP> 80", um zu gucken, ob der AVR überhaupt Verbindungen auf Port 80 annimmt. Das Module benutzt doch TCP auf Port 80 (http), oder?
Telnet brauche ich nicht versuchen. Da ich das Web Interface benutzen kann, antwortet der AVR auch entsprechend. Ja, es ist HTTP und Port 80.
So, ich habe mal den ganzen Auszug aus dem Log gesucht...
2014.06.22 21:23:28 5: Cmd: >define WZ_AVR YAMAHA_AVR 192.168.11.41 mainzone 60 10<
2014.06.22 21:23:28 5: Loading C:/Apps/FHEM//FHEM/71_YAMAHA_AVR.pm
2014.06.22 21:23:28 5: Triggering WZ_AVR (1 changes)
2014.06.22 21:23:28 5: Notify loop for WZ_AVR presence: present
2014.06.22 21:23:28 4: eventTypes: YAMAHA_AVR WZ_AVR presence: present -> presence: present
2014.06.22 21:23:28 5: Triggering global (1 changes)
2014.06.22 21:23:28 5: Notify loop for global DEFINED WZ_AVR
2014.06.22 21:23:30 5: YAMAHA_AVR (WZ_AVR) - execute nonblocking "statusRequest unitDescription" on WZ_AVR: <YAMAHA_AV cmd="GET"><System><Unit_Desc>GetParam</Unit_Desc></System></YAMAHA_AV>
2014.06.22 21:23:30 4: HttpUtils url=http://192.168.11.41/YamahaRemoteControl/ctrl
2014.06.22 21:23:30 5: YAMAHA_AVR (WZ_AVR) - could not execute command "statusRequest unitDescription": connect: A non-blocking socket operation could not be completed immediately.
2014.06.22 21:23:30 3: YAMAHA_AVR (WZ_AVR) - could not execute command on device WZ_AVR. Please turn on your device in case of deactivated network standby or check for correct hostaddress.
2014.06.22 21:23:30 5: Triggering WZ_AVR (1 changes)
2014.06.22 21:23:30 5: Notify loop for WZ_AVR presence: absent
Das ist direkt nach der Einrichtung zu sehen. Danach wiederholen sich im Log nur noch die folgenden Zeilen:
2014.06.22 21:26:30 5: YAMAHA_AVR (WZ_AVR) - execute nonblocking "statusRequest unitDescription" on WZ_AVR: <YAMAHA_AV cmd="GET"><System><Unit_Desc>GetParam</Unit_Desc></System></YAMAHA_AV>
2014.06.22 21:26:30 5: HttpUtils url=http://192.168.11.41/YamahaRemoteControl/ctrl
2014.06.22 21:26:30 5: YAMAHA_AVR (WZ_AVR) - could not execute command "statusRequest unitDescription": connect: A non-blocking socket operation could not be completed immediately.
2014.06.22 21:26:30 5: YAMAHA_AVR (WZ_AVR) - execute nonblocking "statusRequest systemConfig" on WZ_AVR: <YAMAHA_AV cmd="GET"><System><Config>GetParam</Config></System></YAMAHA_AV>
2014.06.22 21:26:30 5: HttpUtils url=http://192.168.11.41/YamahaRemoteControl/ctrl
2014.06.22 21:26:30 5: YAMAHA_AVR (WZ_AVR) - could not execute command "statusRequest systemConfig": connect: A non-blocking socket operation could not be completed immediately.
2014.06.22 21:27:00 5: SW: 7b226964223a3933393330332c226a736f6e727063223a22322e30222c226d6574686f64223a224a534f4e5250432e50696e67227d
Bei der Zeile mit SW bin ich mir nicht sicher ob sie zum Yamaha Modul gehört.
Manchmal sagt ein Bild mehr als tausend Worte:
(http://i.imgur.com/TQb3veu.png)
Wobei ich sagen muss das sobald das FHEM Modul läuft das Webinterface echt arsch lahm wird.
Gruß,
Sascha
Kannst du bitte mal mit wireshark einen TCP-Dump anfertigen?
edit: direkt auf deinem FHEM System und dann mal ein statusRequest ausführen.
Danke Gruß
Markus
So, im Anhang ist das Capture. :)
Mal so am Rande... gibt es konkrete Erfahrungen mit nonblocking in einer windowsumgebung?!
Nicht, dass da ggf. der Hund begraben liegt.
Gute Nacht, Tobias
ändere bitte mal Zeile 788 in 71_YAMAHA_AVR.pm folgendermaßen um:
if($data eq "" and $err ne "")
Dann starte FHEM nocheinmal neu.
Nach meinen Recherchen scheint dies ein Window-spezifischer "Hinweis" und kein Fehler zu sein.
Gruß
Markus
@Markus:
Das hat leider nichts gebracht.
Das einzige was sich verändert hat ist
set WZ_AVR statusRequest
Unable to execute "WZ_AVR statusRequest" - please perform a statusRequest first
Die Antwort in der Console kommt wirklich SOFORT, vorher hat das einige Sekunden gedauert.
*** Edit ***
Ich habe gerade mal getestet ob es sich mit Blocking anders verhält.
In Zeile 728 habe ich $blocking auf 1 festgelegt und dann FHEM neugestartet. Gleiches Ergebnis. :(
Gruß,
Sascha
Dein FHEM läuft unter Windows?
Falls ja, kann ich dir da nicht wirklich helfen, da Windows generell nicht wirklich supported ist aufgrund vieler Schweinereien die Windows so mit sich bringt.
Unter Linux gibt es da keinerlei Probleme.
Gruß
Markus
Ja mein FHEM läuft unter Windows.
Die Information das es unter Linux läuft bringt mir leider gerade nicht viel. Ich bin jetzt nicht so tief in PERL drin, aber es schon doof das es unter Windows nicht "supported" wird.
Ich bin jetzt auch recht neu was das Thema FHEM angeht, aber in allen Guides die ich gelesen habe ist mir nicht aufgefallen das es Einschränkungen unter Windows gibt.
Mich wundert es halt das Module wie XBMC oder das EGPM2LAN halt ohne Probleme funktionieren. Es kann doch dann eigentlich nicht am PERL selbst liegen.
Im Klartext heisst das jetzt das Du mir nicht helfen kannst? :(
Gruß,
Sascha
Ich weiss, es hilft dir nix, aber ich kann sagen, dass ich mehrere Wochen mit FHEM unter Windows rumgespielt haben. Da es jedoch immer mal wieder Probleme an diversen Stellen gab, hab ich mir letztendlich eine virtuelle Maschine mit Tiny Core Linux aufgesetzt (unter Windows), um FHEM laufen zu lassen. Bin jetzt sehr zufrieden. Das Tiny Core ist echt super schlank und bootet in wenigen Sekunden. Das Ganze FHEM ist damit obendrein auch sehr schön gekapselt.
Hallo Sascha,
ja leider. Perl kommt ja ursprünglich aus der Unix-Welt und diese Herkunft spürt man ganz deutlich bei sämtlichen Perl-Portierungen für Windows.
Dazu kommt, dass jede Perl-Portierungen wieder so ihre Eigenheiten hat, so dass es sehr schwierig ist, all diese Spezialitäten irgendwie zu umschiffen. Generell wird Windows nur nach Best-Effort unterstützt. Am saubersten arbeitet nach meinen Informationen die Perl-Portierung von Cygwin. Aber auch hier ist nicht alles fehlerfrei.
Ich kann dir nur raten, einen anderen Perl-Interpreter zu testen, oder eben auf irgend ein linux-basiertes System umzusteigen.
Warum dieses Problem nicht bei den genannten Modulen XBMC und EGMP nicht auftritt, liegt daran, dass dort eine eigene Implementation und Steuerung des Sockets durchgeführt wird. Ich nutze das FHEM-weite Modul HttpUtils.pm, welches innerhalb FHEM Funktionen zur Abfrage von HTTP URL's zur Verfügung stellt.
Die genannte Fehlermeldung, die bei dir im Log erscheint, ist auch Gegenstand von vielen Diskussionen in anderen Programmiersprachen im Internet. Wenn man bei Tante Google nach der Meldung "A non-blocking socket operation could not be completed immediately" sucht, findet man sehr viele Hilfeschreie zu diesem Thema unter anderem in Python, C# und auch Perl.
Tut mir leid.
Gruß
Markus
Hallo Markus,
ja Perl ist sicherlich so eine Sache. Da kann man sicherlich viel und lange drüber streiten. Das bringt mich aber dann auch nicht weiter.
Schade das es nicht klappt. Da ich nicht auf ein Linux System wechseln kann, muss ich mal schauen wie ich das ganze Thema dann abhandeln kann.
Vielen Dank für Deine Hilfe.
Gruß,
Sascha
Hallo Markus,
vielen Dank, da hast Du mir ja was angetan!!! ;)
Ich habe jetzt so ziemlich alles was irgendwie möglich ist getestet.
- Ich habe FHEM unter Linux laufen lassen mit USB-over-Ethernet. Das war ein ganzes Stück Arbeit! - funktioniert aber nur eingeschränkt weil USB-over-Ethernet keine Events vom CUL ans FHEM weiterleitet. Das hat mich den grössten Teil des gestrigen Abends gekostet ;)
- Ich habe cygwin ausprobiert - Fehlanzeige!
- Ich habe ActiveState Perl probiert: Es geht! :O
Jetzt werde ich das nochmal weiter debuggen, das muss doch auch mit Strawberry Perl gehen. Mal sehen woran es liegt.
Der Tip mit dem Perl interpreter war gut! :)
Gruß,
Sascha