Sonos steuern

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

Vorheriges Thema - Nächstes Thema

peter79

#435
Hi Reiner,

ZitatAllerdings sollte wirklich was auf der Konsole rauskommen, da wird so einiges gemeldet. Aber wir haben jetzt ja erstmal einen Anhaltspunkt den ich verfolgen/ausmerzen kann. Dann schauen wir weiter...

--> OK, hatte mich etwas falsch ausgedrückt, natürlich wird mit "verbose 5" viel gelogged - aber während des Absturzes halt leider nichts, was nicht sonst auch kommt (z.B. die normalen keepalives). Hier noch einmal dargestellt - das ging diesmal schneller als ich nach aufstecken des IPMIs auf den Switch aus dem Keller wieder hochlaufen konnte  ;-)

2013.10.17 23:21:14 4: SONOS2: IsAlive-Event UDN=RINCON_000E58EFB30601400_MR
2013.10.17 23:21:14 5: SONOS2: Location: http://192.168.1.106:1400/xml/device_description.xml
2013.10.17 23:21:14 5: SONOS2: PingType: icmp
2013.10.17 23:21:14 4: SONOS2: 192.168.1.106 is alive
Thread 1 terminated abnormally: Can't use string ("
    ") as an ARRAY ref while "strict refs" in use at FHEM/lib/UPnP/Common.pm line 219, <$client> line 2.
2013.10.17 23:21:24 4: SONOS2: IsAlive-Event UDN=RINCON_000E58F2222801400_MR
2013.10.17 23:21:24 5: SONOS2: Location: http://192.168.1.107:1400/xml/device_description.xml
2013.10.17 23:21:24 5: SONOS2: PingType: icmp
2013.10.17 23:21:25 4: SONOS2: 192.168.1.107 is alive


Zitathmm... eigentlich sage ich in meiner Broadcast-Such-Anfrage, dass ich Geräte haben möchte, die den Typ "urn:schemas-upnp-org:device:ZonePlayer:1" haben. Alles andere sollte dann auch nicht gemeldet werden.
Aber du hast natürlich Recht, ich prüfe in meiner Callback-Methode dann nicht mehr, was sich da eigentlich gemeldet hat, sondern laufe einfach mit meiner Verarbeitung los :-)

--> Soweit ich im Dump sehen kann, erfolgt vor der SSDP-Message des IPMI keine Broadcast-Suchanfrage. Bin mir nicht sicher, wie Du das hier gemeint hast, aber für mich sieht es so aus, als würde die Callback-Methode dann eher auf alles hören, was an UPnP SSDP-Messages übers Netz kommt oder liegt das Problem vielleicht schon in der UPnP/Common.pm lib?! Bin hier im Moment nicht im Bilde, wie das alles zusammenspielt. Wenn ich mir Deinen Code anschaue, sollte da aber soweit ich es sehe wirklich eine Logging-Message kommen...

Mach Dir bitte keine Stress - ich habe für mich ja erst einmal eine Lösung gefunden (Switch-Port-Shutdown für das IPMI, so oft brauche ich das zum Glück nicht...) - wie gesagt, könnte ich mir aber vorstellen, dass es früher oder später auch andere über dieses Problem stolpern - mit welcherm UPnP-Gerät auch immer.

PS: Nach Abschaltung des IPMI lief das ganze bis zum Zeitpunkt als ich den Port wieder aufgesteckt hatte :)

Viele Grüße
Peter

JoeALLb

Hallo Reiner, sorry,
das hätte ich genauer schreiben sollen, aber das ist mir schon aufgefallen.
Ich dachte nur, die Logdaten wären dennoch hilfreich, um das eventuell abzufangen...

