FHEM Forum

Hallo Sonos-Freunde,

es ist vollbracht!
Ich habe gerade das Modul im SVN eingecheckt. Es sollte also ab Morgen im Update drin sein ;D

Des Weiteren habe ich das Wiki entsprechend angepasst, und bei den Readings, bzw. Set- und Get-Befehlen eine Strukturierung vorgenommen, damit man vielleicht etwas leichter den passenden Befehl finden kann.
Das sind ja mittlerweile einige, und das macht es nicht gerade übersichtlicher...

Außerdem gibt es dann natürlich auch die Commandref auf Deutsch und Englisch, wobei dort nur alle Befehle mit Parametern beschrieben sind. Für nähere Hinweise und Tipps und Tricks bleibt weiterhin das Wiki die erste Wahl...

Grüße
Reinerlein

@Reinerlein, Dank und gratulation :-) Tolles Modul und seit den letzten Updates hab ich auch keine Abstürze mehr.

Echt Klasse, ich freue mich sehr darauf damit die Feiertage zu verbringen  ;D

Hallo nochmal,

da habe ich vor lauter Schreck doch die Changelist für 2.6 vergessen :)

• Die Zeichenkodierung bei Datenübernahme vom Zoneplayer kann nun über das Attribut characterDecoding eingestellt werden
  
• Bei Gruppen-/LineIn-/SPDIF-Wiedergabe wird wieder die liefernde Zone angezeigt (als Albumname)
  
• SetCurrentPlaylist hatte einen Tippfehler, und konnte dementsprechend nicht ausgeführt werden
  
• Unter Ubuntu gibt es die SHA1-Library nicht mehr, sodass man dort eine andere einbinden muss (SHA)
  
• Wenn bei den Methoden zum heraussuchen der FHEM-Devices etwas nicht gefunden wurde, dann wird jetzt eine Fehlermeldung mit dem gesuchten Merkmal ausgegeben
  
• Es können jetzt IP-Adressen von der UPnP-Verarbeitung ausgeschlossen werden
  
• Es wird nun ein fester Mimetype 'jpg' für Google Music und Simfy festgelegt
  
• Beim Alarm-Reading-Setzen wurde etwas doppelt gesetzt, was u.U. zu Fehlern führen konnte
  
• Die Read-Function wurde robuster gegen Übertragungsprobleme gemacht
  
• Das Wiederherstellen des Playerzustands nach einem PlayURITemp sieht nun auch den PlayBar-Eingang vor
  
• Es wird nun anstatt der WebCmd-Auflistung ein RemoteControl beim Erstellen der Komponenten erzeugt
  
• Wenn sich doch noch ein UPnP-Device als Player ausgibt, dann wird dies nun etwas sicherer erkannt
  
• Der Eingang einer Playbar kann nun auf anderen Playern wiedergegeben werden (mittels des Fhem-Namens)
  
• Lesen wurde auf DevIo_SimpleRead umgestellt (stand auf DevIo_DoSimpleRead). Dadurch wird das Fehlerhandling vereinfacht.
  
• Man kann die Zeit für das Warten auf den Subprozess nun beim Define mit angeben. Standardmäßig wird 8 verwendet.
  
• Es wird nun in regelmäßigen Abständen (Intervall wie bei der Prüfung der Sonosplayer) geprüft, ob die Verbindung zum Subprozess noch funktioniert
  
• Die Readings, die beim Start nicht geladen werden dürfen, werden beim Start von Fhem nun initialisiert. Damit wird die Fehlermeldung in MOTD verhindert
  
• Der Zeitstempel in der Konsolenausgabe berücksichtigt nun auch die Global-Angabe, ob Millisekunden mit ausgegeben werden sollen
  
• Der Start wurde komplett überarbeitet. Nun sind die einzelnen Wartebereiche in Timer ausgelagert, sodass Fhem nicht mit warten blockiert wird.
  
