Sonos steuern

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

Vorheriges Thema - Nächstes Thema

det.

Zitat von: Elektrolurch am 02 Mai 2015, 18:46:24
Ein schneller Tipp?
Cubie bei eingeschalteten SONOS mal komplett neu starten, nicht nur fhem?
LG
det.

Reinerlein

Hallo Elektrolurch,

wenn der Neustart nichts gebracht hat, dann wäre eine Ausgabe auf der Konsole hilfreich.
Das Modul ist in verschiedenen Verbose-Leveln sehr redselig, und gibt ziemlich genau aus, was für Probleme auftreten.

Unter http://www.fhemwiki.de/wiki/SONOS#Fehlersuche sind dazu ein paar Hinweise...

Die Ausgabe dann an mich übermitteln oder hier posten...

Grüße
Reinerlein

Elektrolurch

Hallo Reinerlein,

erst Mal vorab schon sehr herzlichen Dank für Deine unendliche Geduld hier im Forum.
Bei mir erkennt er noch die SonosBridge, meldet aber einen UPnP - Fehler....

Hier der log-Auszug:

Current: "fhem.pl", gPath: "./FHEM"
Current: "./FHEM/00_SONOS.pm", gPath: ""
2015.05.02 20:00:22 1: SONOS0: ./FHEM/00_SONOS.pm is listening to Port 4711
2015.05.02 20:00:29 3: SONOS1: UPnP-Thread gestartet.
2015.05.02 20:00:30 1: SONOS2: IsAlive-Thread gestartet. Warte 120 Sekunden und pruefe dann alle 30 Sekunden...
2015.05.02 20:00:30 1: SONOS3: Restore-Thread gestartet. Warte auf Arbeit...
2015.05.02 20:00:34 2: SONOS1: Discover Sonosplayer 'ZoneBridge' (ZB100) Software Revision 5.2 with ID 'RINCON_000E5846A6F801400_MR'
2015.05.02 20:01:12 2: SONOS1: Error during UPnP-Handling: not properly closed tag 'stateVariable'

2015.05.02 20:01:12 3: SONOS1: UPnP-Thread wurde beendet.
2015.05.02 20:01:29 3: SONOS0: Connection accepted from localhost:56822
2015.05.02 20:01:59 3: SONOS0: Connection accepted from localhost:56823
2015.05.02 20:02:29 3: SONOS0: Connection accepted from localhost:56824
2015.05.02 20:02:59 3: SONOS0: Connection accepted from localhost:56825
2015.05.02 20:03:29 3: SONOS0: Connection accepted from localhost:56826
2015.05.02 20:03:59 3: SONOS0: Connection accepted from localhost:56827
2015.05.02 20:04:29 3: SONOS0: Connection accepted from localhost:56828


Ich hatte das System rebootet und mit
/etc/init.d/fhem stop
das automatisch gestartete fhem beendet.

dann:

perl fhem.pl fhem.cfg >/media/public/startsonos.log

mit aufgezeichnet.

Noch eine Anmerkung: Habe auf dem Cubie derzeit zwei Interfaces laufen (eth0 und wlan0). Über beide ist der Cubie erreichbar. Wie bindet UPnP?
Könnte das ev. noch ein Problem sein?
(sowas gibt es ja schon mal bei VPN-Services)

Elektrolurch


configDB und Windows befreite Zone!

Reinerlein

Hallo Elektrolurch,

kein Problem, ich helfe gerne. Außerdem hilft jeder Fehler (bzw. dessen Behebung) das Modul robuster zu machen :)

Kannst du dieses Logging mal mit Verbose 5 am Sonos Device machen?
Irgendwie scheint das Beschreibungsdokument nicht sauber geladen zu werden...

Der UPnP-Prozess lauscht auf einem Multicast Port, der an alle Adressen gebunden ist (zumindest wenn ich den Parameter "INADDR_ANY" korrekt interpretiere :) ).

Ich kann auf jeden Fall ein Beenden des Prozesses bei einem solchen Fehler unterbinden. Allerdings muss dann eine faire Chance darauf bestehen, dass ein Neustart des UPnP-Handlings etwas hilft...

Grüße
Reinerlein

ujaudio

Nur zur Info: es scheint zu funktionieren, am Anfang gbit es im Log aber ein paar Fehlermeldungen:

