Sonos steuern

[Reinerlein]

Hi Wichtel,

kann es denn sein, dass bei dir der Port 1900 durch einen anderen Prozess belegt wird?
Dieser wird vom Modul als SSDP-Antwortport verwendet.
Wenn ja, sollte ich diesen Port vielleicht konfigurierbar machen... wobei Multicast-Ports von mehreren Prozessen gleichzeitig verwendet werden können, und von dieser Seite wohl keine Probleme zu erwarten sind

Ich habe die Zeile mal so eingefügt, und beobachte erstmal bei mir das Verhalten, bevor ich es einchecke

Danke für die Untersuchung und das herausfinden...

Grüße
Reinerlein

[Wichtel]

kann es denn sein, dass bei dir der Port 1900 durch einen anderen Prozess belegt wird?
Dieser wird vom Modul als SSDP-Antwortport verwendet.

Diese zentrale Frage habe ich für mich nicht schlüssig beantworten können.
Die Befehle

Code Auswählen Erweitern

sudo lsof -i -P |grep 1900
sudo lsof -i -P |grep LISTEN
lieferten zumindest nichts zurück, jetzt steht dort der Sonos-Prozess.

Dass der Port zumindest nicht dauerhaft blockiert ist, habe ich ausgeschlossen durch versuchsweises Starten eines weiteren Port-1900-Lauschers in Form der Linn Kinsky UPnP-Controller-App.

Unter OS X wird UPnP aber auch für Systemdienste wie die Bonjour-Netzwerkgeräteerkennung und die Fernwartungsfunktionen genutzt. Daher gehe ich davon aus dass hier grundsätzlich solch eine Mehrfachnutzung angesagt ist, wenn weitere Software dort mitspielen soll.

Edit: Linn KinSky...ich kaufe hiermit das "S".

[Reinerlein]

Hi Wichtel,

ich habe das mal untersucht. Unter Windows gibt es das Problem, dass dieses Attribut gar nicht definiert ist, und der Prozess damit stirbt. Das habe ich jetzt durch ein zweistufiges Verfahren in den Griff bekommen: Erst wird versucht den Socket mit diesem Flag zu öffnen, und wann das mit der "Ist-nicht-möglich"-Fehlermeldung verhindert wird, dann wird der bisherige Mechanismus verwendet...

Des Weiteren scheint es im Normalfall bei Multicast besser zu sein, es mit aktivem Flag zu verbinden (natürlich nicht für Windows ), da es auch kein Problem ist, wenn mehrere Empfänger dasselbe empfangen... Multicast eben...

Es könnte auch sein, dass eben diese Multicast-Empfangs-Sockets gar nicht aufgelistet werden, da es ja im Normalfall kein Problem ist (wenn man das Flag nutzen kann)...

Ich würde sagen, so kann ich es drin lassen... Da ich noch eine andere Änderung unter Beobachtung habe, werde ich das vermutlich erst Morgen einchecken...

Grüße
Reinerlein

[Wichtel]

Vielen Dank dass du dich dem annimmst. Und ganz besonders dafür dass dieses großartige Modul existiert, so langsam fängt es hier auch an zu glänzen.
Ich staune jedesmal wieder wenn ich in den Quellcode schaue, wie umfangreich es doch schon ist...

Falls es mit der Try-and-error-Methode bei der Portreservierung anderweitig stört, wäre vermutlich auch eine Abfrage auf die von fhem beim Start festgestellte "os:darwin"-Angabe möglich. Ich weiß nur leider nicht wie.

[Spartacus]

Hallo zusammen,
ich bekomme seit ein paar Tagen folgenden Fehler im Lo:

Code Auswählen Erweitern

400-URL-Absolute-Error! Location: "192.168.1.89:51255", Content: "400 URL must be absolute
" at ./FHEM/00_SONOS.pm line 4117 thread 1
Loading device description failed with error: 400 URL must be absolute (Location: 192.168.1.89:51255) at ./FHEM/00_SONOS.pm line 4117 thread 1

192.168.1.89 ist aber überhaupt kein Sonos Device. Es ist ein "normaler" PC. Weiß jemand was das bedeutet, bzw. wie ich es abstellen kann?

Christian

[Reinerlein]

Hi

@Christian: Da schummelt sich wieder mal ein Nicht-Sonos-Gerät dazwischen.
Am Besten mit dem Attribut "ignoredIPs" ausschließen...

@Wichtel: Das ist so kein Problem, da es wohl auf allen Nicht-Windows-Plattformen direkt funktioniert, und unter Windows dann eben einen internen Fehlversuch hat, der aber auch nicht sooo lange dauern dürfte...

Grüße
Reiner

[JoWiemann]

Oder über das Attribut usedonlyIPs eine kommaseparierte Liste Deiner Sonos Geräte definieren. Alle anderen IPs werden ignoriert.

Grüße Jörg

[Spartacus]

Hallo,
Besten Dank für den Tipp!
Christian

[Masterfunk]

Hallo,

habe eben ein Apple Music Abo abgeschlossen.
Im Modul wird beim Abspielen aber kein "TrackProvider" angegeben.
Liegt das an Sonos (liefert den nicht) oder fehlt der im Modul?

Gruß Detlef

[Reinerlein]

Hi Detlef,

da wird leider nix von Sonos geliefert... Das mache ich selber, und bedeutet immer einen manuellen Eintrag .

Kannst du mir mal die TrackURI zukommen lassen? Dann trage ich das mal ein...

Grüße
Reiner

[Masterfunk]

Das steht aktuell drin:

x-sonos-http:song%3a31097204.mp4?sid=204&flags=8224&sn=12

Gruß Detlef

[Reinerlein]

Hi Detlef,

OK, ich habe jetzt mal den Anfang bis song als Erkennung eingebaut, also

Code Auswählen Erweitern


^x-sonos-http:song
als regulären Ausdruck.

Passt das bei den meisten (am Besten bei allen ) Titeln?

Grüße
Reiner

[Masterfunk]

Scheint zu passen.
Hab mal jede Menge ausprobiert, bleibt immer gleich.

Gruß Detlef

[sebbi2k5]

Guten Abend zusammen,

ich bin seit 2 Tagen Besitzer eines Sonos Play 1 und habe diesen bereits erfolgreich in FHEM integriert.

Nun hänge ich jedoch seit Stunden an einem Problem, bei dem ich nicht mehr weiterkomme:

Ich möchte per HTTP Request (fhem?cmd= ...) einen Radio Sender starten. Teste ich dies über die Player Seite in der FHEM Oberfläche, funktioniert alles bestens. Rufe ich jedoch den Sender per URL auf, klappt es nicht. Eine Spotify Playlist lässt sich über diesen Weg ohne Probleme ansteuern. Hat da jemand eine zündende Idee?

Hier die URL, die ich zum Aufruf verwende:

192.168.1.56:8083/fhem?cmd=set%20Sonos_Bad%20StartRadio%201LIVE%20diggi%20-%20Multimedia%20-%201LIVE&fwcsrf=TokenID

Viele Grüße
Sebastian

[Reinerlein]

Hi Sebastian,

ich fürchte das wird unschön, da du die Leerzeichen wahrscheinlich doppelt maskieren musst:
1. Damit sie bei Fhem ankommen
2. Damit sie als ein Parameter im Modul ankommen

Versuch mal

Code Auswählen Erweitern


set+Sonos_Bad+StartRadio+1LIVE%2520diggi%2520-%2520Multimedia%2520-%25201LIVE
Das ist noch einigermaßen lesbar

Grüße
Reiner