Sonos steuern

[Reinerlein]

Hi Merhan,

hmmm... an dieser Stelle wird dem Fhem-Part des Moduls mitgeteilt, dass es einige Readings zu aktualisieren gibt. Dabei sind alle Informationen bereits "drüben" angekommen, und sollen jetzt nur noch auf die Fhem-Devices übertragen werden (mittels Bulkupdate-Mechanismus).

Das sollte eigentlich nicht so lange dauern (blockiert aber natürlich Fhem währenddessen). Andererseits sollte dein HMLAN da auch keine solche Verzögerung verursachen. Das erscheint mir eher so, als würde Fhem irgendwas tun, dabei blockieren und den für HMLAN notwendigen Refresh-Zyklus verpassen (irgendwas um die 30 Sekunden), und deswegen die Verbindung verlieren... Diese wird dann sofort wieder aufgebaut, sobald Fhem wieder "frei" ist.

Kannst du das System mal kleinschrauben, also auf Sonos beschränken? Vielleicht bei einer Kopie an einer anderen Stelle.
Du kannst auch im ersten Schritt versuchen alle Notify-Befehle, die irgendwie an der Aktualisierung der Sonos-Readings dranhängen, zu überprüfen (bzw. testweise zu deaktivieren). Das Aktualisieren von Readings geht grundsätzlich (mindestens) an alle definierten Notify-Anweisungen, die dann entscheiden, ob sie zuständig sind, oder nicht. Je mehr Notifies, desto mehr Arbeit für Fhem beim Aktualisieren eines Reading (bzw. u.U. Folgearbeiten durch die Erledigung der entsprechenden Notify-Anweisungen, das erfolgt sofort, und nicht später).

Wenn das dann funktionieren sollte, dann nach und nach deine anderen Komponenten wieder einbauen, bis es nicht mehr sicher funktioniert. Ich vermute da eine Querbeeinflussung, sodass nicht ein Modul alleine die Schuld trägt, sondern mehrere Dinge zusammen...

Grüße
Reiner

[der-Lolo]

Guten Morgen Reinerlein,
Ich verstehe seit ich mir einen SonosAmp zugelegt habe fürs Büro die Sonos Welt nicht mehr...
Ich habe eine mindmap erstellt die meinen netzwerkaufbau zeigen soll.
WLAN an der fritzbox ist nicht aktiv - alle Geräte beziehen aber über die fritzbox über ihre Mac Adresse immer die gleiche IP.
Wenn ich nun den play3 vom Strom trenne und wieder anschalte sucht er sich wahrscheinlich den für ihn stärksten Knoten, mal ist das der Amp ein anderes mal ist es der ZP ob er auch versucht sich am Dock anzumelden ist nicht klar - der Dock hängt ja auch nur im WLAN...

Wenn der play3 sich mit dem Amp Verbindet taucht er nicht im iPad auf - lässt sich auch dann nicht manuell hinzufügen. Der Dialog arbeitet und reagiert auf das Mute und lauter drücken am play3 es kommt aber kein grüner haken.
Wenn ich den Amp ausschalte verbindet er sich brav mit dem ZP.

Hast du eine Idee was ich tun kann? Für ne Stunde Musik am Tag möchte ich den play3 nicht ständig am Netz lassen.

Ps: FHEM ist auskommentiert...

[Reinerlein]

Hallo der-Lolo,

ich persönlich würde in einem ersten Schritt dafür sorgen, dass nur ein Zoneplayer am verkabelten Netz hängt.
Du hast jetzt eine Schleife gebaut, da es jetzt mehrere Routen zum Ziel gibt. Das Problem ist dabei, dass ein Datenpaket jetzt eine Kreisfahrt machen kann, und nie am Ziel abgeliefert wird.
Eine TCP/IP Datenlieferung erfolgt immer auf die Art und Weise, dass versucht wird, den kürzesten Weg zu finden. Den gibt es bei dir aber nicht mehr (für Interessierte: Das ist das Problem des Handlungsreisenden). Nun gibt es eine Technologie, die genau das ermöglichen soll (ich meine der Name dafür ist Spanning-Tree-Detection, das ganze sorgt auf jeden Fall dafür, dass ein Paket weiß, wo es schon überall langgekommen ist, und den Weg nicht nochmal geht).
Das scheint bei dir vielleicht nicht jeder Switch zu beherrschen...

Grüße
Reiner

[djhans]

Hallo der-Lolo,
ich habe zusätzlich zur Bridge auch 2 weitere Sonos Komponenten am LAN und das funzt bei mir ganz gut. Einmal der ConnectAMP im Wohnzimmer und auf der 1.Etage der Schlafzimmer-Sonos (2 x Play 1 als Stereopaar, der linke Kanal hängt am LAN)....

Was mir auffällt ist, dass Du am 2. LAN Port des ConnectAMP einen Drucker hast. Das hatte ich mit meiner Dreambox auch so gemacht und nur Probleme gehabt. Der ConnectAMP hat teilweise nicht reagiert und einen Neustart hingelegt. Vielleicht einfach mal den Drucker abklemmen....

