Sonos steuern

[justme1968]

hallo reinerlein,

mein play:1 ist seit gestern endlich da und ich bin begeistert. auch von deinem modul

mir sind aber beim ersten spielen noch ein paar dinge aufgefallen:

- das modul lief während der installation schon und hat ein seltsames player device angelegt das sich auch nicht steuern lies. ein mal ist auch komplett alles abgestürzt. sollte man das modul anhalten wenn man einen neuen player in betrieb nimmt?

- targetSpeakDir (und vermutlich auch noch andere attribute) werden erst nach einem modify auf das modul tatächlich übernommen. liegt das eventuell daran das es im externen prozess verwendet wird?

- ich habe alle 10 sekunden eine 'Connection accepted from localhost:56983' meldung in meinem stdout log. da kommt ganz schön was zusammen.

- ich hatte zwischendurch das problem das der automatisch gestartete prozess nicht automatisch beendet wurde und alle 10 sekunden ein hello und goaway im log. wenn man nicht ins log schaut sieht man nicht wirklich das etwas schief geht.

- beim radio hören kommen auch recht viele events zusammen. im log (Received Transport-Event/End of Transport-Event) als auch in fhem. wäre es hier sinnvoll das log level dieser nachrichten zu ändern und im device event-on-change automatisch zu setzen?

bis auf die (unnötigen?) meldungen im log und events war das meiste nach der kompletten installation weg und ist erst mal nicht mehr aufgetreten.

ansonsten bin ich wie gesagt erst mal begeistert und der zweite player ist auf dem weg

gruss
  andre

[Reinerlein]

Hi Andre,

herzlichen Glückwunsch zu deinem Sonos

Hier mal ein paar Anmerkungen zu deinen Fragen:
- Die Player melden sich manchmal bereits per UPnP, sobald sie an sind. Dann haben sie aber noch keine vernünftigen Namen und Positionen im System erhalten. Das macht man ja erst mit dem Controller.
Es ist tatsächlich empfehlenswert (und auch so im Wiki erwähnt ), die Landschaft erst fertig zu haben. Das bedeutet für Neuanschaffungen entweder Umbenennungen (es ist ja Hauptsächlich der Name der da falsch ist) oder eine kurze Fhem-Pause. Ich bevorzuge letzteres, da die Einrichtung des Players ja sehr schnell geht...

- Zu dem targetSpeakDir: Wird tatsächlich nur im SubProzess benötigt. Ich habe mich dagegen entschieden, Attribute zur Laufzeit durchzureichen. Das Durchreichen selbst ist ja kein Problem, aber die Verwendung der neuen Werte sorgt mitten im Betrieb nicht immer für sinnvolle Ergebnisse (und ich müsste auch die Threads dort erstmal alle anhalten, und mit den neuen Werten anstarten). Ich habe mich also dazu entschlossen, diese nur beim Start des SubProzesses zu übermitteln...

- Wenn das System sauber läuft, solltest du den Verbose-Level am Sonos-Device auf 0 oder 1 stellen. Dann bleiben diese ganzen Meldungen weg. Wenn etwas untersucht werden muss, dann kann man diesen ja wieder hochstellen. Auch hier: Das Attribut wird nicht zur Laufzeit übertragen...

- Zu den Transport-Events: Diese Logs kannst du ja wie oben beschrieben unterdrücken. Die Events auf Fhem-Ebene werden für jedes Reading automatisch nur bei Änderung des Wertes durchgeführt. Sonst wäre Fhem bei mehr als einem Player sehr schnell platt und würde nur noch gleiche Readings setzen und die Events dazu ausführen...

Grüße
Reinerlein

[justme1968]

der zweite ist schon im anflug

den hinweis auf die landschaft hatte ich gelesen aber nicht mit der inbetriebnahme in verbindung gebracht. aber eigentlich ist es ja klar.

für die attribute wäre es vielleicht hilfreich wenn das dokumentiert ist das sie nicht ohne neustart verändert werden können und vielleicht sogar das das speak kommando eine meldung ausspuckt wenn das attribut gar nicht gesetzt ist.

