Sonos steuern

Begonnen von Will, 05 Januar 2013, 15:51:12

Vorheriges Thema - Nächstes Thema

JoeALLb

Zwischeninfo:
Heute hat es wieder funktioniert, jedoch hat sich mein rpi heute nacht auch ohne ersichtlichen Grund rebootet.
Ich werds weiter beobachten!
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

m.zielinski

Mein Raspberry stand heute morgen auch still bzw fhem war komplett beendet. Leider zeigte weder fhem noch console logfile irgendwas an.

Bin dann wieder auf die vorversion gegangen statt der von gestern.

Der WAF sinkt zu sehr wenn Fhem ganz weg ist...

Reinerlein

Hallo zusammen,

mich würde es tatsächlich wundern, wenn wegen des Moduls Fhem hängenbleibt, oder gar der RPi einen Neustart durchführen muss.
Aber natürlich kann man nichts ausschließen und ich wurde schon oft genug zum wundern gebracht :-) Nur brauchts dafür die Konsolenausgabe, da dort die Ausgaben des abgetrennten Prozesses auflaufen.

Ich habe das bei mir so gelöst, dass die Konsole in eine Datei umgelenkt wird, sodass ich das auch noch nachträglich durchsehen kanm. Notfalls muss man sowas einrichten, um dem ganzen auf die Spur zu kommen...

Grüße Reiner

JoeALLb

Hast du dafür eine Anleitung??

Vielleicht hilft das schon:
Ich konnte soeben beobachten, dass manchmal die CPU-Auslastung länger als 5 Minuten auf 100% ging. Daraufhin hat der Watchdog den rpi neu gestartet.
In der Log stand ein Hinweis (aus dem Kopf) "kill XXY konnte nicht beendet werden".... naja o ähnlich zumindest. Es war jedoch das SONOS-Modul...
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Reinerlein

Hi,

man könnte einfach das Modul "von Hand" starten:perl fhem.pl fhem.cfg > fhem.log &Damit wird im aktuellen Verzeichnis die Konsolenausgabe in die Datei fhem.log geschrieben.
Das & sorgt dafür, dass der Prozess direkt im Hintergrund gestartet wird, und du die Datei mittail -f fhem.loglaufend mitlesen kannst...

Das mit der CPU Auslastung ist natürlich möglich, wobei ich das bei mir noch nicht hatte... Vielleicht liegt es daran, dass mein fhem unter dem Benutzer root läuft. Das ist aber momentan reine Mutmaßung...
Ich erhoffe mir durch die Log-Analyse einen Einblick, was da die CPU Last erzeugen könnte. Dann können wir das auch in den Griff bekommen...

Grüße Reiner

JoeALLb

Jetzt gerade habe ich eine andere Fehlermeldung bekommen..... aer die CPU war auch bei 100% last.
Ich versuch mal so ein Logging mitlaufen zu lassen!

2013.10.11 23:02:48 3: SONOS1: Event: End of Transport-Event for Zone "Sonos_Bad".
2013.10.11 23:02:49 3: SONOS1: Event: Received ZoneGroupTopology-Event for Zone "Sonos_Kueche".
2013.10.11 23:02:49 3: SONOS1: Event: End of ZoneGroupTopology-Event for Zone "Sonos_Kueche".
2013.10.11 23:02:52 3: SONOS1: Event: Received Transport-Event for Zone "Sonos_Wohnzimmer".
2013.10.11 23:02:52 3: SONOS1: Event: End of Transport-Event for Zone "Sonos_Wohnzimmer".
2013.10.11 23:02:57 3: SONOS1: Event: Received Alarm-Event for Zone "Sonos_Wohnzimmer".
2013.10.11 23:02:57 3: SONOS1: Event: End of Alarm-Event for Zone "Sonos_Wohnzimmer".
2013.10.11 23:03:00 3: SONOS1: Event: Received Transport-Event for Zone "Sonos_Schlafzimmer".
2013.10.11 23:03:01 3: SONOS0: Received: 'DoWork:RINCON_000E58532C2E01400_MR:play:'
Out of memory!
Perl exited with active threads:
        1 running and unjoined
        1 finished and unjoined
        0 running and detached
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Reinerlein