• Die Wiederherstellung des alten Playerzustands nach einem PlayURITemp (und damit auch bei Speak) wird nun auch bei Dateien gemacht, die mit 0s Dauer ermittelt werden (da sie sehr kurz sind).
  
• Der Aufruf der Google Text2Speech-Engine wird nun bei mehr als 95 Zeichen in mehrere Aufrufe aufgeteilt. Damit sind nun auch lange Texte über Google möglich, allerdings geht die Textmelodie u.U. verloren.
  
• Man kann jetzt für die Speak-Erzeugung ein JPG- oder PNG-Bild angeben. Dies kann für jedes Speak-Programm getrennt erfolgen.
  
• Beim Speak-Aufruf werden Umlaute nun auch korrekt an den Text2Speech-Generator (z.B. Google) übergeben, und korrekt in den MP3-Tag geschrieben
  
• Spotify-Cover werden nun in größerer Auflösung (meist 640x640 Pixel) direkt von Spotify heruntergeladen, und enthalten dann nicht mehr das Spotify-Logo
  
• Es gibt zwei neue Readings 'currentAlbumArtURL' und 'nextAlbumArtURL', die die Originalpfade zum eigenen Download darstellen
  
• Es gibt nun zwei Prozeduren, die als Grundlage oder Beispiel für die Verwendung von ReadingsGroups dienen können: 'SONOS_getTitleRG' und 'SONOS_getCoverRG'
  
• Beim automatischen Erzeugen der Sonos-Devices werden nun ReadingsGroups mit mehr Informationen erzeugt. Dies kann (und soll) auch als Vorlage für eigene Ideen Verwendet werden
  
• Es gibt eine weitere ReadingsGroup-Vorlage (steht auch im Wiki), mit der Listen (Playlisten, Favoriten und Radios) dargestellt werden können
  
• Es gibt zwei neue Attribute "proxyCacheTime" und "proxyCacheDir", die einen Cache im Proxy aktivieren
  
• Es gibt drei neue Getter am Sonosplayer-Device: "FavouritesWithCover", "PlaylistsWithCover" und "RadiosWithCovers". Diese geben eine Datenstruktur zurück, die den Titel und das Cover des Elements enthält.
  
• Die Prozeduren für die Anzeige des aktuellen und nächsten Titels verwenden nun ausschließlich DIV-Container (anstatt Tabellen). Dadurch klappt die Anzeige auch in einem Dashboard.
  
• Die Standard-ReadingsGroup-Anzeige durch die Prozeduren sind nun Parametrisiert. Man kann die minimale Breite der Anzeige sowie den Abstand zwischen aktuellem und nächstem Titel in Pixel festlegen
  
• Manche Sender (z.B. Capital Radio Türkiye) haben verbotene Newlines in den Titelinformationen mitgesendet. Diese werden nun entfernt.
  
• Man kann das Cover nun anklicken (oder antippen), und erhält dann die Coverdarstellung in einer Vollbilddarstellung mit Abspielstatus und Titelinformationen
  
• Es gibt zwei neue Befehle 'StartPlaylist' und 'StartRadio', die die gleichen Parameter wie ihre Pendants mit 'Load' am Anfang haben, nur dass hier das Abspielen gleich gestartet wird.
  
• Es gibt jetzt ein Reading 'currentTrackPosition', welches bei jedem Transportstate-Wechsel (neuer Titel, Play/Pause/Stop usw.) gesetzt wird. Damit kann man die verbleibende Restzeit eines laufenden Titels ermitteln, bzw. den Pausezeitpunkt anzeigen.
  
• Beim Wiedergeben von TV oder sonstigen externen Quellen, wird jetzt nicht mehr das 'leere' Cover angezeigt, sondern ein TV-Cover bzw. ein Default-Input-Cover

Ist ja auch eine erkleckliche Liste geworden...

Grüße
Reinerlein

Hi Reinerlein,

super!, hat es ja doch noch vor Weihnachten geklappt ;D 8)

Ich bin gespannt wie die Statistik für das Modul ausfällt!

Gruß Claudiu

sehr schön, gratuliere!

