Sonos steuern

[strauch]

Ich setzte zur Zeit das Sonos und XBMC Modul ein, was schade ist, in Sonos muss Play/Pause etc. groß geschrieben werden bei XBMC klein. Ich kann also kein notify machen nach dem Motto:

Code Auswählen Erweitern

define notify_Telefon notify Fritzbox:.*ring set sonos,xbmc pause

sondern ich muss

Code Auswählen Erweitern

define notify_Telefon notify Fritzbox:.*ring set sonos Pause;set xbmc pause

schreiben, keine große Sache, aber vielleicht können sich ja die Owner zu einer Schreibweise durchringen, oder groß und klein erlauben?!
Wusste jetzt auch nicht wohin ich das schreiben soll, hier oder im xbmc Thread.
Danke

[herman]

Wie sieht das denn mit den Umlauten z.B. bei den Titeln aus?
Bei mir wird das alles auf der Weboberfläche normal dargestellt (auch in den FileLog-Dateien dazu)...

Hallo Reiner,

die Titel sehen gut aus.

Viele Grüße,
Merhan

[JoeALLb]

Hallo Reiner,

Korrekt,  es war ein Notify. Habe ihn aber soeben nochmal abgesetzt,  und alles klappte.

Ich habe diese Befehle auf eine Fernbedienung gelegt und vermute nun,  dass irgendeine Kombination der Befehle das auslöst....  Wenn Du eine Idee hast,  was ich prüfen kann,  dann immer her damit.

LG Joe

Gesendet von meinem Xperia Pro mit Tapatalk

[det.]

Hallo Jo,
der SONOS-Player scheint intern recht lange zu brauchen um Befehle abzuarbeiten (unabhängig von FHEM). Ich hab das mit folgender Befehlsfolge zum Einschalten über FS20 Funksteckdose <Medien> inzwischen gelöst. Dauert zwar etwas, ist sicher nicht effektiv programmiert, aber funktioniert sehr zuverlässig:

define Sonos_Notify notify Medien:on {\
fhem "define SonosStart0 at +00:00:45 set Sonos_Wohnzimmer LoadRadio Radio%%20Paradise";;\
fhem "define SonosStart1 at +00:01:00 set Sonos_Wohnzimmer Volume 15";;\
fhem "define SonosStart2 at +00:01:02 set Sonos_Wohnzimmer Play";;\
fhem "define SonosStart3 at +00:01:03 set Sonos_Wohnzimmer Mute off"\
}

[JoeALLb]

Hallo Det, danke für die Info, ich werde damit herumspielen.
Verstehe aber nicht, warum Du erst nach 45 Sekunden beginnst? Direkt am Anfang fürfte FHEM doch nicht ausgeladtet sein, oder?

Frage an Reiner:
Vielen Dank für die StoppAll-Funktion. Diese ist bisher echt zuverlässig und geht deutlich schneller wie das einzelne Ausführen der Befehle.
Nun die Frage: Wäre solch ein "Stapeln" von Befehlen eventuell auch in anderen Bereichen ein Vorteil? Ich kenne die Struktur von Upnp leide rüberhaupt nicht, könnte mir aber vorstellen, dass ein Befehl: "Starte mit Lautstärke 40" effizienter ist als beides getrennt....

[Reinerlein]

Hi Zusammen,

im Prinzip gibt es diese Warteschlange natürlich schon.
Jeder Befehl, den man von Fhem an den SubProzess übergibt, wird dort erstmal in eine Warteschlange gelegt, die der Reihe nach verarbeitet wird.
Der Spezialfall (Stop|Pause)All wird halt als ein Befehl an den SubProzess übergeben, und sendet dort (wie immer) die Befehle an jeden Player einzeln.
Ein Zusammenfassen von Befehlen gibt es in UPnP nicht. Jede Anweisung ist ein einzelnes XML-Strukturiertes Paket von Informationen (ein sogenanntes SOAP-Paket), welches auch mit einem solchen beantwortet wird.