2015.05.03 09:27:03 1: SONOS0: Kein UPnP-Server gefunden... Starte selber einen und warte 8 Sekunde(n) darauf...
Current: "fhem.pl", gPath: "./FHEM"
2015.05.03 09:27:11 3: Opening Sonos device localhost:4711
2015.05.03 09:27:11 3: Can't connect to localhost:4711: Verbindungsaufbau abgelehnt
Current: "./FHEM/00_SONOS.pm", gPath: ""
2015.05.03 09:27:12 1: SONOS0: ./FHEM/00_SONOS.pm is listening to Port 4711
2015.05.03 09:28:13 3: SONOS0: Connection accepted from localhost:46799
2015.05.03 09:28:13 1: localhost:4711 reappeared (Sonos)
2015.05.03 09:28:15 3: SONOS1: UPnP-Thread gestartet.
2015.05.03 09:28:16 1: SONOS2: IsAlive-Thread gestartet. Warte 120 Sekunden und pruefe dann alle 30 Sekunden...
2015.05.03 09:28:17 1: SONOS3: Restore-Thread gestartet. Warte auf Arbeit...


Danach kommen aber sinnvolle Meldungen und meine Geräte werden erkannt. Deshalb gehe ich davon uas, dass das soweit ok ist.

Mittlerweile habe ich mal das Wiki gelesen, diesen Thread werde ich auch noch durchackern, bevor ich richtig loslege. Auf alle Fälle werde ich wohl weit mehr machen, als ursprünglich vorgesehen war. Der Appetit kommt halt bem Essen... ;)

Einen lieben Gruß
Jürgen
Einen lieben Gruß
Jürgen

Reinerlein

Hi Jürgen,

diese Fehlermeldung kommt daher, weil der SubProzess nicht schnell genug Bereit ist und auf der Schnittstelle lauscht.
Es dauert je nach Hardware etwas, bis der Part von Perl kompiliert und ausgeführt wurde...

Diese lange Wartezeit in der Folge davon kannst du aber mit einem weiteren Parameter bei der Definition des Sonos-Moduls verhindern.
Wenn du dir die Logs anschaust, siehst du, dass da bloß eine Sekunde fehlt.

Wenn du also die Standard-8-Sekunden-Wartezeit auf 10 erhöhst, sollte das schneller durchlaufen (der Verbindungsaufbau wartet sonst eine Minute für einen weitren Versuch):

define Sonos SONOS localhost:4711 30 10


Bedenke bei diesem Thread hier, dass dieser über zwei Jahre Laufzeit hat. Ab einem gewissen Alter der Posts sind diese u.U. nicht mehr für die aktuelle Version gültig :)

Ich denke auch, dass es die beste Taktik ist, das Modul einfach mal in Betrieb zu bringen, wenn man schon Sonos-Player besitzt.
Ideen was man damit dann machen kann kommen von ganz alleine :)

Grüße
Reiner

ujaudio

#1791
Wie änder ich die Waittime ohne löschen und neu definieren? Sorry, eigentlich eine Anfängerfrage...
Ansonsten steckt da viel Arbeit dahinter - ein ganz dickes Lob und Danke!


Nachtrag: schon selbst gefunden, einfach im "DEF" von "Sonos" die Definition anpassen!
Einen lieben Gruß
Jürgen

Elektrolurch

Hallo Reinerlein,

jetzt bin ich einen Schritt weiter. Die Geräte werden jetzt erkannt, aber dann stürzt der fhem-Hauptprozess ab.
Wenn die Geräte ausgeschaltet sind, läuft fhem.
Wenn ich dann die SonosBridge einschalte, wird diese auch erkannt und fhem läuft weiter.
Wenn dann ein player eingeschaltet wird, wird dieser erkannt und angelegt. Anscheinend gibt es aber dann ein Problem beim Lesen der Musikbibliotheken....

Ich hänge mal die verschidenen logs mit verbose 5 an:

fhem-2015-05-03:
Das ist die letzte Zeile vor der Beendigung:
2015.05.03 08:52:31 4: SONOS0: Transport-Event: CoverArt konnte nicht gefunden werden. Verwende FHEM-Logo. Bilder-Download: SONOS_DownloadReplaceIfChanged('./FHEM/lib/UPnP/sonos_empty.jpg', './www/images/default/SONOSPLAYER/Sonos_Hobbyraum_AlbumArt.png');