Tolle Arbeit - vielen Dank!:D

Hi Reinerlein,


ich bin nicht sicher, ob der Checkin im SVN jetzt so erfolgreich war. Im Update Protokoll sehe ich nur die beiden Module, aber die ganzen zusätzlichen Libs nicht. Hattest du dich diesbezüglich nochmals mit Rudi und Co abgestimmt? Es kann sein, dass dafür ein paar Sonderlocken notwendig sind und/oder etwas umgestellt werden muss an deinen Modulen, damit es mit der Daten und Update-Struktur, wie sie Rudi vorgesehen hat, funktioniert.


Edit: Ich beziehe mich insbesondere auf den Ordner "./lib".

Hi Loredo,

ich habe auch das Update heute Morgen gemacht und die Dateien im lib-Ordner nicht bekommen, habe das aber darauf zurückgeführt, dass ich die Dateien im lib-Ordner ja schon genau in derselben Version vorliegen habe.
Die beiden pm-Dateien wurden ja durch Subversion verändert (der ID-Eintrag), die anderen aber nicht...

Ich bin noch nicht dazu gekommen, dass auf einem jungfräulichen System zu testen. Das schaffe ich erst heute Abend...

Grüße
Reinerlein

zusätzliche directories (und deren inhalt) werden im update nicht automatisch verteilt sondern müssen mit rudi abgestimmt werden weil er hier von hand eingreifen muss.

gruß
  andre

Hi reinerlein,

dein modul ist super !
echt tolle Arbeit !!!

Vielen Dank dafür
und auch für den super schnellen Support hier im Forum  :)


mfg. m311331

Hallo zusammen,

nur kurz zur Bestätigung: Die notwendigen Ordner in "FHEM/lib" werden wirklich nicht per Update ausgeliefert. Das bedeutet, dass das Modul so für eine frische Installation nicht lauffähig sein wird.

Für diese Fälle muss man weiterhin das Modul aus dem Dev-Bereich herunterladen:

update all http://fhem.lmsoft.de/sonos_dev/controls_sonos.txt


Rudi möchte diese Ordner nicht drin haben, da man sie wohl (zumindest eins) per CPAN erhalten könnte.
Da ich das noch nie selber verwendet habe (unter Windows verwende ich den ActivePerl Paketmanager, unter Debian verwende ich apt-Pakete), und auch keine Zerstückelung des Moduls möchte, wird es vielleicht auf einen Rückbau auf die Thirdparty-Installations-Möglichkeit hinauslaufen...

Aber mal schauen, was noch so passiert. Vielleicht kann man ja auch den Installationsmechanismus umbauen...

Grüße
Reinerlein

Hallo Reinerlein,

erst mal vielen Dank für Dein tolles Modul!

Dass man per cpan/apt-get Perl-Pakete nachinstallieren muss, haben wir doch bei diversen anderen Modulen auch. Wenn Du in der commandref danach suchst, wirst Du diverse Treffer haben. Darum halte ich es aus meiner User-Sicht für unproblematisch, wenn Du in der commandref auf diese Voraussetzung hinweist. Ziel: Ich hätte SONOS gerne im normalen Update, statt als Thirdparty-Install. Wenn es "nur" um die Update-Verteilung von Eigenentwicklungen geht, hat Rudi vielleicht auch keine Probleme, das ins update aufzunehmen.

Gruß, Christian

ich stimme krikan da zu.

Zumal man auch möchte, dass Perl Pakete automatisch aktualisiert werden. Du solltest nicht der Lieferant dafür sein, wenn sie einfach in zB Debian enthalten sind. Müssten deine Module nur noch so geschrieben sein, dass sie nicht in FHEM/lib suchen :-)

Hallo,

wir reden hier von der UPnP-Lib, die ich angepasst habe, und die sowieso nicht per CPAN zu bekommen ist (scheint für Rudi auch kein Problem zu sein), und von einer MP3-Lib, bei dir ich mich noch vage daran erinnern kann, dass viele Versionen davon fehlerhaft waren (und ich noch nichtmal weiß, ob sie per CPAN o.ä. erhältich sind).
Ich möchte dabei sicherstellen, dass *genau* diese Dateien verwendet werden. Damit läuft alles. Wer weiß, wie es mit anderen Versionen aussieht...