reicht es den sub prozess zu killen und mit einem modify auf das sonos device neu starten zu lassen? wie wäre es das zumindest halb automatisch mit einem restart kommando zu ermöglichen? oder gleich zwei kommandos draus machen. eins zum stoppen und eins zum starten. dann könnte man damit auch bei der einrichtung den sub prozess anhalten und nicht ganz fhem.

ich muss mal schauen woher die events im fhem kommen.

gruss
  andre

[Reinerlein]

Hi Andre,

ich habe das in der Doku korrigiert, wird dann beim nächsten veröffentlichen dabei sein...

Ich bin gerade dabei ein Attribut "disable" am Sonos-Device einzubauen, der den Subprozess beenden und starten kann...
Dann kann man das Ding temporär auch mal abschalten...

Selber den Prozess zu killen wird nicht viel bringen, da er praktisch sofort neu gestartet wird. Diese Überprüfungen habe ich ja schließlich eingebaut, da er sich ab und an mal verkrümelt hatte
Allerdings kann es natürlich immer noch passieren, sollte aber deutlich seltener geworden sein...

Grüße
Reinerlein

[justme1968]

das klingt gut!

danke
  andre

[aherby]

Hallo Reinerlein,

ja sind ein paar Songs-Geräte geworden dachte man kann sich ein gutes Surround-System bauen aber an einen AV-Receiver kommt es nicht ran.

Also vorhanden sind ein Sub, zwei Play 1 und die Soundbar im Wohnzimmer.
Der andere Play1 steht im Bad.

Sub
Devicename: Sonos_Wohnzimmer_SW
fieldType: SW

Play 1 links
Devicename: Sonos_Wohnzimmer_LR
fieldType: LR

Play 1 rechts
Devicename: Sonos_Wohnzimmer_RR
fieldType: RR

habe jetzt noch mal die Einträge von Sonos aus der cfg genommen und den FHEm neu gestartet.
Nun sieht es so aus, dass nur ein Bedienend erzeugt wird.

Ach den Befehl hatte ich schon so aufgebaut aber scheinbar als einer alten fhem.cfg kopiert.

"define Radio.YouFM notify BT5_YouFM_Hr3.Short.* set Sonos_Wohnzimmer RemoveMember Sonos_Wechselraum ;; set Sonos_Wechselraum PlayURI http://metafiles.gl-systemhaus.de/hr/youfm_2.m3u 21"

Dieser Befehl lässt sich sicher nur an der einen Stelle kürzen:
ALT:
define Soundmorgens_PLAY_Week at *06:15 { fhem("set Sonos Groups [Sonos_Wohnzimmer, Sonos_Wechselraum] ;; set Sonos_Wohnzimmer PlayURI http://metafiles.gl-systemhaus.de/hr/youfm_2.m3u ;; set Sonos_Wohnzimmer Volume 10 ;; set Sonos_Wechselraum Volume 15") if($wday == 1 || $wday == 2  || $wday == 3  || $wday == 4  || $wday == 5 ) }
attr Soundmorgens_PLAY_Week disable 0


Neu:
define Soundmorgens_PLAY_Week at *06:15 { fhem("set Sonos Groups [Sonos_Wohnzimmer, Sonos_Wechselraum] ;; set Sonos_Wohnzimmer PlayURI http://metafiles.gl-systemhaus.de/hr/youfm_2.m3u 10 ;; set Sonos_Wechselraum Volume 15") if($wday == 1 || $wday == 2  || $wday == 3  || $wday == 4  || $wday == 5 ) }
attr Soundmorgens_PLAY_Week disable 0


MFG

[Reinerlein]

Hallo aherby,

danke für die Infos. Kannst du mir noch kurz den fieldType der Playbar zukommen lassen?
Dann habe ich die Aliasnamengeschichte drin...

Wenn ich dann fertig mit dem disable bin, wird es veröffentlicht...

Grüße
Reinerlein