Das Hauptproblem an dieser Stelle dürfte eine Kollision einer Player-Reaktion mit dem nächsten Befehl innerhalb von Fhem sein.
Das Problem ist, dass ich (bzw. der SubProzess) für die Verarbeitung von Benachrichtigungen diverse Informationen bei Fhem nachfragen muss, z.B. ob ein Gerät disabled wurde, oder bei einem Lautstärke-Event, welche Lautstärkegrenzen festgelegt wurden.
Diese Anfrage kann Fhem nicht bedienen, wenn es gerade in einer Befehlssequenz ist (Fhem ist Single-Threaded, was eigentlich auch gut ist). Dadurch entsteht aber u.U. ein Dead-Lock: Der Fhem Prozess arbeitet gerade die Befehlssequenz ab, der SubProzess verarbeitet gerade ein reinkommendes Player-Event und benötigt genau jetzt Informationen, um dieses Event korrekt verarbeiten zu können, und kann den nächsten Befehl nicht in seine Warteschlange legen...

Ich muss mir da noch ein paar tiefergehende Gedanken machen, wie ich dieses Dilemma konzeptionell am sichersten umschiffe...

Zur Lösung von Det: Es würde reichen, die Befehle ca. 1-2 Sekunden zu trennen. Vielleicht mit einem Sleep-Befehl, der von Rudi ja so gebaut wurde, das Fhem währenddessen andere Dinge erledigt... Sobald die Verarbeitung der Playerreaktionen nicht geblock wird, solte das normal durchgehen können...

Grüße
Reiner

[det.]

Hallo  Reiner,
Du hast mit Sicherheit Recht, aber mein ZP90 lässt sich nach Aufruf dieses bestimmten Radiosenders auch bei Aufruf über die Sonos App am IPad gefühlte 10-12s Zeit, bis die ersten Töne kommen. An der Internetverbindung liegt es nicht (entertain VDSL50), eher am Radiostream. Da hat die Abarbeitung der nächsten Befehle 1-2s nach dem Aufruf des Streams keine Chance gehabt. Daher diese umständliche Lösung - die Zeiten hab ich durch Probieren schon optimiert. Die ersten 45s braucht SONOS nach Strom einschalten um zu booten. Toll finde ich den Konstrukt auch nicht, aber seither kann ich den SONOS zuverlässig dank Deinem genialen Modul über mein FritzFon einschalten, ohne gleich das IPad in die Hand zu nehmen.

[gki]

Hallo JoeAllb,

Radiosender & Lautstärke in einem Befehl (EA_Sonos_P1 ist ein Aktor):

define nSonos_Radio_P1 notify EA_Sonos_P1:on { \
    fhem "define tempSonosRadioP1 at +00:00:45 set Sonos_HR PlayURI http://stream.104.6rtl.com/rtl-live/mp3-128 12" \
}

Gleicher Effekt wie das Beispiel von det.

Gruß,
Ines

[JoeALLb]

@Reiner und Det:

Zitat aus einem Forumseintrag von Rudi:
Demnach sollte hier Sleep nicht verwendet werden, solange die Befehle mit "fhem(...) angegeben sind...

Code Auswählen Erweitern

Ja, perl sleep() ist zu vermeiden. Ausnahme ist das fhem eigene sleep
(blockiert fhem NICHT), ist aber auch nur fuer "reine" fhem Kommandos sinnvoll,
also nicht aus einem perl Ausdruck heraus. Beispiel (on-for-timer fuer Arme :)
OK
  define notify schalter:on set lamp on;; sleep 2.5;; set lamp off
Nicht OK:
  define notify schalter:on { \
    fhem("set lamp on");;  \
    fhem("sleep 2.5");;  \
    fhem("set lamp off");; \
  }

[JoeALLb]

@GKI:

Danke für diese Idee: Diese schaltet jedoch um einiges schneller das Radio ein, als wenn ich die Befehle auf 2 getrennte aufteile:

Dies ist demnach schneller als

Code Auswählen Erweitern

define tempSonosRadioP1 at +00:00:01 set Sonos_Wohnzimmer PlayURI http://stream.104.6rtl.com/rtl-live/mp3-128 40

Code Auswählen Erweitern