Die Ausgaben von stdout sind in startsonos:

Das ist die letzte Zeile:
2015.05.03 08:56:51 4: SONOS2: 192.168.1.67 is alive


Der subprozess (perl 00_SONOS.pm) scheint auch nach dem Absturz fhem weiterzulaufen (siehe unten).

Dann habe ich noch stderr aufgezeichnet (konsole):
letzte Zeile:
Smartmatch is experimental at ./FHEM/00_SONOS.pm line 5521.

Es gibt da noch Ausgaben, die wohl vom Subprozess kommen:
Odd number of elements in hash assignment at /usr/share/perl/5.20/IO/Socket/IP.pm line 109, <$client> line 4.
Odd number of elements in hash assignment at /usr/share/perl/5.20/IO/Socket/IP.pm line 109, <$client> line 4.
Odd number of elements in hash assignment at /usr/share/perl/5.20/IO/Socket/IP.pm line 109, <$client> line 4.
Odd number of elements in hash assignment at /usr/share/perl/5.20/IO/Socket/IP.pm line 109, <$client> line 4.


Ich vermute, dass das was mit den Albuminformationen zu tun haben könnte, die der Subprozess sammelt, denn wenn fhem abstürzt und ich dann einen weiteren Player einschalte, kommen die Ausgaben auch wieder.

Die eingebundenen Musikbibliotheken sind zum Teil nicht verfügbar (ausgeschalteter Laptop der Tochter). Ich hoffe, dass das nichts macht.

Nicht über die unterschiedliche Zeiten in den Dateien wundern, habe das zweimal gemacht, da einmal mit > und dann mit 2>...

Gruß

Elektrolurch




configDB und Windows befreite Zone!

Reinerlein

Hi Elektrolurch,

in den ganzen Logs ist jetzt nix drin, was irgendwie einen Absturz rechtfertigen würde.
Das Modul sollte kein Problem mit Musikquellen haben, die nicht mehr da sind. Es wird ja nur das Verarbeitet, was von den Playern gesendet wird, und das darf natürlich auch leer sein :)

Die Meldungen mit den "Odd numbers of Arguments..." stammt von dem Perl IP-Modul, und hat nur am Rande mit dem Sonos-Modul zu tun (es verwendet halt den IP-Layer). Das kann man leider nicht ändern, sorgt aber auch für keine Einbußen beim Betrieb des Moduls.

Ist denn Fhem richtig weg, oder arbeitet Perl nur sehr stark (am Besten mal mit "top" auf der Konsole nachschauen)?
Ist das gepostete Fhem-Log wirklich bis zum Absturz geschrieben? Da steht ja keinerlei Fehlermeldung am Ende drin...

Die letzte Meldung im Log ist ja, dass er ein Standardcover verwenden wird. Das ist auch OK so.
Stimmen die Dateirechte alle? Nicht dass er gerade versucht, eine Datei zu lesen (in diesem Fall "./FHEM/lib/UPnP/sonos_empty.jpg") die er nicht lesen darf, oder zu schreiben, wo er nicht darf (in diesem Fall im Ordner/Datei "./www/images/default/SONOSPLAYER/Sonos_Hobbyraum_AlbumArt.png").

Grüße
Reinerlein

Elektrolurch

Hallo Reinerlein,

uppsss... Du bist einfach der Größte:

Zitat:
"./FHEM/lib/UPnP/sonos_empty.jpg") die er nicht lesen darf,
Die hatte ich schon gesehen, weil da war auch was im log und die Rechte habe ich gesetzt, aber das:

oder zu schreiben, wo er nicht darf (in diesem Fall im Ordner/Datei "./www/images/default/SONOSPLAYER/Sonos_Hobbyraum_AlbumArt.png").

Das war es dann auch. Jetzt sind alle Player da...!

Jetzt muss ich mir mal darüber Gedanken machen, wie ich durch die Musikbibliotheken oder Radiosender-Liste per fhem browsen kann. Leider ist nämlich die app von Sonos nicht (bzw. nur sehr eingeschränkt) tauglich für einen Screenreader.

Weißt Du, ob da schon jemand so einen "Musikbrowser" ev. gebaut hat?

Gruß

Elektrolurch

configDB und Windows befreite Zone!

Reinerlein

Hallo Elektrolurch,