Hi JoeALLb,

das mit dem Memory-Error hatten wir hier schon mal. Ich weiss jetzt nicht mehr genau, ob sich das erledigt hatte, oder irgendwie in den Griff bekommen wurde. Das Modul selbst macht an dieser Stelle keine großen Aktionen. Es wird ein SOAP-Paket an den Player zusammengeschnürt, und ein bißchen hin- und herkommuniziert. Alles nix großartiges, da muss der Speicher echt knapp bemessen sein.

Kannst du mal prüfen, wieviel der Perl-Prozess so benötigt, und wieviel dein Pi da noch so frei hat?
Vielleicht könnte auch eine Swap-Datei auf einem anderen Speichermedium helfen (auf der SD Card ist das wohl eher nicht so gut).

Bei mir sieht die Aufteilung auf die beiden Prozesse so aus, dass Fhem ca. 40MB und mein extra Prozess ca. 70MB belegt.
Hier mal die Ausgabe des belegten Speichers aus dem Befehl "top":KiB Mem: 188880 total, 139588 used, 49292 free, 8012 buffers
KiB Swap: 102396 total, 4592 used, 97804 free, 39712 cached
Da wird also Swap verwendet, obwohl noch Arbeitsspeicher frei ist, was unter Linux auch normal ist. Ich habe da aber auch nix angepasst, das ist wohl das Standardverhalten / die Standardeinrichtung von Raspbian...

Grüße Reiner

snoop

Hallo Reiner,
der erste Test zum Thema:
ZitatBei der temporären Wiedergabe (TempPlaying, Speak) wird nun auch ein Line-Eingang korrekt wiederhergestellt.
war erfolgreich - Vielen Dank dafür.
Viele Grüße
Arthur

JoeALLb

Hallo Reiner,

heute morgen lief FHEM noch, also konnte ich das Problem nicht nachstellen.
Es laufen jedoch häufig mehrere upnp-Perl-Prozesse aus dem Sonos-Bereich.... ich habe derzeit tatsächlich den Verdacht, dass FHEM, welches nicht mit Root-Rechten läuft,
probleme beim Abbau vorhandener und nicht mehr benötigter Connections hat.... daher hab ich vermutlich vor 2 Tagen auch mal den Fehler "Trying to kill Sonos_Thread..." mit dem nicht erfolgreichen Kill-Befehl gesehen. Kann das sein? Wann genau wird denn hier etwas gekillt?

Ich war heute zuwenig zuhause und konnte es dahe rnicht weiter testen...
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Reinerlein

Hi JoeALLb,

dieser Versuch den Sonos_Thread zu killen wird immer dann unternommen, wenn du ein "rereadcfg" oder "shutdown" in Fhem durchführst. Nach der Ausgabe von "trying" sollte dann kurz danach die Ausgabe von "UPnP-Thread wurde beendet" kommen. Damit ist dann auch der UPnP-Listener beendet, und empfängt keine Nachrichten mehr von den Playern. Es werden aber auch noch andere Threads getötet, da sollten also auch noch entsprechende Ausgaben erfolgen (insgesamt bis zu 3). Wenn du ein "shutdown" in Fhem durchführst, wird sogar der ganze Prozess beendet (wenn du ihn nicht selber per Hand gestartet hattest).

Und mit "es laufen jedoch häufig mehrere upnp-Perl-Prozesse" meinst du echte Prozesse, die du z.B. per "top" oder "ps" auf der Konsole sehen kannst?
Das ist dann reichlich komisch, weil im Normalfall beim Start eines zweiten Sonos_Thread eine Fehlermeldung kommen müsste, dass der Port (den du übergeben/eingestellt hast) bereits belegt ist. Er startet ja immerhin einen Serverdienst auf dem angegebenen Port (bzw. versucht es).