Die anderen notwendigen Libs müssen ja sowieso installiert sein (Netzwerk u.ä.). Da ist die Version nicht so wichtig und ist dementsprechend auch nicht mit in der Lieferung...

Mir geht es um die Lauffähigkeit out-of-the-box für diese libs und darum, dass wir bei Fehlern nicht noch klären müssen, ob die richtigen libs installiert sind. Also eigentlich nichts dramatisches.

Grüße
Reinerlein

Hallo Reinerlein,

warum nicht einfach in die Commandref/Wiki einen Hinweis wie:

- Klickste hier www.meinserver.de/dowload.zip und entpackste enthaltene Dateien in ..FHEM/lib 
- Oder nur die Libs über den Thirdparty Update-Mechanismus verteilen?

fertig?

Und den rest einfach so lassen wie es gerade ist, also der fhem Update die sonosplayer.pm und sonos.pm verteilen?

Ich denke die libs wirst du warscheinlich sowieso "nie" anfassen, bzw. etwas daran aktualisieren solang alles funktioniert?

Gruß Claudiu

Hallo zusammen,

Rudi und ich haben einen Weg gefunden...
Es hat sich herausgestellt, dass von der MP3-Lib nicht alles benötigt wird, und Rudi hauptsächlich ein Problem mit den enthaltenen Binärdateien hatte.

Ich habe nun korrekterweise die überflüssigen beiden Ordner entfernt, die beiden notwendigen Ordner hat Rudi nun im Update eingetragen.
Wenn mein Test jetzt kein Blödsinn war, sollte so alles aus dem normalen Update heraus funktionieren.

Grüße
Reinerlein

Hi Reinerlein,


ich kann bestätigen, funzt jetzt auf einem jungfräulichen System  :D
Weiß nicht, ob das jetzt "neu" ist, aber bei mir werden jetzt auf allen Consolen (egal ob Remote/SSH oder direkt am Gerät) die Events des UPnP Daemons ausgegeben. Das nervt leider ziemlich, kann man das nicht per Default ausschalten und nur bei Bedarf aktivieren (optimaler Weise mit Logging in eine Datei)?


Ansonsten dauert es bei mir immer einige Minuten nach dem Start, bis dann das Sonos-Player Gerät erkannt wird. Auch habe ich FHEM schon einmal zum Absturz gebracht. Letzteres werde ich aber erstmal noch beobachten, ich kann jetzt nicht genau erinnern, was ich in dem Moment gemacht habe. Kann mich nur an eine hohe CPU Last des UPnP Daemons erinnern.




Gruß
Julian

Hallo Reinerlein,

hört sich sehr interessant an. Ist das ein generelles UPNP Modul das ich auch für andere UPNP Geräte nutzen kann?
Wäre es möglich das Fehlen eines Moduls abzufangen (eval "use Net::Telnet;1" or $missingModul .= "Net::Telnet ";) und als Fehler auszugeben?

Gruß
tupol

Hi tupol,

diese Fehlermeldung kann eigentlich gar nicht kommen. Das Verfahren mit Telnet ist ein altes, welches nur noch drin ist, damit man es einfach wieder aktivieren könnte (was ich eigentlich aber nicht mehr vorhabe).
Der Aufruf dazu ist aber ausmarkiert (ab Zeile 6194) und wird demnach auch nicht aufgerufen...

Kannst du mal ein Log mitschicken, wo diese Fehlermeldung auftaucht?

Das UPnP-Modul ist im Prinzip ein allgemeines (http://perlupnp.sourceforge.net/ (http://perlupnp.sourceforge.net/)), welches von mir aber angepast wurde, da es zumindest in Zusammenarbeit mit Sonos ein paar Mankos hatte.
Ich denke aber, dass es für die meisten Anwendungen passen sollte, sofern diese Anwendungen nicht auch so Divenhaft wie Sonos sind :-)

