Sonos steuern

JoeALLb · 14 Januar 2014, 15:12:08

Nachtrag:
ohne sleep bekomme ich es nicht zum laufen!

Das funktioniert nicht!

define wz.Bedienung.NotifyT6 notify wz.Bedienung.virt_Btn6.virtActTrigger.* {\
set Sonos_Wohnzimmer StartFavourite BAYERN%%203;
}

Das funktioniert bisher immer.

Code Auswählen

define wz.Bedienung.NotifyT6 notify wz.Bedienung.virt_Btn6.virtActTrigger.* {\
sleep 1;
set Sonos_Wohnzimmer StartFavourite BAYERN%%203;
}

JoeALLb · 15 Januar 2014, 22:34:39

Statusbericht: Seit dem Update auf die aktuelle dev-version konnte ich den routing-fehler nicht mehr provozieren. Kann sein, dass er damit schon behoben ist?

Gesendet von meinem Xperia Pro mit Tapatalk

Reinerlein · 15 Januar 2014, 23:26:23

Hi JoeALLb,

zumindest nicht direkt. Die Dev-Version verbindet über Telnet zurück an Fhem (um die Attribute u.ä. abzufragen). Vielleicht sorgt das für ein verändertes Verhalten bei dem Routing-Problem...

Ich lasse gerade ein Konstrukt in meinem Kopf reifen, womit ich diese Dead-Lock Situation allgemein umgehen kann. Das muss aber noch etwas abhängen, bevor ich es umsetzen kann...

Grüße
Reiner

gki · 16 Januar 2014, 22:41:16

Hallo Reiner,

nur zur Info, da du ja ein neues Konstrukt in deinem Kopf reifen lässt

Ich habe heute mal die dev-Version Version geladen.

restart fhem als user fhem

Current: "/usr/share/fhem/fhem.pl", gPath: "/usr/share/fhem/FHEM"
Current: "/usr/share/fhem/FHEM/00_SONOS.pm", gPath: ""
Bind failed: Address already in use at /usr/share/fhem/FHEM/00_SONOS.pm line 4655.

Habe jetzt wieder die standard-Version geladen.

Gruß,
Ines

Reinerlein · 16 Januar 2014, 23:09:07

Hi Ines,

diese Fehlermeldung bedeutet, dass der Port, den du in der Fhem-Konfiguration für den Subprozess vorgesehen hast (in meinen Beispielen immer das 4711), bereits belegt ist.

Da müsstest du mal schauen, wer den belegt, und den Prozess entsprechend schliessen, oder in der Fhem-Konfiguration einen anderen Port einstellen.
Lief dort Fhem veilleicht schon einmal? Sonst versuch mal einen Neustart deiner Kiste, und lass Fhem nochmal versuchen...

Grüße
Reiner

gki · 16 Januar 2014, 23:44:02

Hallo Reiner,

ich hatte mir die Ports (netstat -letu | grep fhem) und Prozesse (ps -Af | grep fhem) angesehen.
Versuche es mit der dev-Version später nochmal wenn ich mehr Zeit habe.

Danke

Gruß,
Ines

ArminK · 19 Januar 2014, 15:11:26

Hallo zusammen, vor Allen Dingen Reinerlein,

hoffe ich liege hier nicht falsch...folgendes Problem:
Habe mir letzte Woche eine Sonos Play:1 nebst einer Bridge zugelegt. Beim Versuch das Sonos-Modul einzubinden bin ich kläglich gescheitert. Vermutlich weil meine Fhem-Installation auf dem Raspberry aus ziemlich alten tagen stammte, obwohl immer wieder upgedated wurde.
Habe dann einen zweite Pi samt neuer SD-Karte genommen und fhem von Grund auf neu installiert und um meine Konfiguration erweitert.
Alle nötigen Sachen laut Sonos-Wiki (im Übrigen: Super Beitrag!) installiert, den Eintrag define Sonos SONOS localhost:4711 30 in die fhem.cfg getippt, beim Start finde ich folgendes im Log:
2014.01.19 15:01:42 3: Opening Sonos device localhost:4711
2014.01.19 15:01:42 3: Sonos device opened

Allerdings werden keine Player (bzw. kein Player, habe ja aktuell nur einen) angelegt wie im Wiki beschrieben... Hat jemand eine Idee woran das liegen könnte?

Grüße aus Heidelberg,
ArminK

JoeALLb · 19 Januar 2014, 15:45:52

Und du hast sicher nur ein Netzwerk? Funktioniert dein Sonos mit anderen controller-apps, zB einer Handyapp oder auf dem PC? Dann kannst du von dieser Apple mal die IP ausfindig machen, die das Play 1 erhalten hat. Kannst du diese von deinem Rpi aus pingen?

Gesendet von meinem Xperia Pro mit Tapatalk

Reinerlein · 19 Januar 2014, 17:38:49

Hallo ArminK,