Aber eigentlich sollte das alles von root unabhängig sein. Der Prozess wurde ja schließlich von dem Fhem-User gestartet, und darf dementsprechend auch von diesem Benuter wieder entfernt werden...
Komisch, komisch...

Grüße Reiner

JoeALLb

#415
Hallo Reiner

mit htop in der Baumansicht konnte ich diese sehen. Aktuell sind da "nur" 2.
Ich habe zwischenzeitlich auch fhem nochmals aktualisiert und einige perl-module aktualisiert... vielleicht funktioniert es ja deshalb derzeit! Ich beobachte es noch weiter
und schreibe alles in Logdateien mit! Danke erstmal dafür.


`- perl fhem.pl fhem.cfg
|  `- perl FHEM/00_SONOS.pm 4711 3
|     `- perl FHEM/00_SONOS.pm 4711 3
|     `- perl FHEM/00_SONOS.pm 4711 3



Edit: Fixed!!! Der Speak-Fehler(unten) wurde durch die Schreibrechte im SonosSpeak-Verzeichnis ausgelöst. Darauf hat mich die Logdatei leider nicht sofort gebracht-.....
Jetzt funktioniert es!!!

Nun wollte ich die Funktion Speak testen, dabei erhalte ich jedoch fiolgende Meldung.
Mache ich da was falsch?
set Sonos_Wohnzimmer Speak 30 de Test


2013.10.13 00:18:47 3: SONOS0: Received: 'DoWork:RINCON_000E58532C2E01400_MR:speak:30,de, Test'
2013.10.13 00:18:47 3: SONOS1: Load MP3 from "http://translate.google.com/translate_tts?tl=de&q=Test" to "/mnt/SonosSpeak//RINCON_000E58532C2E01400_MR_Speak.mp3"
2013.10.13 00:18:47 2: SONOS1: Beim Setzen der MP3-Informationen (ID3TagV2) ist ein Fehler aufgetreten: Can't call method "title_set" on an undefined value at FHEM/00_SONOS.pm line 1659, <$client> line 2.

2013.10.13 00:18:47 3: SONOS1: Start temporary playing of "\192.168.178.69\SonosSpeak/RINCON_000E58532C2E01400_MR_Speak.mp3"
2013.10.13 00:18:49 3: SONOS1: SleepTimer berechnet die Laufzeit des Titels selber, da keine Wartezeit uebermittelt wurde!
2013.10.13 00:18:49 1: SONOS1: Da keine Endzeit ermittelt werden konnte, wird kein Restoring durchgef?hrt werden!



edit: verwendeten code corrigiert
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

JoeALLb

Hi,
soeben hatte ich folgende Fehlermeldung... vielleicht hilft das weiter? Danach war wieder mein Arbeitsspeicher voll und ich hatt
9 UpnP-Prozesse in htop gesehen. Sorry für die vielen Nachrichten, aber ich hoffe, es hilft weiter ;-)


2013.10.13 00:26:54 3: SONOS0: Trying to kill Sonos_Thread...
2013.10.13 00:26:54 3: SONOS0: Trying to kill PlayerRestore_Thread...
2013.10.13 00:26:54 1: SONOS2: Restore-Thread wurde beendet.
2013.10.13 00:26:55 3: SONOS1: Controlpoint-Listener wurde beendet.
Unsubscription request failed with error: 412 Precondition Failed at FHEM/lib/UPnP/ControlPoint.pm line 1001 thread 1.
Can't call method "kill" on an undefined value at FHEM/00_SONOS.pm line 4038, <$client> line 17.
Current: "fhem.pl", gPath: "./FHEM"
Current: "FHEM/00_SONOS.pm", gPath: ""
2013.10.13 00:27:14 1: SONOS0: FHEM/00_SONOS.pm is listening to Port 4711
2013.10.13 00:27:16 1: SONOS0: Connection accepted from localhost:47862
2013.10.13 00:27:17 3: SONOS0: Received: 'SetData:Sonos:none:RINCON_000E58532C9001400_MR,RINCON_000E58532C2E01400_MR,RINCON_000E5871016E01400_MR,RINCON_000E5836AAAC01400_MR'
2013.10.13 00:27:17 3: SONOS0: Received: 'StartThread'
2013.10.13 00:27:18 3: SONOS1: UPnP-Thread gestartet.
2013.10.13 00:27:19 1: SONOS2: Restore-Thread gestartet. Warte auf Arbeit...
2013.10.13 00:27:20 2: SONOS1: Discover Sonosplayer 'Wohnzimmer' (ZP120) Software Revision 4.1 with ID 'RINCON_000E5836AAAC01400_MR'
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Reinerlein