@all:
Zu meinem Sleeptimer Button-Problem:
Ich habe das mit dem SleepTimer jetzt anders gelöst, ob es praxistauglich ist, weiss ich noch nicht.
Generell stelle ich sicher, dass immer mein Radiosender geladen ist. Das mache ich mit "presence:.appeared " und wird sowohl beim Start von fhem, als auch beim Einstöpseln der Player vorgenommen.
Der Sleeptimer wird immer um 22:00 Uhr gestartet, egal ob der Sonos läuft, oder nicht. Wenn ich nun zu Bett gehe, drücke ich einfach den Play Button am Sonos und durch das Event "Playing" wird die Lautstärke auf angenehme 3% heruntergefahren (nur zwischen 21:00 und 23:00 Uhr).
Wenn ich halt vor 22Uhr schlafen gehe, spielt der Sonos den Sender direkt ab und um 22 Uhr startet dann nahtlos der Sleeptimer für 90min. Wenn ich halt kein Bock mehr auf Mucke habe, dann schalte ich Gerät einfach mit dem Button weder ab, ansonsten erledigt das der Sleeeptimer um 23:30 bzw. 0:30 an samstagen...

Später kann man das ja mal mit Lichtschaltern machen. Aber ich weiß halt absolut noch nicht, ob ich das teuere enocean oder die HM-Sachen nutzen soll. Wenn jemand weiß, wo Vor- und Nachteile zu den System diskutiert werden oder Erfahrungen mit den Komponenten hat, dem wäre ich dankbar für Tipps.

djhans

[djhans]

Hi Reiner,
kann man die AlarmID des aktuell laufenden Alarms bestimmen?

mit

Code Auswählen Erweitern

{ReadingsVal("Sonos_Schlafzimmer", "AlarmListIDs", 0)}
bekomme ich alle IDs genannt, möchte aber auf einen bestimmten Alarm reagieren.

Anwendungsfall:
wenn der Schlafzimmer_Sonos mit ID 67 morgens weckt, dann schalte den Wohnzimmer Sonos nach 30min in einer Gruppe hinzu.

Gruß,
Christian.

[Reinerlein]

Hi Christian,

soweit ich das weiß, liefert das Sonos-System diese Info nicht.
Man bekommt nur eine Alarm-Änderung mit, wenn der Alarm nur einmal laufen sollte, und deshalb nach einmal ausführen disabled wird...

Du bekommst nur die Info, dass es ein Alarm ist, der da gerade auf "Play" gedrückt hat, nicht welcher es war...

Grüße
Reiner

[djhans]

Hi,
das ist schade!