[CQuadrat]

Hallo Zusammen,

ich nutze das im Wiki

http://www.fhemwiki.de/wiki/Sonos_Anwendungsbeispiel#Beispiele

beschriebene Konzept, um beim Einschalten (Strom an) eines Plays sofort mit einem Radiosender zu starten. Das klappt auch soweit ganz gut.

Allerdings habe ich den Effekt, dass beim Neustarten von Fhem das entsprechende appeared-notify ebenfalls getriggert wird, was dann dazu führt, dass beim FHEM-(Neu)Start der Play anfängt zu spielen. Das ist insbesonders dann irritierend, wenn ich nicht zuhause bin und z.B. remote FHEM neustarte -> reduzierter WAF 

Lässt sich dieses Verhalten irgendwie einfach(!) vermeiden?


Danke und Gruß

Christoph

[Reinerlein]

Hi Christoph,

du könntest vor dem Setzen und Starten des Abspielens prüfen, ob bereits ein currentTrackURI gesetzt ist.

Z.B. so:

Code Auswählen Erweitern


define Sonos_Schlafzimmer_Appeared_Notify notify Sonos_Schlafzimmer:presence:.appeared { if (ReadingsVal("Sonos_Schlafzimmer", "currentTrackURI", "") eq "") { fhem "sleep 5 ;; set Sonos_Schlafzimmer StartFavourite myFavouriteName" } }


Mit dem sleep musst du mal rumspielen. Da ich nur einen Pi habe, muss ich dort manchmal ein paar Wartezeiten einplanen...

Grüße
Reinerlein

[CQuadrat]

Danke, das muss ich mal ausprobieren.

[justme1968]

ich hoffe du entschuldigst die ideen und vorschläge die ich als neueinsteiger habe...

wie wäre es wenn man bei der angabe von radios und favourites auch eine regex statt url encoded verwenden könnte?

du hast ja hier die liste der möglichen werte. im harmony modul habe ich damit gute erfahrungen gemacht.

gruss
  andre

[Reinerlein]

Hi Andre,

keine Sorge... Ideen sind wichtig

Ich schaue mir mal an, wie ich das einbauen kann...

Grüße
Reinerlein

[justme1968]

ich versuche gerade den vorschlag von oben mit der auswertung von currentTrackURI im notify auf presence:.apeared umzusetzen.

aber eigentlich kann es doch so gar nicht funktionieren:

- der player spielt einen radio stream, currentTrackURI hat einen wert
- der player wird aus der steckdose gezogen
- der player geht auf disapeared
- currentTrackURI wird nicht geändert sondern hat noch den alten wert
- beim einstecken wird das notify getriggert, aber currentTrackURI hat immer noch den alten wert und die if abfrage läuft ins leere
- jetzt erst wird der status des players aktualisiert und die readings neu gefüllt

damit das funktionieren kann bräuchte man doch ein reading das beim wechsel auf disapeared schon zurück gesetzt wird. z.b. in einem notify auf disapeared.

gruss
  andre

[Reinerlein]

Hi Andre,

das stimmt soweit. Nur klappt es bei mir in den meisten Fällen, und ich überlege gerade warum

Das sind vom Player zwei verschiedene Events:
1. Discover-Event: Der Player teilt mit, dass er da ist. Hier wird presence auf "appeared" gesetzt
2. Transport-Event: Der Player teilt mit, dass momentan kein Titel aktiv ist. Hier werden die Readings auf leer gesetzt
3. Hier sollte jetzt erst die Überprüfung des Readings erfolgen

Vielleicht kommen die schnell genug hintereinander?
Ich würde auf jeden Fall jetzt noch einbauen, dass die Titelreadings beim initialen Erkennen des Players zurückgesetzt werden.
Dann sollte es auf jeden Fall klappen...

Grüße
Reinerlein

[der-Lolo]

Hey Andre,
schön das Du nun auch in der Sonos Welt eingetaucht bist...
Hast du schon gesehen das Du Sonos auch im Harmony Hub anmelden kannst?