Danke schon mal...

Grüße
Reinerlein

Hi Julian,

bei mir kommt das nicht ins normale Fhem-Log. Ich habe aber auch die STDOUT und STDERR Ausgabe direkt im Startskript auf eine Datei umgelenkt, damit ich dort immer mittels "tail -f" im laufenden Betrieb gucken kann, was im Subprozess so passiert..

Fhem lenkt beim Start selber den STDOUT und STDERR in das Logfile um (in fhem.pl in der Prozedur "redirectStdinStdErr" in Zeile 1166).
Vielleicht klappt das in meinem Fall wegen der eigenen Umlenkung dann nicht mehr...

Grüße
Reiner

Zitat von: Reinerlein am 20 Dezember 2014, 16:05:58
diese Fehlermeldung kann eigentlich gar nicht kommen. Das Verfahren mit Telnet ist ein altes, welches nur noch drin ist, damit man es einfach wieder aktivieren könnte (was ich eigentlich aber nicht mehr vorhabe).
Der Aufruf dazu ist aber ausmarkiert (ab Zeile 6194) und wird demnach auch nicht aufgerufen...

Das war nur ein Beispiel, wie man das erkennen und dem Nutzer zeigen kann. Leider weiß ich nämlich nicht was, sondern nur das etwas fehlt. :-)

Gibt es eigentlich ein Modul das alle UPnP-Geräte erkennt und auch UPnP-AV kann? Vielleicht könnte man Deins (unter neuem Namen) dazu ausbauen (ich habe z.B. kein Sonos aber eine Soundbridge)

Hi tupol,

hmm... komisch ist das schon, weil Perl ja ziemlich klar sagt, wenn ihm etwas fehlt, und er sagt dann auch genau was er jetzt gerne gefunden hätte, und wo... Ich verstehe die Frage jetzt nicht ganz...

Zu dem allgemeinen UPnP-AV: Das hat schon mal jemand versucht. das ging dort nicht weiter. Vermutlich liegt das an den vielen Unwägbarkeiten, und dem doch sehr geringen "Standard", den man da UPnP nennt. Vieles funktioniert nicht bei allen, und es ist auch eher eine grundlegende Verbindungsdefinition. Man kann die Teilnehmer über Standards finden und ansprechen (auch über den Standard steuern). Gleich Funktionieren tun die deshalb noch lange nicht. Das bezieht sich alles nur auf Protokollvereinheitlichung...

Das Sonos-Modul geht sehr speziell auf die Sonderwünsche des Sonos-Systems ein, du müsstest eher ein neues Modul von "unten" her anfangen... Das Sonos-Modul so in die Richtung "weiter zu entwickeln" wird wohl eher nicht gehen...

Grüße
Reinerlein

Also "klar" sieht anders aus  ;)
BEGIN failed--compilation aborted at ./FHEM/00_SONOS.pm line 296.
Compilation failed in require at ./FHEM/00_SONOS.pm line 296.
BEGIN failed--compilation aborted at FHEM/lib/UPnP/ControlPoint.pm line 14.
Compilation failed in require at FHEM/lib/UPnP/ControlPoint.pm line 14.
BEGIN failed--compilation aborted at FHEM/lib/UPnP/Common.pm line 85.
2014.12.20 13:04:49 0: Can't locate SOAP/Lite.pm in @INC (@INC contains: fhem.p/lib fhem.p/FHEM/lib ./FHEM/lib ./lib ./FHEM ./ /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at FHEM/lib/UPnP/Common.pm line 85.