Keine Ahnung ob das hier etwas hilft (https://code.google.com/p/openhab/wiki/SonosBinding), aber hier steht etwas zu "alarmproperties (Properties of the alarm currently running)". Kennst Du aber bestimmt schon!

djhans

[der-Lolo]

Danke für eure Tipps - ohne weiteres kann ich den Amp nicht von Kabel trennen, die Komponenten sind zwar in der gleichen Etage - aber diagonal in jeweils der gegenüber liegenden Ecke der Wohnung... Das Wireless Netz das Sonos erstellt schafft es nicht, obwohl der Dock dazwischen - zwar nicht ganz in der Mitte - aber dazwischen steht...
Wie ich es auch drehte und wendete - ich bekam keine Verbindung mehr zum play3 es half nur ein reset auf werkseinstellungen... Es gab wohl schon ein paar Menschen mit einem ähnlichem Problem - deswegen wurde ich im Netz schnell fündig...

[Reinerlein]

Hi Christian,

das mit dem openhab schaue ich mir mal an.
Leider gab es dort keine Quelltexte dieses Bindings zum Runterladen, sodass ich die Klassendateien erst dekompilieren muss. Das kann ich aber leider nicht an meinem iPad, sodass ich da Morgen am normalen Rechner was versuche...

Ich vermute aber, dass es einfach die Daten des "nächsten" Alarms sind. Wahrscheinlich holen die sich die Liste aller Alarme, und ermitteln einfach den nächsten, der zeitlich dran wäre (und aktiv ist)... Das wäre in meinen Augen nur halb interessant, da man dann nie sicher sein kann, auch wirklich den richtigen Alarm in der Hand zu haben. Es könnte ja noch kurzfristig einer dazwischengekommen sein, oder was auch immer...

Ich habe nochmal die Datenangebote der UPnP-Schnittstelle überprüft, und so auf Anhieb nichts gefunden, was mir die Information des aktuell laufenden Alarms bieten würde...
Das war den Entwicklern von Sonos wohl nicht wichtig. Wichtig war vermutlich nur, dass es überhaupt ein Alarm ist, der gerade aktiv ist. Dann kann man den auch Pausieren und ähnliches...

Grüße
Reiner

[JoeALLb]

@der-Lolo
Gehts jetzt seit dem Reset?
Ich habe auch 3 Geräte am LAN angestöpselt und andere nicht und alles funktioniert wunderbar,  auch wenn eines mal nicht da sein sollte.

Allgemeine INFO:
Seit vorgestern lief auch mein fhem rund, ohne abstürze, jedoch klappt mein morgendlichen Google-Wecker nicht mehr.  Hab die Ursache aber noch nicht geprüft. Vielleicht hängt es das sachlich mit dem verschwinden eines Sonos - Players zusammen,  ich habe nämlich kürzlich an einem Player vor dem fhem Absturz das Netzwerkkabel getauscht.

Das Ermitteln der AlarmID wurde mich auch interessieren,  aus dem selben Grund.

LG Joe

Gesendet von meinem Xperia Pro mit Tapatalk

[djhans]

Hi Reiner,
super! Vielen Dank!. Vielleicht geht das ja doch irgendwie mit dem Alarm, sonst baue ich halt einen Workaround...

Ich habe aber immer wieder diese fetten Abstürze und ich weiss nicht, wo ich ansetzten soll! Habe schon das Netzteil ausgetauscht, aber das bringt offenbar nichts. Ich vermute, es hängt mit dem upnp-Server  zusammen. Das Problem tritt hauptsächlich auf, wenn Player versetzt werden.

Heute morgen habe ich den Player um halb acht versetzt und danach war das System tot. Gemerkt habe ich es erst um kurz nach acht...

Die Abstürze passieren allerdings auch, wenn ich keine Player versetzte. Gestern Abend habe ich ein paar Funktionalitäten für den Sonos implementiert und plötzlich reagierte das Webinterface von fhem nicht mehr. Ich habe sowieso den Eindruck, dass das System manchmal sehr lange überlegt, bis es auf die Klicks im Webinterface reagiert. Im Hintergrund läuft auch eine ganze Menge ab. Kann es sein, das fhem einfach überlastet ist? Immerhin habe ich 8 Sonos Komponenten im Netz.

djhans

Im Anhang mal das Logfile der letzten 15min vor dem Absturz..vielleicht entdeckst Du ja etwas.

[det.]

@ all,
kann hier mit meinem derzeit immer noch einzigen ZP90 nicht viel beitragen, außer die Erfahrung, dass seit dem Umzug des Produktiv FHEM mit SONOS auf ein Cubie2 Board alles viel flüssiger läuft und Reiners SONOS Modul diese Konfiguration kein einziges Mal zum Absturz überreden konnten. Vorher hatte ich für SONOS einen extra RPI über FHEM2FHEM an den Produktiv RPI gekoppelt. Der SONOS RPI ist da öfter abgestürzt.

[Reinerlein]

Hi Christian,

sooo, wer lesen kann ist klar im Vorteil. Ich habe die Stelle gefunden, wie ich die 'AlarmRunningID' abfragen kann, und tue das in der aktuellen Developer Version jetzt auch

Desweiteren habe ich mir das Log mal angeschaut:
Das bricht ja ziemlich ruckartig ab. Ich könnte mir vorstellen, dass Fhem in dem Augenblick kurzzeitig so beschäftigt war, dass er nicht auf die Nachricht auf dem Socket vom SubProzess reagieren konnte. Das wiederrum mochte der SubProzess nicht wirklich, und hat die zu Übertragenden Befehle und Informationen direkt mal verworfen
Das habe ich nun versucht zu korrigieren... Vielleicht geht das ja jetzt besser...

Zu der Anzahl kann ich leider auch nicht viel beitragen, da ich nur drei Sonos-Komponenten habe...

Grüße
Reiner

[djhans]

Reiner,
das ist perfekt! Vielen Dank für Deinen Support. Ich teste es umgehend aus und geben Feedback.

Frage: wie kann ich die ID Abfragen?
Nachtrag:
hat sich erledigt:

Code Auswählen Erweitern

{ReadingsVal  ("Sonos_Schlafzimmer","AlarmRunningID",0)}

Danke,
Christian.

[JoeALLb]

Hm,
Irgendwas hat hier nach dem Update nicht fuunktioniert,
habe extra davor mit killall versucht, alle perl-prozesse zu beenden.

Kann da noch etwas anderes den Port blockieren, als perl?
Das UPNP-Modul startet keine C++ - Applikation?!?

lG
Joe

Code Auswählen Erweitern


killall -9 perl
perl: Kein Prozess gefunden

/etc/init.d/fhem start
Starting fhem...
root@raspberrypi:~# Subroutine myUtils_Initialize redefined at ./FHEM/99_myUtils.pm line 118, <$fh> line 5.
Current: "fhem.pl", gPath: "./FHEM"
Current: "FHEM/00_SONOS.pm", gPath: ""
2014.02.12 14:39:22 1: SONOS0: FHEM/00_SONOS.pm is listening to Port 4711
Bind failed: Die Adresse wird bereits verwendet at FHEM/00_SONOS.pm line 4888.



Edit: Schreibfehler