Sonos steuern

[mullischlumpf]

Ja mist du hast recht. Hier die Ausgabe:

/usr/local/perl/bin/perl -V | grep useithreads
    useithreads=undef, usemultiplicity=undef


------------

/usr/local/perl/bin/perl -V
Summary of my perl5 (revision 5 version 16 subversion 0) configuration:
   
  Platform:
    osname=linux, osvers=2.6.32.12, archname=armv5tel-linux
    uname='linux diskstation 2.6.32.12 #2233 wed jun 6 04:25:24 cst 2012 armv5tel gnulinux '
    config_args='-des -Dcc=gcc -Dprefix=/usr/local/perl -Dcf_by=Martin Fischer -


Die von Martin Fischer ist wohl auch ohne thread support kompiliert :-(

Hm besteht da noch eine Chance für mich auf eine Perl Version die das unterstützt für meine NAS (DS212J)?

[bapou]

Hallo,

ich bin nicht sicher ob es mit dem SONOS Modul zusammen haengt, aber es ungefaehr seit der
SONOS Installation (und gleichzeitigem Umstieg auf raspberry pi) habe ich folgendes Problem.

Wenn ich rereadcfg ausfuehre, oder fhem.cfg im Webinterface editiere und dann Save fhem.cfg klicke,
stuerzt fhem ab.
Der Grund dafuer; er will Ports oeffnen die schon offen sind. In der log Datei ist dies ersichtlich:

telnetPort: Can't open server port at 7072: Address already in use. Exiting.

Habt Ihr das gleiche Problem? Ich will gerne nur ausschliessen, dass es an dem SONOS Modul haengt.

Herzlicher Gruss,
Thom

[Reinerlein]

Hi Thom,

sorry für die späte Rückmeldung, bin gerade etwas im Stress...

Also, ich habe das gerade mal geprüft. Ich habe das Phänomen auch; wenn ich Sonos wieder rausnehme läuft es normal.
Es liegt also (mindestens) an dem Modul.

Ich muss mir das nochmal anschauen, ob ich eine Möglichkeit habe, das irgendwie zu verhindern. Bis vor kurzem ging das, meiner Meinung nach, nämlich noch. Es kann also auch ein Seiteneffekt im Zusammenhang mit einem anderen Modul sein. Threads sind in dieser Hinsicht in Perl leider nicht gut umgesetzt.

Ich weiss, das hilft jetzt nicht wirklich weiter.
Bei mir habe ich diese "rereadcfg"-Problematik allgemein umgangen, indem ich in der Hauptdatei nur noch include-Anweisungen stehen habe, die ich sehr selten ändern muss. Wenn ich diese dann mal ändern muss, dann tue ich das auf der Konsole der Maschine, und Restarte Fhem dann (ich habe einen Menüpunkt dazu auf der Fhem-Oberfläche angelegt).
Eine Änderung in einer der includierten Dateien ist dann auch über das Webinterface Problemfrei, da kein automatischer Rereadcfg ausgeführt wird.

Grüße Reiner

[bapou]

Hallo Reiner,

danke fuer die schnelle Rückmeldung. Ich kann mit dem Problem leben.  
Wo hängt es bezüglich der Idee die Weckzeit auszulesen? An deiner Zeit oder an einem speziellen technischen Problem?
Aber auch hier; mache Dir keinen Stress, es ist toll, dass Sonos schon so gut funktioniert.

Gruss,
Thom

[mullischlumpf]

Ich habe es leider bislang über FHEM noch nicht geschafft mit meiner Synology NAS den Sonos direkt zu steuern.

Da ich mir aber selbst eine kleine Website zum Steuern meiner Geräte gebaut habe, bin ich auf eine Möglichkeit gestoßen, wie man seine Sonos-Lautsprecher entweder über ein Webinterface oder aber über die Commandline steuern kann.
Ich wollte euch hier mal das Projekt zeigen, das unter anderem ein Beispiel für ein Webinterface und eine Commandline Steuerung programmiert hat.

https://github.com/rahims/SoCo

Das Webinterface will bei mir leider auch nicht laufen aber ich habe jetzt zumindest die Commandline Steuerung zum Laufen bekommen. Dadurch kann ich nun per Skript  meine Sonosgeräte ansprechen und die entsprechenden Kommandos ausführen (play, pause, next ...). Das Skript wiederum rufe ich durch Klicks auf meiner Website auf.   Etwas umständlicher aber es funktioniert :-)