BEGIN failed--compilation aborted at ./FHEM/00_SONOS.pm line 296.
Compilation failed in require at ./FHEM/00_SONOS.pm line 296.
BEGIN failed--compilation aborted at FHEM/lib/UPnP/ControlPoint.pm line 14.
Compilation failed in require at FHEM/lib/UPnP/ControlPoint.pm line 14.
BEGIN failed--compilation aborted at FHEM/lib/UPnP/Common.pm line 85.
Can't locate SOAP/Lite.pm in @INC (@INC contains: fhem.p/lib fhem.p/FHEM/lib ./FHEM/lib ./lib ./FHEM ./ /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at FHEM/lib/UPnP/Common.pm line 85.
2014.12.20 13:04:49 1: reload: Error:Modul 00_SONOS deactivated:


Hi tupol,

Das ist die Aufrufkette rückwärts...
Die wichtige Zeile steht doch deutlich da:

2014.12.20 13:04:49 0: Can't locate SOAP/Lite.pm in @INC (@INC contains: fhem.p/lib fhem.p/FHEM/lib ./FHEM/lib ./lib ./FHEM ./ /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at FHEM/lib/UPnP/Common.pm line 85.


Wenn du diese Reihenfolge nicht lesbar findest, dann solltest die Logausgabe wieder richtig drehen...

Grüße
Reiner

Hallo Reinerlein,

es geht mir nicht um die Reihenfolge sondern, um die kryptischen Beschreibungen von Perl, die nur Insidern verständlich sind. Das ganze ist für einen newbee auch nicht in korrekter Reihenfolge lesbar. Nachdem Du darauf hingewiesen hast, ist es zwar klar. Es würde Deinen Betreuungsaufwand aber sicherlich reduzieren, wenn die Fehlermeldung "Perl module SOAP::Lite is missing" lauten würde.

Gruß
tupol

Hi tupol,

also, ich baue keine Fehlermeldung für Perl Fehlermeldungen :)

Als Newbee würde man sowas doch erstmal bei Google eintüten, oder?
Dort ist unter den ersten 10 Ergebnissen von "Can't locate SOAP/Lite.pm in @INC" mindestens fünfmal eine saubere und ordentliche Beschreibung, was das Problem ist, und vor allem, was man dagegen tun kann...

Des Weiteren steht in meinen Installationshinweisen (commandref) deutlich, dass dieses Modul benötigt wird (unter anderem), und im Wiki steht passend dazu eine wirklich genaue Installationsanweisung. Da muss man sich nur eine passende raussuchen...

Ich denke, dass sowas schon häufiger hier im Forum angesprochen wurde: Ein bißchen Eigeninitiative muss man mitbringen. Wir helfen hier alle wirklich gerne, und manchmal sieht man das Problem ja auch einfach nicht, aber diese Grundlagen muss man auch als Newbee draufbekommen können...

Grüße
Reinerlein

Hallo zusammen,
ich finde es supertoll, dass das SONOS-Modul nun direkt von fhem unerstützt wird. Ich traue mich aber nicht, es einzubinden. Damals hatte ich es parallel auf meinem produktiven rpi und hatte immer wieder Abstürze. Vor ca. 3 Monaten habe ich den rpi neu aufgesetzt und kein Sonos mehr an Bord. Seit dem habe ich keine Abstürze mehr. Wie sind die Erfahrungen mit dem neuen Modul? Schafft ein rpi diese zusätzliche Last? Habe derzeit quasi kaum Prozessorlast und damals mit Sonos lag ich bei mehr als 20% teilweise bei 70% Auslastung.

Wie sieht das bei Euch aus? Ich habe 11 Sonos Devices im Einsatz
2 x Bridge
2 x Play 1 als Stereopaar
3 x Play 1 als Single-Player
2 x Play 3, Singlebetrieb, teilweise als Stereopaar
1 x ConnectAmp
1 x SUB
Das Problem mit dem Absturz trat sehr häufig auf, wenn man einen Player vom Strom trennte und an anderer Stelle wieder ins Netz nahm, oder wenn man Sterepaare bildetet und wieder auflöste.

BTW:
Schön fände ich es, wenn das Sonos-Modul das Bilden und Trennen von Stereopaaren unterstützen würde. Das nutze ich öfter für die beiden Play 3. Auch das Einbinden eines SUB in eine andere Konfiguration wäre eine tolle Sache. So könnte man verschiedene Konfigurationen mit einem System fahren und per fhem einfach auf Knopfdruck zusammenstellen....