im Prinzip sieht das schon gar nicht soo schlecht aus. Wenn im Fhem-Log steht, dass das Device geöffnet werden konnte, dann ist der SubProzess zumindest schon mal angestartet.
Um jetzt sehen zu können, was wirklich auf Seiten des SubProzesses schief läuft, musst du dir die Konsolenausgabe des Prozesses anschauen.

Da der SubProzess ein eigenständiger Prozess ist, kann er nicht mit in das "normale" Fhem-Log schreiben, sondern gibt alles direkt auf STDOUT (bzw. manchmal auch STDERR) aus. Dort steht je nach Verbose-Level sehr detailliert, was gerade gemacht wird, und was einen Fehler verursacht haben könnte...

Wenn du das aus deinem Startskript heraus nicht in den Griff bekommst, kannst du für diese Untersuchung Fhem auch manuell starten (dazu aber erst eine etwaig laufende Instanz von Fhem beenden, und in das korrekte Verzeichnis wechseln):

Code Auswählen

sudo perl fhem.pl fhem.cfgDann siehst du direkt auf der Konsole die Ausgaben des SubProzesses..

Grüße
Reiner

ArminK · 20 Januar 2014, 16:21:50

Hallo Reinerlein,

also habe das jetzt mal (vom Büro aus via SSH) probiert. Mir fiel noch auf, das die Rechte von 00_sonos.pm anders waren als bei den restlichen files...das habe ich vorher mal noch angepasst auf von 644 auf 666

dann gestartet und als Ausgabe bekomme ich:

Prototype mismatch: sub main::head: none vs ($) at ./FHEM/00_SONOS.pm line 163
Current: "fhem.pl", gPath: "./FHEM"

und Fhem startet offensichtlich nicht mehr, zumindest komme ich von extern nicht mehr dran...

setzte jetzt auch noch die Rechte von 21_SONOSPLAYER.pm auf 666 und versuche nochmal

ArminK · 20 Januar 2014, 16:41:34

Zweiter Versuch wie oben vorgewarnt: Keine Fehlermeldung mehr aber es sieht so aus wie wenn fhem hängt, kann ich aber erst heute Abend checken wenn ich Zuhause bin...kann ich denn auf der Kommandozeile feststelen ob fhem läuft?

Reinerlein · 20 Januar 2014, 16:54:51

Hallo ArminK,

diese Fehlermeldung sieht komisch aus, und kann ich persönlich auch nicht nachvollziehen. An der Stelle steht im Code die "Package"-Anweisung. Ich wusste gar nicht, dass es dort auch was mit Prototypen geben kann...

zu deiner zweiten Frage:
Mittels

Code Auswählen


ps aux | grep perl

kannst du dir alle laufenden Perl-Prozesse auflisten lassen. Da sollte dann mindestens einer mit dem Skriptnamen fhem.pl auftauchen, dann läuft Fhem prinzipiell...

Du kannst auch von der Konsole aus in die Log-Datei von Fhem reinschauen:

Code Auswählen


tail -f /path/to/logfile.log

Damit kannst du "Live" mitlesen, was Fhem da so reinschreibt...

Grüße
Reiner

ArminK · 20 Januar 2014, 17:02:44

Hallo Reiner,

vielen Dank für die Hilfe. Kurzes Update: Habe die Rechte via FTP wieder auf 644 gesetzt und nochmal einen Reboot gemacht. Es kam mir so vor als ob fhem nicht von alleine starten wollte (war sehr lange nicht erreichbar) also nochmal via ssh fhem händisch gestartet, ein paar Minuten später noch einmal nachgeschaut und siehe da: fhem ist wieder via dyndns zu erreichen! Und was noch besser ist: Ich hab jetzt bei meinen Devices die Sonos bridge und den Sonos Player gelistet....erklären kann ich mir das nicht...ich werde jetzt mal versuchen damit zu spielen und gebe Dir ein Feedback wie es aussieht!

Grüße
Armin

herman · 22 Januar 2014, 13:00:05

Hallo Reiner,

kann man Dich bzgl. dem Deadlock Thema unterstützen? Die Logs sind bei mir gerade nicht sonderlich aussagekräftig. Grundsätzlich habe ich zwei Situationen:

a) Subprozess hängt, FHEM läuft. Befehle werden von FHEM abgesetzt, in der Konsole erscheint ein DoWork aber keine Reaktion. Wenn ich ein delete Sonos in FHEM ausführe werden die ganzen Befehle abgearbeitet

b) FHEM hängt, Subprozess ?: Wenn ich FHEM abschieße werden wieder alle Befehle abgearbeitet

Wenn ich irgendetwas testen soll, lass es mich wissen

Viele Grüße,
Merhan

Reinerlein · 22 Januar 2014, 13:13:07

Hallo Merhan,

danke für das Angebot, aber ich bin noch mitten in der Umsetzung meiner Idee. Und dann muss das ja am Ende auch noch funktionieren

Ich bin momentan nicht zuhause, sodass die Entwicklung bis Ende der Woche ruht. Aber dann sollte es eigentlich weitergehen, sodass ich da hoffentlich bald was neues zu sagen/schreiben kann.

Grüße
Reiner