Sonos steuern

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

Vorheriges Thema - Nächstes Thema

poempel

Zitat von: poempel am 27 Juni 2014, 10:49:57
Nochmal eine Frage zum automatischen Playlist-Laden:

Ich habe bei mir jetzt eingebaut, dass wenn mein Presence-Status von absent auf present wechselt, die Sonos Komponenten per IT-Steckdose wieder eingeschaltet werden, anschließend 80 Sekunden gewartet wird und dann der Radiosender PULS geladen wird.
Manchmal funktioniert es und manchmal schmiert mir FHEM komplett ab und reagiert nicht mehr. Dann muss ich den kompletten Raspberry Pi neu starten.

Das Logfile gibt folgendes aus:

2014.06.26 17:22:46 2: IT set SonosPlaybar off
2014.06.26 21:17:37 1: Including fhem.cfg
2014.06.26 21:17:38 3: telnetPort: port 7072 opened
2014.06.26 21:17:40 3: WEB: port 8083 opened
2014.06.26 21:17:40 3: WEBphone: port 8084 opened
2014.06.26 21:17:40 3: WEBtablet: port 8085 opened
2014.06.26 21:17:42 3: Opening CUL0 device /dev/ttyACM0
2014.06.26 21:17:43 3: Setting CUL0 baudrate to 9600
2014.06.26 21:17:43 3: CUL0 device opened
2014.06.26 21:17:43 3: CUL0: Possible commands: BCFiAZEGMKRTVWXefmltux
2014.06.26 21:32:33 1: SONOS0: Kein UPnP-Server gefunden... Starte selber einen und warte 8 sekunden darauf...
2014.06.26 21:32:41 3: Opening SonosPlayer device localhost:4711
2014.06.26 21:32:41 3: SonosPlayer device opened
2014.06.26 21:32:42 1: Including ./log/fhem.save
2014.06.26 21:32:42 1: statefile: Reading SonosPlayer_BRIDGE->presence must not be used out of statefile.
Reading SonosPlayer_Bad->AlarmList must not be used out of statefile.
Reading SonosPlayer_Bad->AlarmListIDs must not be used out of statefile.
Reading SonosPlayer_Bad->AlarmListVersion must not be used out of statefile.
Reading SonosPlayer_Bad->LastActionResult must not be used out of statefile.
Reading SonosPlayer_Bad->presence must not be used out of statefile.
Reading SonosPlayer_K__che->AlarmList must not be used out of statefile.
Reading SonosPlayer_K__che->AlarmListIDs must not be used out of statefile.
Reading SonosPlayer_K__che->AlarmListVersion must not be used out of statefile.
Reading SonosPlayer_K__che->LastActionResult must not be used out of statefile.
Reading SonosPlayer_K__che->presence must not be used out of statefile.
Reading SonosPlayer_Wohnzimmer->AlarmList must not be used out of statefile.
Reading SonosPlayer_Wohnzimmer->AlarmListIDs must not be used out of statefile.
Reading SonosPlayer_Wohnzimmer->AlarmListVersion must not be used out of statefile.
Reading SonosPlayer_Wohnzimmer->presence must not be used out of statefile.
Reading SonosPlayer_Wohnzimmer_LR->AlarmList must not be used out of statefile.
Reading SonosPlayer_Wohnzimmer_LR->AlarmListIDs must not be used out of statefile.
Reading SonosPlayer_Wohnzimmer_LR->AlarmListVersion must not be used out of statefile.
Reading SonosPlayer_Wohnzimmer_LR->presence must not be used out of statefile.
Reading SonosPlayer_Wohnzimmer_RR->AlarmList must not be used out of statefile.
Reading SonosPlayer_Wohnzimmer_RR->AlarmListIDs must not be used out of statefile.
Reading SonosPlayer_Wohnzimmer_RR->AlarmListVersion must not be used out of statefile.
Reading SonosPlayer_Wohnzimmer_RR->presence must not be used out of statefile.


Kann mir jemand sagen, was hier schief läuft? Ich werde leider daraus nicht schlau.

Danke!

Hat hierzu jemand vielleicht noch eine Idee?
Reinerlein vielleicht?

Reinerlein

Hi poempel,

leider habe ich da auch keine direkte Idee. Auf jeden Fall steht in deinem Log-Auszug nix, was auf einen Fehler hindeutet.
Diese Meldungen bezogen auf das Statefile sind normal. Es gibt ein paar Readings, die von Fhem nicht gespeichert werden dürften. Leider geht das nicht, man kann nur das Laden durch eine Meldung verhindern. Das, was du im Log siehst, ist das Ergebnis der Ladeunterdrückung aus dem Statefile...