Danke und Gruß,
Christian

Hallo Spartacus,
ich habe mit dem Sonos Modul auch so meine schwierigkeiten gehabt - aktuell bin ich aber ziemlich zufrieden, ich habe auch einen play3 der immer wieder mal schwierigkeiten machte - seitdem ich dieses aber mit einem kleinem workarround in den griff bekommen habe läuft eigentlich alles sehr stabil.

Ich kann nur nichts über Prozesslast sagen - da ich produktiv auf dem Cubietruck bin.

Hallo der-Lolo,
der Cubi soll ja abgehen, wie "Schmits-Katze"... Hatte auch mal vor mir so ne Büchse zuzulegen, aber wieder auf die lange Bank geschoben...

Eigentlich wollte ich dem Sonos-Modul einen eigenen rpi spendieren, aber wenn das jetzt stabil läuft, werde ich es wohl doch wieder auf meinen enocean-pi schrauben...mal gucken...so nen pi kostet ja auch mit Allem ca. 50 Euros. 

Welchen Workaround nutzt Du bei Deinem Play 3 und wie viele Sonos-Devices hast Du per fhem am Start?

Christian

Hallo Spartacus,

ich habe bei mir Sonos auf einem Pi im Produktivbetrieb zusammen mit meinen vier Sonos-Komponenten.
Dort läuft es naturgemäß langsamer als auf "starken" CPUs, aber es läuft bei mir gut...

Das Problem dürfte auch eher sein, wieviel auf deinen Komponenten so los ist. Jede Titeländerung z.B. verursacht eine Menge Aktualisierungen bei den Readings. Das muss alles über den TCP/IP Kanal zwischen SubProzess und Fhem transportiert werden und dann in Fhem ausgeführt werden. Oft hängen viele Events dran, bzw. einfach nur viele Notify-Angemeldete Fhem-Komponenten, die dann für jede Änderung aufgerufen werden...
Das Dauert seine Zeit...

Die Übertragung vom SubProzess zum Fhem-Teil ist zwar kurzgefasst, und Datenmengenmäßig eng gehalten, trotzdem werden dort immer alle ermittelbaren Readingswerte erstmal übertragen. Erst im Fhem-Teil wird geprüft, ob sich ein Readings-Wert überhaupt geändert hat (bzw. ändern soll), und nur für diesen wird dann auch eine Änderung angestossen.

Das musst du also probieren. Abstürze sollten aber deutlich seltener geworden sein (bei mir habe ich mittlerweile keine mehr), da das Modul natürlich mit der Zeit auch ausgereifter geworden ist...
Ich mache ca. alle 1-3Wochen ein Update. In diesem Zeitraum habe ich keine Abstürze mehr. Ob nach längerem Betrieb also Ausfälle auftreten, kann ich nicht sagen, ewarte ich aber auch nicht...

Zu der Paarbildung:
Das erscheint mir eher kompliziert in der Automatisierung, zumal dort auch eine Benutzeraktion notwendig ist, oder? "Drücken sie die Taste des linken Lautsprechers" oder so ähnlich...
Ich hatte mich bislang aus den Grundkonfigurativen Sachen mit dem Modul rausgehalten... Name und Icon gehen ja noch, das verändert nix grundlegendes :-)

Grüße
Reinerlein

Hallo Spartacus,
ich betreibe zur zeit  einen ZP-90 einen ZP-120 einen Play:3 und das Dock.
Nur das Dock und der Play3 haben keinen Ethernet Anschluss und laufen also übers Wlan.
Der Play3 wird täglich etwa eine Stunde betrieben (im Bad) ich wollte nicht das er den ganzen Tag am Netz hängt bei so wenig Nutzung, also schaltete ich eine Steckdose davor um ihn steuern zu können.