Hi,

kein Problem, wir versuchen das Problem ja zu lösen :-)

Eigentlich dachte ich, dass ich das Poblem mit den nicht mehr vorhandenen Threads, die ich töten möchte, im Griff habe... Dem scheint nicht so zu sein. Da schärfe ich noch etwas nach.
Aber das wird eine reine Symptombehandlung und wir wollen ja eigentlich das Problem in den Griff bekommen...

Ich habe mir das bei mir auch mal mit htop angeschaut, und ich habe natürlich auch die Threads, nur dass es bei mir einer mehr ist. Ich habe im Baum oben den Fhem-Prozess, und darunter meinen selbstgestarteten zweiten Prozess. Dann folgen darunter drei Threads, die ich in Perl ja auch starte. Bei dir waren das nur zwei. Da fehlt wohl der IsAlive-Thread (zumindest laut deines Log-Auszugs). Da müsste dazu passend eigentlich eine Ausgabe kommen. Vielleicht kannst du den Loglevel mal hochdrehen, und die ersten Zeilen der Konsolenausgabe mal hier angeben. Vielleicht stirbt der wegen fehlender Rechte.
Steht dein PingType vielleicht auf "icmp"? Das geht nur als root. Aber wie gesagt, da müsste eine Ausgabe zu erfolgen...

Grüße
Reiner

Reinerlein

Hi JoeALLb,

eine Frage kann ich mir mittlerweile selber beantworten. Das passiert, wenn man seinen eigenen Code nicht mehr vollständig im Kopf hat :-)
Sorry dafür...

Du hast wahrscheinlich keinen pingType definiert. Ab Version 2.0 wird dann standardmäßig keine zyklische Prüfung mehr durchgeführt. Das Verhalten ist dann so wie beim Original-Controller (Ein Player bleibt für immer in der Liste der verfügbaren Player, erst wenn man ihn wieder anschaltet, verschwindet er kurz, und taucht danach wieder auf). Das bedeutet auch, dass dieser Thread natürlich gar nicht erst gestartet wird.
Damit ist die Anzahl der Threads geklärt. Ich habe pingType definiert, und somit einen Thread mehr als du...

Aber dein Speicherproblem ist damit natürlich noch nicht geklärt... Da müssen wir noch irgendwas herausfinden...

Grüße Reiner

JoeALLb

Hallo Reiner,

genau ;-)
Ich lasse im Moment noch alle meine Sonos-Boxen permanent an und prüfe sie deshlb noch nicht. Jedoch ist meine Konfiguration durchaus noch im Entstehen....
Schaltest Du deine per Funksteckdose aus?

Wenn ich Dir irgend etwas helfen kann, gib mir einfach bescheid. Ich lese mich erstmal in Deinen Code ein, und würde ihn gerne um eine Offline-Voice.Methode ergänzen, obwohl mir durchaus bewußt ist, dass eine Stimme aus espeak undeutlicher klingt als die von Google. Wäre das in deinem Sinne, oder soll ich das lieber eigens auslagern?

Lässt Du dich schon von diesem Modul wecken, oder nimmst Du noch die Sonos-interne Weckfunktion? Ich spiele derzeit mit den diversen Möglichkeiten herum, hab aber noch keine für mich zufriedenstellende Lösung gefunden..
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270