Du könntest höchstens mal die Sonos-Logausgabe auf 5 hochsetzen, und mal sammeln. Wenn dann der Fehler auftritt, kann man dort mal reinschauen... Aber vorsicht: das wird groß...
Es geht hier auch nur um die Ausgaben des Sub-Prozesses, die im Normalfall nicht im normalen Fhem-Log landen. Dort sind dann alle Informationen drin, die von den Sonosplayern an Fhem gesendet werden, und die das Modul zurücksendet. Außerdem noch die Werte, die an Fhem weitergereicht werden...
Damit kann man mindestens mal die Stelle rausfinden, die zum Blockieren führt....
Tipps zum loggen stehen auch auf der Wiki-Seite.

Grüße
Reiner

der-Lolo

Hallo Reinerlein,
macht es eigentlich sinn dem Sonos Modul mitzuteilen wenn ich einen Teilnehmer abschalte?
Ich könnte ja bevor ich die Steckdose für meinen play3 abschalte das reading presence setzen...
Oder Gruppen auflösen, oder oder oder...

Was denkst du?

Reinerlein

Hallo der-Lolo,

das Modul ist eher auf Reaktionen der Player ausgelegt. Ich könnte es intern gar nicht verarbeiten, diese Informationen vorher zu besitzen :-)

Zu den Gruppierungen: Das ist vielleicht sinnvoll, damit die Original-Controller den Player schneller aus der Gruppe nehmen.
Allerdings bleibt er ja trotzdem standardmäßig in der Liste der verfügbaren Player.
Mein Modul meldet, wenn die Abwesenheit festgestellt wird, diese Informationen an das Sonos-System, sodass dieser Player auch aus den Listen verschwindet. Das sollte (wenn das Erkennen sauber funktioniert) im Prinzip ja ausreichen...

Mein Fazit dazu wäre: Lieber die Ursachen herausfinden, warum ein fehlender Player nicht erkannt wird, bzw. warum das Modul blockiert :-)

Grüße
Reiner

der-Lolo

Da komme ich scheinbar auch nicht weiter - ich war ja schon beim Sonos Second-Level support gelandet...
Wirklich helfen konnten die aber auch nicht.

Mir geht es ja auch aktuell eher um das ausschalten. Ich kann dem Modul, oder eben auch Sonos ja mitteilen das ich ausschalte, wenn Du das aber nicht verarbeitest bringt es ja nichts.



der-Lolo

Hallo Reiner,
ich habe glaube ich etwas herausgefunden.
Im offenem Terminal auf dem fhem gestartet wurde kommt wenn ich in fhemweb "shutdown erstarrt" eingebe folgendes...

Zitat
root@mediaCT:/opt/fhem# Loading device description failed with error: 500 Can't connect to 192.168.0.57:1400 (timeout) at FHEM/00_SONOS.pm line 2196 thread 1
Loading device description failed with error: 500 Can't connect to 192.168.0.57:1400 (timeout) at FHEM/00_SONOS.pm line 2196 thread 1
2014.07.03 23:25:28 3: SONOS0: Disconnecting client and shutdown server...
2014.07.03 23:25:28 3: SONOS0: Trying to kill Sonos_Thread...
2014.07.03 23:25:28 3: SONOS0: Trying to kill PlayerRestore_Thread...
2014.07.03 23:25:28 1: SONOS2: Restore-Thread wurde beendet.
Can't call method "kill" on an undefined value at FHEM/00_SONOS.pm line 4965, <$client> line 8.
192.168.0.57 ist vermutlich mein play3 der sich keine "saubere IP" abgeholt hat. Wäre es möglich IP-Adressen ausserhalb von 192.168.178.xxx zu ignorieren?

Reinerlein

Hallo der-Lolo,

leider geht das nicht. Das UPnP-Konzept ist ein Broadcast-Konzept, wo man einmal in das Netz reinpustet, dass man auf Antworten wartet, und dann tut man genau das.
Rein technisch sollten aber auch nur Antworten aus dem gleichen Subnetz wie deine Fhem-Hardware kommen können, da ein Router diese Broadcast-Anfragen nicht weiterleitet (deswegen kann man den Sonos-Controller ja auch nicht per VPN nutzen, was echt schade ist :-).