fhem "define SonosStart0 at +00:00:01 set Sonos_Wohnzimmer LoadRadio Radio%%20Paradise";;\
fhem "define SonosStart1 at +00:00:02 set Sonos_Wohnzimmer Volume 15";;\


@Reiner:
Ich habe heute Nacht Sonos nochmal beobachtet und der Fehler ist wieder aufgetreten. Aufgefallen ist er mir heute kurz nachdem sich ein Sonos-Player
über eine schaltbare Steckdose verabschiedet hat.
Das Sonos-System selbst scheint keine Schwierigkeiten damit zu haben, das FHEM-Modul scheint ihn jedoch noch mit dieser Routengeschichte zu suchen.
Stimmt jetzt die Codezeile, nachdem ich das Modul aktualisiert habe?

Code Auswählen Erweitern

Renewal of subscription failed with error: 412 Precondition Failed at FHEM/00_SONOS.pm line 1839 thread 1.

Ich prüfe gerade, ob diese Zeilen wieder verschwinden, nachdem ich den Sonosplayer wieder eingeschaltet habe: --> Seit 3 Minuten habe ich keine Meldung mehr bekommen.

[Reinerlein]

Hi JoeALLb,

diese Meldung hat aber nichts mit deiner unbekannten Route zum Host zu tun.
Die Meldung "Renewal of subscription..." kommt immer dann, wenn der Wiederauffrischungs-Thread die angemeldeten Subscriptions aktualisieren möchte, und der Player aus Sicht des UPnP-Moduls in einem komischen Zustand ist, z.B. nicht mehr erreichbar...
Diese Meldung kann man zunächst mal getrost ignorieren, da ich sie leider nicht unterdrücken kann.
Wenn der IsAlive-Checker festgestellt hat, dass der Player nicht mehr da ist, sollte diese Meldung auf jeden Fall wegbleiben, da der Player dann aus der Renewal-Liste entfernt wurde... (so zumindest die Theorie

Zu meiner Sleep-Anmerkung:
Rudi hat doch geschrieben, dass es für reine Fhem-Anweisungen sinnvoll ist. Du kannst doch immer, wenn du keine Berechnungen für irgendwelche Parameterwerte hast, auch die "Fhem-Schreibweise" für Befehlssequenzen verwenden, und musst nicht eine Verkettung von fhem()-Anweisungen in Perl machen (ich mache das immer nur zur besseren Lesbarkeit)...

Zu der PlayURI-Anweisung: Hier sollte beachtet werden, dass unterschiedliche Dinge gemacht werden, und am Ende etwas anderes rauskommt.
- PlayURI: Es wird direkt die URL an den Player übergeben, ein SetVolume und eine Play-Anweisung durchgeführt. Das bedeutet also 3 Anweisungen. Allerdings werden hier keine Stream-Informationen wie Cover oder so dargestellt.
- LoadRadio+SetVolume+Play: es wird zunächst die Liste verfügbarer Radiosender abgefragt, danach die entsprechenden Informationen an den Player übergeben (also zwei Anweisungen). Dann wird ja Volume (2 Anweisungen, da der gesetzte Wert am Ende wieder abgefragt wird) und anschließend Play aufgerufen (eine Anweisung). Das sind in Summe 5 Anweisungen, allerdings wird der Radiosender "Sonos-konform" gesetzt, sodass alle Informationen sauber angezeigt werden und der Bezug zum Radiofavoriten noch existiert...

Was man noch probieren könnte, wäre, den Radiosender in die Sonos-Favoriten zu packen (nicht die Radiofavoriten), und mit StartFavourite den Favoriten anzustarten. Der macht zwar im Prinzip das gleiche wie LoadRadio, ausser dass er die Play-Anweisung nicht in einem zweiten Fhem-Befehl stehen hat, aber genau das könnte ja schon helfen...

Mit fällt gerade auf, wieviele Wege hier nach Rom führen

Grüße
Reiner

[JoeALLb]

Hallo Reiner,

danke für die Antworten...

diese Meldung hat aber nichts mit deiner unbekannten Route zum Host zu tun.

Sorry, da hab ich zuschnell hingeschaut. Dennoch bekomme ich diese Meldung regelmäßig, obwohl alle Player aktiv sind und per Kabel verbunden sind. Kein WLAN.
Aber ich kann sie gerne ignorieren

Zu meiner Sleep-Anmerkung:
...eine Verkettung von fhem()-Anweisungen in Perl machen (ich mache das immer nur zur besseren Lesbarkeit)...

Ich wollte nur darauf hinweisen, da eben andere auch diese Schreibweise bevorzugen, jedoch hier eben lt. Rudi die Sleep-Anweisung nicht funktioniert.


StartFavourite Scheint bei mir leider nicht zu funktionieren. Er nimmt den Befehl zwar an, es rührt sich jedoch nichts....
set Sonos_Wohnzimmer StartFavourite "BAYERN 3"
Mache ich da was falsch?

[herman]

Hi Zusammen,

im Prinzip gibt es diese Warteschlange natürlich schon.
Jeder Befehl, den man von Fhem an den SubProzess übergibt, wird dort erstmal in eine Warteschlange gelegt, die der Reihe nach verarbeitet wird.
Der Spezialfall (Stop|Pause)All wird halt als ein Befehl an den SubProzess übergeben, und sendet dort (wie immer) die Befehle an jeden Player einzeln.
Ein Zusammenfassen von Befehlen gibt es in UPnP nicht. Jede Anweisung ist ein einzelnes XML-Strukturiertes Paket von Informationen (ein sogenanntes SOAP-Paket), welches auch mit einem solchen beantwortet wird.

Das Hauptproblem an dieser Stelle dürfte eine Kollision einer Player-Reaktion mit dem nächsten Befehl innerhalb von Fhem sein.
Das Problem ist, dass ich (bzw. der SubProzess) für die Verarbeitung von Benachrichtigungen diverse Informationen bei Fhem nachfragen muss, z.B. ob ein Gerät disabled wurde, oder bei einem Lautstärke-Event, welche Lautstärkegrenzen festgelegt wurden.
Diese Anfrage kann Fhem nicht bedienen, wenn es gerade in einer Befehlssequenz ist (Fhem ist Single-Threaded, was eigentlich auch gut ist). Dadurch entsteht aber u.U. ein Dead-Lock: Der Fhem Prozess arbeitet gerade die Befehlssequenz ab, der SubProzess verarbeitet gerade ein reinkommendes Player-Event und benötigt genau jetzt Informationen, um dieses Event korrekt verarbeiten zu können, und kann den nächsten Befehl nicht in seine Warteschlange legen...

Ich muss mir da noch ein paar tiefergehende Gedanken machen, wie ich dieses Dilemma konzeptionell am sichersten umschiffe...

Zur Lösung von Det: Es würde reichen, die Befehle ca. 1-2 Sekunden zu trennen. Vielleicht mit einem Sleep-Befehl, der von Rudi ja so gebaut wurde, das Fhem währenddessen andere Dinge erledigt... Sobald die Verarbeitung der Playerreaktionen nicht geblock wird, solte das normal durchgehen können...

Grüße
Reiner

Diese Deadlocksituation tritt bei mir ab und zu auf. Ich beende dann den FHEM und den Subthread mit dem "kill" Befehl und starte FHEM neu.
Ich habe in FHEM ein paar Funktionen geschriebenen, die sicherstellen, dass FHEM keine Sonosbefehle absetzt solange das System nicht "hochgefahren" ist. Das bedeutet in meinem Setup, dass 3 Minuten nach dem Einschalten einer Funksteckdose, an dem eine Sonos-Komponente hängt, vergangen sein muss. Seitdem habe ich relativ wenig Probleme mit Deadlocks/Abstürzen aber sie treten dennoch sporadisch auf.

Grüße,
Merhan

[Reinerlein]

Hi JoeALLb,

der Befehl muss ohne Anführungszeichen geschrieben werden:

Code Auswählen Erweitern


set Sonos_Wohnzimmer StartFavourite BAYERN%203

Beachte bitte, dass in einem Notify das Prozent maskiert werden muss (also %%).

Grüße
Reiner

[JoeALLb]

Hallo Reiner,

sorry, Anfängerfehler. Hatte es wieder mit den 2x% versucht....