Gelegentlich passierte es nach dem einschalten das der Play3 sich eine total merkwürdige IP hier im netz holte - oder sich selbst gab. Wenn das passierte bekam ich meist auch ärger mit der restlichen Sonos Landschaft.

Heute schalte ich die Steckdose, starte einen presence, schaue ob innerhalb von 50 Sekunden die richtige IP besetzt ist... Falls nicht schalte ich wieder ab um kurz darauf einen zweiten versuch zu starten.
Das Sonosmodul ist seit ich diese Prozedur benutze bei mir nicht mehr abgestürzt.

PS: Der Spaß an FHEM wächst mit großer Hardware - also besorg Dir nen Truck ;-)

Kannst Du mir mal was über den Sub sagen? Ich habe im internet keine Infos über Anschlüsse gefunden, also entweder kann man kein eigenes Eingangssignal einspielen oder es ist schlecht beschrieben.
Mein jetziger Kino Sub hängt am Denon Verstärker und brummt wie sau, den würde ich gerne ersetzen.
Er müsste aber in dem Fall ein Signal des Denon verarbeiten können da ich auf den rest meines 5.1 Systems nicht verzichten möchte.

Hallo zusammen,

@ Reiner:
vielen Dank für Deine Ausführungen. Ich denke, ich werde mir den Cubi zulegen und dann Sonos alleine auf den rpi bringen. 11 Sonos Devices sind schon recht viel und i.d.R. sind am WE auch mind. 4 unterschiedliche Streams aktiv. Die enocean Devices müssen zuverlässig laufen. Es sind zwar erst 22 Devices aber das hat Prio.

Ja beim Bilden von einem Stereopaar muss man den linken Kanal per Tastendruck wählen. Es soll ja nicht das "Anlernen" automatisiert werden, sondern die gespeicherte Konfiguration geladen werden. Keine Ahnung, ob man darauf überhaupt Zugriff hat. War ja nur so eine Idee. Zumindest wäre es prima, wenn man den SUB konfigurieren könnte. Hier stellt man per SW ja auch die "Basslautstärke" ein.
Beim Einbinden des SUBS muss man allerdings keine tasten drücken. Das läuft alles über den Controller.

@ Der-Lolo
Ich hatte mal, zwecks Test, fhem auf meinem alten Dell Laptop D630 aufgespielt. Das war der Wahnsinn, wie das abging! Sowas von schnell! Das hat schon Spaß gemacht...wenn ich fhem auf dem rpi neu starte, dauert das ca. 15-20s. bis das Web-Interface wieder online ist. Bei gleicher Konfig auf dem Laptop waren das Sekundenbruchteile...

Der SUB hat keine Anschlüsse (nur Strom + LAN), der kann nur per SW in das Sonos-System eingebunden werden. Du kannst jedem Sonos-Player einen SUB spendieren. Sinn macht es aber nur bei Stereopaaren, z.B. 2x Play 1 oder 2 x Play 3. Bei mir hängt der SUB an einem ConnectAmp . Am ConnectAmp sind zwei Loewe Stand Speaker ID und der SUB per WLAN (nur 2.1).  Die Stand Speaker werden dann von der Sonos-SW als Hoch und Mitteltöner angesteuert und der SUB macht dann den Rest. Den Unterschied hört man! Mein Bruder hat den SUB an einer Playbar zusammen mit 2 x Play 3 als 5.1.  Das ist m.E. die Beste Lösung; besonders für den TV-Sound. Als ich die Loewe Speaker gekauft habe, gab es die Playbar noch nicht, sonst hätte ich das auch so gemacht.

Aber wenn man so ein Denon Dingen schon hat, dann ist es halt schwierig umzusteigen. Bei mir (naja, meine Frau) war halt wichtig, dass es keinen Kabelsalat gibt. Und Kabel gibt es bei Sonos so gut wie keine. Ein Denon ist sicherlich soundtechnisch nicht zu übertreffen, aber die Playbar mit Sub und 2 x Play3/Play1 ist absolut wohnzimmertauglich!

Christian