Gruß

[Reinerlein]

Hi,

der Nachteil dieser Lösung liegt ja darin, dass keine Events bei Änderungen am Player erzeugt werden (Titelaktualisierungen usw...).

Das Steuern über die bekannte IP des Players geht auch viel direkter.
Man kann sich selber ein SOAP-Paket zusammenschrauben, und an die bekannte(!) IP versenden. Dann macht der Player das auch.
Das Problem ist immer der Discovery-Prozess und das Reagieren auf UPnP-Events. Dafür muss man sich verrenken und diverse Libraries und Threads verwenden...

Sehr schön ist dieses Thread-Notify-freie steuern im PHPSonos-Skript zu erkennen.
Ich habe dazu mal auch eine Erweiterung entwickelt, die auch auf Events reagieren kann: http://www.ip-symcon.de/forum/threads/7676-PHP-Sonos-(Klasse-zum-Ansteuern-einzelner-Player)/page23
Dazu muss allerdings PHP lauffähig sein, und die PHP-Erweiterung GUPNP installiert sein. Aber vielleicht ist das für manche ausreichend, bzw. wegen vorhandener PHP-Server besser als die FHEM-Variante...

Wenn man mal sehen möchte, welche Informationen der Player so bereitstellt, kann man über die Web-Oberfläche des Players gehen.
Dazu z.B.: http://192.168.0.36:1400/status aufrufen (IP natürlich anpassen).
Damit kann man aber nix steuern, das ist nur für Informationen da.

Also, u.U. ist das eine Möglichkeit für die Personen, bei denen Perl nicht mit Threads läuft.
Ich hatte meine PHP-Version ursprünglich zum Steuern meines Verstärkers durch Fhem verwendet. Da hatte sich das PHP-Skript dann mit Fhem verbunden, und einen Trigger ausgelöst, wenn der Player auf PLAYING oder PAUSED_PLAYBACK oder STOPPED gegangen ist.

Wegen der fehlenden Titelinfos ihm Fhem und allgemeiner Unbequemlichkeit hatte ich ja damals das Sonos-Modul für Fhem begonnen :-)

Grüße Reiner

[Reinerlein]

Hi Thom,

soo, ich bin schon ziemlich weit, und muss Hauptsächlich noch dokumentieren.

Was nun drin ist:
- Man kann einen Alarm-Listener anmelden, der für eine automatische Aktualisierung der Alarm- und DailyIndexRefreshTime-Readings sorgt.
- Man kann Alarme anlegen, verändern und löschen
- Man kann den Sleeptimer mit einer beliebigen Zeit starten und natürlich auch wieder deaktivieren

Durch die Menge der Informationen, die zum Anlegen eines Alarms notwendig sind, ist das im Normalfall ein nicht zu empfehlender Weg, wenngleich er natürlich möglich ist.
Viel besser ist es, einen Alarm im Controller anzulegen, und diesen immer wieder nur anzupassen (neuer Tag, einfach wieder aktivieren o.ä.), da dafür nur die zu ändernden Informationen angegeben werden müssen...

Kannst du mir bitte noch mal kurz deinen Use-Case schreiben, also was du am liebsten mit Fhem und Sonos da machen möchtest?
Dann kann ich das hier mal gegenprüfen, und u.U. die Beispiele dahingehend aufbauen...

Grüße Reiner

[snoop]

Hallo Reiner,
gibt es eine Möglichkeit zwei Player per Kommando zu gruppieren?
Ich habe bisher nichts dazu gelesen.
Danke.
Viele Grüße
Arthur

[Reinerlein]

Hi Arthur,

das kannst du auch nicht :-) Es geht einfach noch nicht...