Ich habe hier in meiner Dev-Version gerade eine Möglichkeit in der Mache, einzelne IP-Adressen bereits von der Verarbeitung auszuschließen. Das bezieht sich dann aber mehr darauf, dass Antworten, die von einer IP kommen, die auf einer "Blacklist" steht, ignoriert werden. Ob das so funktioniert. wie ich mir das gedacht habe, probiere ich gerade noch... ob es dein Problem überhaupt lösen wird ist dabei aber auch eher fraglich.
Hier geht es um das Unterdrücken von einzelnen Netzkomponenten, die sich einfach als Sonos-Player ausgeben, und damit das Modul in die Knie zwingen, da dann gewisse Anfragen schiefgehen...

Du solltest mal auf die Suche gehen, zu welcher Komponente diese 192.168.0.57 wirklich gehört. Dann könnte man da vielleicht etwas untersuchen.
Vielleicht würde es natürlich tatsächlich helfen, wenn man diesen 57er dann einfach ignorieren könnte...

Ich sehe mal zu, dass ich den Stand mal ausführbar bekomme, das ist momentan gerade nicht der Fall :-)
Dann können wir das bei dir mal einsetzen und testen...

Grüße
Reiner

der-Lolo

Ich habe dieses problem mittlerweile mehrfach beobachtet - mir stellt sich die situation wie folgt dar...
Der Play3 kann sich nicht entscheiden ob er sich im Büro oder im Wohnzimmer anmelden soll, er nimmt daraufhin die von der Fritzbox angebotene IP Adresse nicht an - und gibt sich selbst eine in diesem anderem Subnetz.
Das Sonos Modul versucht zwar den play3 zu erreichen, das geht aber dann technisch nicht.

Ich frage mich nun warum das Modul überhaupt mitbekommt das der play3 da ist - Broadcast sagtest du schon...
Aber wenn die IP nicht ins mein Class C netz passt sollte doch eigentlich gar keine Kommunikation stattfinden können, oder?

In meinem Fall führt es jedenfalls manchmal - also nicht immer dazu das das Sonos Modul in einer Schleife landet und abstürzt bzw. nicht mehr ansprechbar ist.

Ich habe nicht genügend wissen um an einer solchen stelle eingreifen zu können, falls Du Ideen oder Änderungsvorschläge hast schreib sie hier in den thread - ich lese mit und versuche umzusetzen.

Gruß aus Berlin - Vielen Dank für Deine mühe...
Michael

Spartacus

Hallo,
ich habe im Sonos 2 Wecker definiert, die jeweils von Mo-Fr. arbeiten und je nach Ereignis (Ferien, Feiertag) ein- bzw. ausgeschaltet werden. Leider stellt diese Deaktivierung den Wecker im Sonos auf "Einmal" um und die Information "Mo-Fr" ist beim Aktivieren verloren. Ich könnte den Update Alarm Befehl auch mit den Wochentagen erweitern, aber warum ist das so? Ist das so gewollt?
{
if ((fhem("get Feiertag today") !~ m/none/))
{
   fhem ("set Sonos_Buero Alarm Update 203 {Enabled => 0}");;
   fhem ("set Sonos_Buero Alarm Update 269 {Enabled => 0}")
}
else
{
  if ((Value("Ferientag")))
   {
    fhem ("set Sonos_Buero Alarm Update 269 {Enabled => 1}");;
    fhem ("set Sonos_Buero Alarm Update 203 {Enabled => 0}")
   }
else
  {
   fhem ("set Sonos_Buero Alarm Update 203 {Enabled => 1}");;
   fhem ("set Sonos_Buero Alarm Update 269 {Enabled => 0}")
  }
}
}


Gruß,
Spartacus
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Reinerlein

Hi Spartacus,

das klingt ein bißchen so, als würde im AlarmList-Reading die Information über die Tage nicht korrekt abgelegt sein (das kannst du ja mal prüfen, steht dort ja im Klartext). Ist das vielleicht seit der neuen Software-Version von Sonos so?
Vielleicht wurde da etwas verändert; da ich die Alarme nicht benutze, würde ich das auch nicht mitkriegen...

Wenn ich wieder zuhause bin, kann ich mir das mal anschauen...

Grüße
Reiner

Spartacus