schön, dass es jetzt geht :)

Es gibt diverse Möglichkeiten um out-of-the-box mit dem Modul eine Favoriten-, Radio- oder Playlistenanzeige zu bauen.
Da gibt es die Get-Anweisungen "FavouritesWithCovers", "RadiosWithCovers" oder "PlaylistsWithCovers" zu. Diese befüllen dann ein Reading mit den entsprechenden Namen "Favourites", "Radios" oder "Playlists" am entsprechenden Sonosplayer Device.
Das kannst du dir dann selber zerpflücken. Eine beispielhafter Code für eine ReadingsGroup ist auch schon mitgeliefert.
Zum Beispiel:

SONOS_getListRG("Sonos_Bad", "Favourites", 1)

Das liefert dir den HTML-Code für eine UnOrdered-List (durch den dritten Parameter, die Eins) für die Favoriten inkl. Cover (allerdings ohne Namensanzeige)

Die Variante

SONOS_getListRG("Sonos_Bad", "Favourites")
, also ohne dritten Parameter, liefert dir eine Tabelle der Liste, dafür aber mit Namen der Favoriten.

Das ganze ist eher als Vorlage für eigenen Code in der eigenen 99_myUtils.pm gedacht, damit man sieht, wie man das Reading durchgehen kann, um selber etwas für die Oberfläche zu bauen (aber nicht vergessen, den Namen der Prozedur anzupassen)...

Wenn es dir um eine grundsätzliche Browse-Funktionalität geht, dann ist Andre (justme1968) wohl gerade dabei etwas großes zu bauen, womit man die komplette Bibliothek der Player durchsuchen kann. Die Daten dafür kann das Modul bereits vom Player abfragen...
Das sind aber echt viele Daten, sodass eine Oberfläche dazu sehr geschickt aufgebaut sein muss, damit das noch handhabbar bleibt...

Grüße
Reinerlein

Elektrolurch

Danke Reinerlein. Das ist genau der Super-Kickoff, den ich brauchte....
configDB und Windows befreite Zone!

ujaudio

Da ich aus Energiespargründen meine Sonos-Geräte abschalte, bekomme ich jede Menge Einträge in das Logfile, ich habe den verbose schon auf 0 gesetzt, es kommen aber noch immer Meldungen:
Renewal of subscription failed with error: 500 Can't connect to 192.168.178.35:1400 (Keine Route zum Zielrechner) at ./FHEM/00_SONOS.pm line 3593 thread 4
Wie kann ich diese verhindern?
Einen lieben Gruß
Jürgen

Reinerlein

Hi Jürgen,

das kommt daher, weil das Modul immer noch der Meinung ist, dass der Player erreichbar sei, obwohl er das nicht ist. Deswegen versucht er die Anmeldungen an den Playern aufzufrischen.
Diese Meldungen werden auch nicht vom Modul selbst über das kontrollierte Logging geschrieben, sondern landen durch das verwendetete UPnP-Modul und dessen carp-Aufruf direkt auf STDERR.

Was sagt denn das Reading "presence" bei den Playern?
Wenn das noch auf "appeared" steht, dann mal die Konsolen-Logs durchsuchen (notfalls auf verbose 5), ob der IsAlive-Checker einen Fehler ausgibt...

Ich habe gerade mal eine Möglichkeit gesucht und vielleicht gefunden, diese Meldungen wirklich abzufangen (das eigentliche Problem ist, dass das UPnP-Modul dort ein "carp" aufruft, und das nicht mit einem "eval{}"-Block aufgefangen werden kann)...
Leider kann ich das gerade nicht zwischendurch probieren/veröffentlichen, da ich gerade mitten in der Entwicklung der Bookmarks bin :(
Vielleicht kannst du temporär was mit einer Umleitung von STDERR erreichen, damit diese nicht im Fhem-Log landen...

Grüße
Reiner

Reinerlein

Hi Jürgen

kannst du mal eine kleine Code-Änderung für mich versuchen?

In der Datei "ControlPoint.pm" im Ordner "FHEM/lib/UPnP/" in der Zeile 1008 aus dem "carp" bitte ein "croak" machen.
Wenn es bei dir damit klappt dann kann ich das einchecken. Das läuft dann ja unabhängig von meiner Baustelle...

Danke schon mal...

Grüße
Reiner