Der Grund liegt einfach daran, dass ich bislang nur einen Player habe, und deswegen das Verhalten von mehreren Playern aus Sicht der Programmierung nicht beurteilen kann...
Dieser Zustand wird aber nun sicher im Laufe des nächsten Monats geändert. Die Budget-/Notwendigkeitsverhandlungen mit meiner Frau sind durch :-)

Wenn du dich in diesem Punkt also noch etwas gedulden kannst... es kommt auf jeden Fall...

Grüße Reiner

[snoop]

Hallo Reiner,

klar, kein Problem.
Danke und bis demnächst.

Viele Grüße
Arthur

[bapou]

Hallo Reiner,

entschuldige die spaete Rueckmeldung.

Der Anwendungsfall ist einfach. Ich lasse mich wecken durch SONOS im Schlafzimmer; Nur ein Wecker
an einem Sonos Geraet. Eingestellt wird der Wecker ueber das Iphone SONOS Interface abends.

Nun soll FHEM die Weckzeit auslesen; entweder automatisch wenn diese veraendert wurde, oder falls technisch
zu kompliziert,  zu einer festen Zeit; z.B. 4 Uhr am Morgen.
Damit kann FHEM vor der SONOS Weckzeit entsprechend die Heizung, Kaffemaschine etc. anschalten.

Eventuell, falls das ganze zuverlaessig ist, soll FHEM auch nachts die SONOS Geraete ausschalten und am Morgen
rechtzeitig einschalten um Energie zu sparen. Nur hier bin ich noch nicht sicher ob ich mich auf FHEM + FS20 Schalter verlassen soll, auch wenn man natuerlich das FS20 Kommando ein paar Mal senden koennte.

D.h. nur die Weckzeit von einem Wecker (z.B. dem ersten) auslesen reicht fuer meine Anwendung

Herzlichen Dank,
Thom

[Reinerlein]

Hi Thom,

ok, das klingt einfach. Meine Implementierung erzeugt bei jeder Änderung eines Alarms für einen Player an diesem ein Event.
Das bedeutet, du kannst einfach mit einem Notify darauf reagieren.

Das Problem ist, das der Code für dein Notify etwas komplizierter werden dürfte. Ich musste ja schließlich auf die Begebenheiten von Sonos Rücksicht nehmen :-)
Soll heißen, dass du immer denselben Alarm verwenden solltest, denn du da einstellst. Dann bleibt die interne ID gleich, und du kannst schon mal in deinem Notify direkt auf den passenden Alarm zugreifen.

In Fhem sind die Alarme als Hashes von Hashes im Reading (also in einem Hash:-) abgelegt, also z.b. mit:

Code Auswählen Erweitern

SONOS_Stringify(ReadingsVal("Sonos_Wohnzimmer", "AlarmList", 0))
Kannst du dir folgenden Hash ermitteln:

Code Auswählen Erweitern