Hi Reiner,
yep! Das sieht so aus!
Ich habe Aktuell Alarm 269 im Sonos auf Mo-Fr. stehen.
So sieht das Reading aus:
{'269' => {'Recurrence_Thursday' => 0,'IncludeLinkedZones' => '1','Volume' => '3','Shuffle' => 1,'Recurrence_Wednesday' => 0,'ProgramURI' => 'x-sonosapi-stream:s99166?sid=254&flags=32','Repeat' => 0,'Recurrence_Once' => 0,'StartTime' => '08:00:00','Duration' => '','Recurrence_Sunday' => 0,'Enabled' => '0','Recurrence_Friday' => 0,'Recurrence_Saturday' => 0,'Recurrence_Tuesday' => 0,'RoomUUID' => 'RINCON_000E58F084FC01400','ProgramMetaData' => '<DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:r="urn:schemas-rinconnetworks-com:metadata-1-0/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"><item id="R:0/0/3" parentID="R:0/0" restricted="true"><dc:title>WDR2 Ruhrgebiet</dc:title><upnp:class>object.item.audioItem.audioBroadcast</upnp:class><desc id="cdudn" nameSpace="urn:schemas-rinconnetworks-com:metadata-1-0/">SA_RINCON65031_</desc></item></DIDL-Lite>','Recurrence_Monday' => 0},'203' => {'Recurrence_Thursday' => 1,'IncludeLinkedZones' => '1','Volume' => '6','Shuffle' => 1,'Recurrence_Wednesday' => 1,'ProgramURI' => 'x-sonosapi-stream:s99166?sid=254&flags=32','Repeat' => 0,'Recurrence_Once' => 0,'StartTime' => '07:00:00','Duration' => '','Recurrence_Sunday' => 0,'Enabled' => '0','Recurrence_Friday' => 1,'Recurrence_Saturday' => 0,'Recurrence_Tuesday' => 1,'RoomUUID' => 'RINCON_000E58F084FC01400','ProgramMetaData' => '<DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:r="urn:schemas-rinconnetworks-com:metadata-1-0/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"><item id="R:0/0/3" parentID="R:0/0" restricted="true"><dc:title>WDR2 Ruhrgebiet</dc:title><upnp:class>object.item.audioItem.audioBroadcast</upnp:class><desc id="cdudn" nameSpace="urn:schemas-rinconnetworks-com:metadata-1-0/">SA_RINCON65031_</desc></item></DIDL-Lite>','Recurrence_Monday' => 1}}

Ich kann leider nicht sagen, ob es vor dem 5.0er Update anders war, da ich keine Alarme mit fhem modifiziert habe.

Spartacus.
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Reinerlein

Hi Spartacus,

kannst du mal zum Testen einen Sonos-Alarmton für die beiden Alarme einstellen?
Ich habe das Gefühl, dass die Metadaten vielleicht zu einer Fehlinterpretation des Hashs führen könnten.

Leider darf man in ein Fhem-Reading nicht einfach alles eintragen. Das kodiere ich zwar, das kann aber ja auch mal schiefgehen...
Einzelne Tage sind in dem von dir geschriebenen Hash ja drin... die sollten dann eigentlich auch unverändert wieder an den Player gehen...

Grüße
Reiner

Spartacus

Hi Reiner,
habe jetzt beide Alarme auf "Sonos Wecksignal" gestellt, im Sonos beide Wecker auf Montag-Freitag eingestellt, danach den o.a. Code ausgeführt und der Alarm 269 steht anschließend wieder auf "aktiv" und "Einmal" (Ferientag=1)

Witzigerweise scheint Alarm203 zu funzen, denn wenn ich den Ferientag auf 0 setze, wird Alarm 203 korrekt behandelt! Ich lege den Alaram 263 mal neu an und teste es noch einmal.....

Spartacus..

Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Spartacus

#1063
Puuh!
Habe nun beide Alarme neu angelegt. Jetzt geht es bei keinem Alarm mehr.
Hier noch mal der Code:
{
if ((fhem("get Feiertag today") !~ m/none/))
{
   fhem ("set Sonos_Buero Alarm Update 335 {Enabled => 0}");;
   fhem ("set Sonos_Buero Alarm Update 338 {Enabled => 0}")
}
else
{
  if ((Value("Ferientag")))
   {
    fhem ("set Sonos_Buero Alarm Update 338 {Enabled => 1}");;
    fhem ("set Sonos_Buero Alarm Update 335 {Enabled => 0}")
   }
else
  {
   fhem ("set Sonos_Buero Alarm Update 335 {Enabled => 1}");;
   fhem ("set Sonos_Buero Alarm Update 338 {Enabled => 0}")
  }
}
}