Gibt es für das URLencoden eigentlich eine Funktion, damit soetwas ähnliches wie
{fhem (set Sonos_Wohnzimmer LoadRadio $encode("BAYERN 3") } möglich wird?

Gibt es eine Möglichkeit, schnell alle Sonosse abzuschalten? Derzeit schalte ich alle nacheinander ab,
was leider eine weile dauert.... Im Controller gibt es die Funktion "Alle Anhalten", die deutlich schneller reagiert.
Ich dachte nur, dass es vielleicht in einen einzigen Aufruf gesteckt werden kann......



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

Hallo zusammen,

@Peter: Ich bin da gerade am Untersuchen, wie sich ein Zoneplayer vielleicht von anderem unterscheiden läßt. Das sollte wohl eigentlich möglich sein :-)
nur kurz zum Komzept von UPnP: Man startet eine Suchanfrage als Broadcast in das lokale Netz. Dabei gibt man an, von welchen Grätetypen man Discover-Nachrichten erhalten möchte. Das wird dann im Normallfall gefiltert (ob das erst in der UPnP-Library erfolgt, oder das Device sich gar nicht erst meldet, weiss ich auch gerade nicht so genau), und über meine Callback-Methode gemeldet. Das bedeutet, daß dein IPMI auf eine solche Suchanfrage reagiert, und in meiner Callback-Methode landet. Im Prinzip ist es wurscht, warum genau. Das muss ich auf jeden Fall abfangen :-)
Leider ist bei meinem Rechnersystem gerade ein Problem aufgetreten um das ich mich kümmern muss. Ich bitte da also kurzzeitig um etwas Geduld.

@JoeALLb: Mit dem zentralen Stop für alle Sonos-Geräte schaue ich mal, wie der Original-Controller das macht. Aber ich gehe davon aus, dass der auch nur an alle nacheinander eine Nachricht sendet. Aber mal schauen...
Zu den Playlistnamen: Wenn das Sonos Modul läuft, dann hat dein Perl offensichtlich das URI::Escape Paket geladen (ist eine Voraussetzung:-). Das bedeutet, du kannst mit dem Aufruf vonuri_escape('Meine Playlist')das Leerzeichen umwandeln lassen. Ich verwende auf der Befehlsempfangsseite das Pendant "uri_unescape()" aus diesem Paket. Das sollte also passen...

Wie gesagt, ist mir gerade ein Problem Dazwischengekommen und damit meine Entwicklungsumgebung abhanden gekommen... Es gibt hier also eine kurze Verzögerung in der Weiterentwicklung...

Grüße Reiner

JoeALLb

Hallo!

Habt ihr eine Idee? Seit heute wird folgender text immer in der Küche, statt im Wohnzimmer ausgegeben:
set Sonos_Wohnzimmer Speak 50 de Durchsage Test

Ich habe fhem neu gestartet und habe noch immer das selbe ergebnis! Bin echt ratlos!
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

Hallo JoeALLb,

das Modul unterscheidet die einzelnen Player anhand der eindeutigen UDN. Hast du deine Sonos Landschaft vielleicht umbenannt?
Das würde Fhem nicht weiter interessieren, da er ja immer noch die alten UDNs zu den alten Namen hat. Das kannst du kontrollieren, indem du an deinem SonosController die Informationen "Über das Sonos-System" ausgeben läßt, und mit den bei Fhem angegebenen UDNs vergleichst.
Die UDN ist das Kürzel "RINCON_" gefolgt von der Seriennummer (was auch die Hardware-MAC-Adresse des Geräts ist) ohne Bindestriche, gefolgt von der Konstanten "1400_MR".

Schau mal, ob die Fhem-Playernamen noch mit den entsprechenden Sonos-Playernamen übereinstimmen...

Grüße Reiner

JoeALLb

Hallo Reiner,

danke für die Nachricht! Nein, ich habe nichts umbenannt und habe sie auch nicht umgestellt.
Aber jetzt geht es wieder. Ich habe alle in eine Gruppe geschmissen und die Gruppe dann einzeln wieder aufgelöst: --> Jetzt kommen die Befehle
(es gab auch noch andere..) wieder beim korrekten Gerät an.
Passiert ist es erstmals, nachdem ich solch einen Befehl an ein Gerät geschickt habe, das sich gerade in einer anderen Gruppe befunden hat....

seltsam, und meine Frau war ganz schön überrascht!!! :D
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,

ok, damit hast du einen Bug entdeckt. Der Befehl "AddMember" ist stillschweigend davon ausgegangen, dass der hinzuzufügende Player "frei" ist.
Das muss ja nicht immer so sein :-)

Dabei entstehen wirklich lustige Konstellationen (das sieht man im Original-Controller nur anhand der Abspiellisten), dass ein Player z.B. zwar alleine eine Gruppe bildet, aber nicht sein eigener Koordinator ist :-)
Das ist doch eher ungewöhnlich...

Ich werde das also entsprechend anpassen...

Als Notbehelf kann man den Befehl "set Groups" verwenden, und dort alle Player als jeweils eigene Gruppe angeben. Dann räumt er damit wieder auf...

Danke für die Meldung.