{27 => {Recurrence_Thursday => 1, IncludeLinkedZones => 0, Volume => 35, Shuffle => 0, Recurrence_Wednesday => 1, ProgramURI => x-rincon-buzzer:0, Repeat => 0, Recurrence_Once => 0, StartTime => 00:00:00, Duration => 00:15:00, Recurrence_Sunday => 0, Enabled => 0, Recurrence_Friday => 1, Recurrence_Saturday => 0, Recurrence_Tuesday => 1, RoomUUID => RINCON_000E5828D0F401400, ProgramMetaData => , Recurrence_Monday => 0}, 3 => {Recurrence_Thursday => 0, IncludeLinkedZones => 0, Volume => 25, Shuffle => 1, Recurrence_Wednesday => 0, ProgramURI => x-sonosapi-stream:s78371?sid=254&flags=32, Repeat => 0, Recurrence_Once => 1, StartTime => 14:58:00, Duration => 00:15:00, Recurrence_Sunday => 0, Enabled => 0, Recurrence_Friday => 0, Recurrence_Saturday => 0, Recurrence_Tuesday => 0, RoomUUID => RINCON_000E5828D0F401400, 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/11" parentID="R:0/0" restricted="true"><dc:title>RADIO fresh80s</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}}Dabei ist SONOS_Stringify nur eine Hilfsmethode, um den Inhalt von Hashes auszugeben. Das benötigst du dann natürlich nicht in deinem Notify...

Wenn du da mal reinschaust, siehst du, dass die Hauptschlüssel die IDs der Alarme sind. Diese kannst du auch als Vereinfachung aus dem Reading

Code Auswählen Erweitern

ReadingsVal("Sonos_Wohnzimmer", "AlarmListIDs", 0) auslesen:

Code Auswählen Erweitern

3,27
Das sieht jetzt erstmal wüst aus, ist aber relativ simpel gestrickt. Es sind halt alle Informationen vorhanden...

Ich teste den Code noch ein bißchen bei mir in der Produktivumgebung, und veröffentliche ihn dann. Die Doku im Wiki ist schon mal angepasst...

Zu deiner Konstellation: Ich persönlich würde mich *nicht* auf FS20 verlassen. Da geht mir einfach zu viel verloren... Aber das solltest du mal Testen...

Grüße Reiner

[Reinerlein]

Hallo zusammen,

sooo, das ganze ist bei mir auf dem Produktiv-System eine Weile ohne besondere Vorkommnisse gelaufen, sodass ich den Code hier nun veröffentliche.

Was ist drin:

• Neues Attribut "getAlarms", welches Alarminformationen beim Player erfragt, und einen Listener für Aktualisierungen anmeldet.
• Dadurch neue Readings: "AlarmList", "AlarmListIDs" und "AlarmListVersion"
  
  • AlarmList ist ein Hash aller Alarme, die für den Player eingetragen sind. Das unterscheidet sich zur Darstellung im Original-Controller, dort werden alle Alarme unabhängig der Zone dargestellt.
  • AlarmListIDs sind die Keys für die erste Ebene des Alarm-Hashes, um einfacher daran zu kommen
  • AlarmListVersion ist zur internene Verwaltung der Aktualität der Alarminformationen
• Wenn Alarme verändert werden, wird ein Event generiert. Dieses Event bezieht sich aber auf die komplette Alarmliste. Es wird also nicht für einen speziellen Alarm ein Event erzeugt, sondern ein globales.
• SleepTimer wird automatisch aktualisiert und erzeugt ein Event beim Setzen und Ablaufen (und kann natürlich auch von Fhem aus gesetzt werden)
• DailyIndexRefreshTime wird nun automatisch ermittelt und kann gesetzt werden
• Neue Im-/Exportmöglichkeit: LoadPlaylist und SavePlayList können nun auch Dateien verarbeiten/erzeugen, die im M3U-Format abgelegt wurden/werden
• Diverse Sonderfälle, die den meisten nicht aufgefallen sein dürften, wurden berücksichtigt und andere kleinere Fehler wurden behoben

Die Dokumentation im Wiki ist angepasst und liefert auch Hinweise auf das Format des Alarm-Hashs.

Wie immer komplett, obwohl sich nur die beiden Fhem-Moduldateien geändert haben...
Viel Spaß mit den neuen Möglichkeiten, als nächstes werden wohl die Zonengruppierungen drankommen :-)

Grüße Reiner

[snoop]

Hallo Reiner,

beim Einspielen der neuen Version mit anschließendem Reload erscheint folgende Meldung:

Not enough arguments for main::SONOS_getDeviceDefHash at ./FHEM/00_SONOS.pm line 1024, near "()"
Not enough arguments for main::SONOS_getDeviceDefHash at ./FHEM/00_SONOS.pm line 1030, near "()"
Not enough arguments for main::SONOS_getDeviceDefHash at ./FHEM/00_SONOS.pm line 1031, near "()"
BEGIN not safe after errors--compilation aborted at ./FHEM/00_SONOS.pm line 1048.

Eine Idee was schief läuft?
Benötigst du Logs?

Viele Grüße
Arthur

[det.]

Hallo Reiner,
bin auch wieder auf die Version vorher zurück - FHEM lief zwar noch, aber der Zugriff auf web war nicht mehr da und das ging nur mit Neustart RPI zu beheben.