und hier die Readings:
{'338' => {'Recurrence_Thursday' => 0,'IncludeLinkedZones' => '1','Volume' => '5','Shuffle' => 1,'Recurrence_Wednesday' => 0,'ProgramURI' => 'x-sonosapi-stream:s99166?sid=254&flags=32','Repeat' => 0,'Recurrence_Once' => 1,'StartTime' => '08:00:00','Duration' => '','Recurrence_Sunday' => 0,'Enabled' => '1','Recurrence_Friday' => 0,'Recurrence_Saturday' => 0,'Recurrence_Tuesday' => 0,'RoomUUID' => 'RINCON_000E58F084FC01400','ProgramMetaData' => '<DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:r="urn:schemas-rinconnetworks-com:metadata-1-0/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"><item id="R:0/0/3" parentID="R:0/0" restricted="true"><dc:title>WDR2 Ruhrgebiet</dc:title><upnp:class>object.item.audioItem.audioBroadcast</upnp:class><desc id="cdudn" nameSpace="urn:schemas-rinconnetworks-com:metadata-1-0/">SA_RINCON65031_</desc></item></DIDL-Lite>','Recurrence_Monday' => 0},'335' => {'Recurrence_Thursday' => 0,'IncludeLinkedZones' => '1','Volume' => '5','Shuffle' => 1,'Recurrence_Wednesday' => 0,'ProgramURI' => 'x-sonosapi-stream:s99166?sid=254&flags=32','Repeat' => 0,'Recurrence_Once' => 1,'StartTime' => '07:00:00','Duration' => '','Recurrence_Sunday' => 0,'Enabled' => '0','Recurrence_Friday' => 0,'Recurrence_Saturday' => 0,'Recurrence_Tuesday' => 0,'RoomUUID' => 'RINCON_000E58F084FC01400','ProgramMetaData' => '<DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:r="urn:schemas-rinconnetworks-com:metadata-1-0/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"><item id="R:0/0/3" parentID="R:0/0" restricted="true"><dc:title>WDR2 Ruhrgebiet</dc:title><upnp:class>object.item.audioItem.audioBroadcast</upnp:class><desc id="cdudn" nameSpace="urn:schemas-rinconnetworks-com:metadata-1-0/">SA_RINCON65031_</desc></item></DIDL-Lite>','Recurrence_Monday' => 0}}
Spartacus

Nachtrag:
übrigens werden jetzt immer beide Alarme auf "Einmal" umgestellt.
Hier noch mal das AlarmReading mit dem Sonos Wecksignal:
{'338' => {'Recurrence_Thursday' => 0,'IncludeLinkedZones' => '1','Volume' => '5','Shuffle' => 1,'Recurrence_Wednesday' => 0,'ProgramURI' => 'x-rincon-buzzer:0','Repeat' => 0,'Recurrence_Once' => 1,'StartTime' => '08:00:00','Duration' => '','Recurrence_Sunday' => 0,'Enabled' => '1','Recurrence_Friday' => 0,'Recurrence_Saturday' => 0,'Recurrence_Tuesday' => 0,'RoomUUID' => 'RINCON_000E58F084FC01400','ProgramMetaData' => '','Recurrence_Monday' => 0},'335' => {'Recurrence_Thursday' => 0,'IncludeLinkedZones' => '1','Volume' => '5','Shuffle' => 1,'Recurrence_Wednesday' => 0,'ProgramURI' => 'x-rincon-buzzer:0','Repeat' => 0,'Recurrence_Once' => 1,'StartTime' => '07:00:00','Duration' => '','Recurrence_Sunday' => 0,'Enabled' => '0','Recurrence_Friday' => 0,'Recurrence_Saturday' => 0,'Recurrence_Tuesday' => 0,'RoomUUID' => 'RINCON_000E58F084FC01400','ProgramMetaData' => '','Recurrence_Monday' => 0}}
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Reinerlein

Hi Spartacus,

hmmm... ich habe das gerade mal bei mir geschaut. Da sieht das noch normal aus.
Bei dir scheint aber auch ein Alarm immer noch ein Radiosender zu sein (WDR 2).

Bitte mach die beiden Alarme nochmal mit einem Sonos-Controller, nur einem Sonos-Buzzer-Ton, und an verschiedenen Tagen. Danach notfalls Fhem einmal neustarten, damit die Alarme auch wirklich neu eingelesen werden...

ich hoffe, dass wir dann mehr wissen...

Danke schon mal...

Grüße
Reiner