Grüße, Reiner

der-Lolo

Hallo Reiner,
Ich stolper ab und an über Abstürze meines Netzwerks, in diesem Zusammenhang ist mir der Avahi server aufgefallen der auf dem Raspi läuft, ich vermute mal das es für das Sonos Modul gebraucht wird...
Kannst du mal was zu avahi sagen? Ich fand im ubuntu wiki einen Artikel in dem zum Beispiel beschrieben wird das man IPv6 ausklammern könne falls nicht benutzt...
Was sind deine Anforderungen an avahi?

Reinerlein

#443
Hallo Der-Lolo,

mir ist kein (direkter) Bezug des Sonos-Moduls zu avahi bekannt. Ich kannte das auch noch gar nicht. Es kann natürlich sein, dass ein Perl-Modul das irgendwo mitbringt.

Ein Blick auf Wikipedia bzgl. avahi hat aufgezeigt, dass auch ein grafischer Desktop dieses Modul mitbringen könnte. Kann es sein, dass du sowas auf deinen Pi installiert hast?

Edit: Es könnte auch von Bonjour gekommen sein. Das scheint eine zeroconf-Implementierung von Apple zu sein...

Grüße Reiner

det.

Hallo Reiner,
mal wieder ein Statusupdate von mir. Nach kompletter Neuinstallation von Linaro Linux, Perl und Fhem auf einem Cubieboard2 läuft Dein Modul auch bei mir. Es lag also wirklich an der Ordnerstruktur des Busware RPI Image vom September letzten Jahres, welches ich für meine 3 RPI immer nur geklont und angepasst hatte. Nach dem ersten Eindruck rennt das alles sehr schnell.
LG
det.

Christoph

Zitat von: FHEM-Freak am 15 Oktober 2013, 12:19:27
Hoffe das die bald erhältlichen Sonos Play1 auch funktionieren.

Funktioniert ohne Probleme  :)

Reinerlein

Hallo zusammen,

von mir auch mal wieder eine Meldung.
Ich habe meinen Rechner-Ausfall nun hinter mich gebracht, und kann mich wieder um das Modul kümmern.
Ich bin gerade an dem Phänomen von komischen Lautstärken bei Durchsagen bei Gruppen. Ansonsten steht ja noch der eine oder andere Punkt auf der Liste...

Ich denke, dass es am Wochenende was neues geben könnte...

Grüße
Reiner

Will

Hallo zusammen,

Wieder mal ein neues fhem aufgesetzt und mich auf das neue sonos Modul gefreut. Zusätzlich betreibe ich eine neue sonos Komponente. Jetzt laufen play 1, play 3, und ein connect.
Mit dem neuen sonos Modul läuft es aber noch nicht so rund:
Alle player werden erkannt und die readings sind korrekt (sehe ich wenn ich mit der sonos APP bediene). Den play 1 kann ich über fhem bedienen....wenn ich dann den connect an machen will (play) geht der play 1 an. Wenn ich den play1 trenne, passiert gar nichts, also ein play bewirkt nichts....
Meine notifies habe ich umgestellt auf das "große S" ;-)

Hat da jemand eine Idee?

Danke

Wil

Sent from my Nexus 7 using Tapatalk


Will

Ach ja, stelle gerade fest, dass VolU und VolD und MuteT funktionieren, Play und Pause jedoch nicht.....die scheinen immer noch an den nplay1 zu gehen, obwohl abgesteckt (bei diesen befehlen motzt der log, dass der player bathroom - der play1- dissappeared ist)....

W

Sent from my Nexus 7 using Tapatalk


Reinerlein

Hi Will,

kann es sein, dass diese beiden vorher eine Gruppe gebildet hatten? Vielleicht sogar so, dass der nun fehlende Play1 der Gruppenmaster war?

Das würde darauf hindeuten, da die Lautstärke natürlich immer direkt an den entsprechenden Player gesendet wird, und Play/Pause usw. an den sogenannten Gruppenmaster...

Ich fürchte, ich musss mir noch ein paar Gedanken um dieses ganze Gruppengetue machen. Diese Gruppen werden in meinen Augen nicht sauber von Sonos behandelt, sonst würden die verbleibenden Mitglieder eine Nachricht senden, dass sich der Zustand verändert hat... So aber bleibt alles beim Alten, und die Controller gucken in die Röhre, und senden ihre Signale an den falschen Player...

Grüße Reiner