Sonos Player disappeared

[hoppel118]

Die folgenden Posts kommen aus dem ,,Sonos steuern" Thread. Für mein Gefühl passt das hier besser hin.

https://forum.fhem.de/index.php/topic,10033.msg1049971.html#msg1049971

Hallo zusammen,

ich bräuchte bitte mal einen Tipp, wie ich an meinem aktuellen Problem weiterforschen kann.

Wie bei vielen anderen vor mir, disappearten die Sonos regelmäßig (ein bis drei/vier Mal am Tag). Seit ein paar Tagen hilft auch ein shutdown restart nicht mehr, weil nicht mehr nur Thread 4 ("Thread 4 terminated abnormally: Error creating SSDP multicast listen socket: Address already in use"), sondern auch noch Thread 1 ("Error during UPnP-Handling: Error creating SSDP multicast listen socket: Address already in use") gleich nach dem Neustart abbricht. M.a.W. Sonos läuft derzeit nur noch über die App aber nicht mehr über FHEM. Natürlich wird es einen rationalen Grund für die Verschlechterung geben, leider kann ich ihn aber nicht rekonstruieren, aber auch der Fehler zum Thread 4 allein muss ja irgendwann behoben werden 

Bei der Suche nach Hinweisen hier im Forum schon lange vor der Verschlechterung habe ich u.a. verstanden, dass bei der o.g. Fehlermeldung meist ein anderes Gerät auch auf dem UPnP-Port 1900 funkt bzw. lauscht, und dass man dieses eigentlich per

sudo netstat -a | grep 1900  bzw.
sudo netstat -apn | grep 1900

einkreisen kann. Bei letzterem meckert mein MacMini, auf dem mein FHEM läuft, dass -n ein unbekanntes Protokoll sei, bei ersterem sucht er eine gute Minute und tut dann so, als wäre nichts gewesen.

Code Auswählen Erweitern


sarah@Tsehuss fhem-6.0 % sudo netstat -a | grep 1900 
sarah@Tsehuss fhem-6.0 % sudo netstat -apn | grep 1900
netstat: n: unknown or uninstrumented protocol
sarah@Tsehuss fhem-6.0 %

                           

Im Netzwerkdienstprogramm von Catalina hätte ich gedacht, dass die Option ,,Netstat -> Multicast-Informationen anzeigen" mir ein wenig weiterhilft, aber bisher leider nicht (vielleicht suche ich nicht das richtige). Auch die drei anderen ,,Netstat"-Optionen helfen mir nicht weiter.

Wenn ich das richtig sehe, kommen vor allem die Harmony-Fernbedienung und Philips Hue als Kandidaten in Frage (aber die sind bei so vielen im Einsatz, dass ich es mir fast nicht vorstellen kann), während ZWave, das KLF200-Modul und die Fritz!Box ziemlich unverdächtig sein sollten.

Weil ich nicht sicher war, ob der Bonjour-Dienst evtl. Teil des Problems sein könnte, hatte ich auch den schon mal deaktiviert, und auch mit dem Delay-Parameter des Sonos-Moduls habe ich mal ein bisschen herumprobiert, beides ohne Erfolg.

Kann mir jemand einen Tipp geben, wie ich im MacOS-Umfeld den Übeltäter (vielleicht sogar systematischer als ich das bisher getan habe) näher einkreisen kann?

Besten Dank im Voraus.

Martin.


Logfile bei jedem Neustart:

Code Auswählen Erweitern


2020.05.03 17:21:04 1: SONOS0: Kein UPnP-Server gefunden... Starte selber einen und warte 1 Sekunde(n) darauf...
2020.05.03 17:21:04 1: SONOS0: ./FHEM/00_SONOS.pm is started by fhem...
2020.05.03 17:21:04 1: SONOS0: ./FHEM/00_SONOS.pm is listening to Port 4711
2020.05.03 17:21:05 3: Opening Sonos device localhost:4711
2020.05.03 17:21:05 3: SONOS0: Connection accepted from localhost:60408
2020.05.03 17:21:05 3: Sonos device opened
2020.05.03 17:21:06 1: SONOS1: UPnP-Thread gestartet.
2020.05.03 17:21:06 2: SONOS1: Error during UPnP-Handling: Error creating SSDP multicast listen socket: Address already in use
at ./FHEM/00_SONOS.pm line 2421 thread 1.
at ./FHEM/00_SONOS.pm line 2421 thread 1.

2020.05.03 17:21:06 1: SONOS1: UPnP-Thread wurde beendet.
2020.05.03 17:21:06 1: SONOS2: LongJobs-Thread gestartet. Prüfe auf LongJobs...
2020.05.03 17:21:06 1: SONOS3: IsAlive-Thread gestartet. Warte 120 Sekunden und pruefe dann alle 30 Sekunden...
2020.05.03 17:21:06 1: SONOS4: Restore-Thread gestartet. Warte auf Arbeit...
Thread 4 terminated abnormally: Error creating SSDP multicast listen socket: Address already in use
at ./FHEM/00_SONOS.pm line 4995 thread 4.
at ./FHEM/00_SONOS.pm line 4995 thread 4.




Die Harmony meldet übrigens beim Start ein Warning - vielleicht hängt das miteinander zusammen (?):

Code Auswählen Erweitern


2020.05.03 17:20:54 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/37_harmony.pm line 1765.
2020.05.03 17:20:54 1: stacktrace:
2020.05.03 17:20:54 1:     main::__ANON__                      called by ./FHEM/37_harmony.pm (1765)
2020.05.03 17:20:54 1:     main::harmony_connect               called by ./FHEM/37_harmony.pm (284)
2020.05.03 17:20:54 1:     main::harmony_Notify                called by fhem.pl (3777)
2020.05.03 17:20:54 1:     main::CallFn                        called by fhem.pl (3697)
2020.05.03 17:20:54 1:     main::DoTrigger                     called by fhem.pl (658)


@Kläwwerhäusle0.1

Wahrscheinlich ist es sinnvoll, wenn du in diesem Thread weitermachst:

https://forum.fhem.de/index.php/topic,46058.30.html

Hast du schonmal probiert alle Nicht-Sonos-IPs auszugrenzen?

Code Auswählen Erweitern

attr Sonos usedonlyIPs /192.168.1.(5\d|60)/

Damit würde lediglich der UPnP Datenverkehr der IPs von 192.168.1.50 bis 192.168.1.60 akzeptiert werden. Bei manchen bringt's was. Bei mir nicht.

Wir haben in dem Thread zu letzt einen Workaround besprochen. Anhand einer Kombination aus at und DOIF wird das Modul inkl. UPnP neugestartet, sobald das Hauptdevice Sonos in den Status ,,disabled" wechselt.

Gruß Hoppel

Hallo Hoppel,

vielen Dank für die Rückmeldung.

Ich hatte hin- und herüberlegt, in welchem Thread ich schreibe, mich dann für diesen (allgemeineren) entschieden, weil es im anderen sehr spezifisch "nur" um mein erstes Problem, das "gelegentliche" Disappearen, ging, aber nicht um den dauerhaften Status "Disappeared", der m.E. das noch gravierendere Problem ist, aber wenn Du es für sinnvoller hältst, verschiebe ich meine Frage gerne dorthin. Besser im anderen Thread weitermachen?

Vielen Dank für Deine Anregung mit den usedonlyIPs, die ich zwar schon wahrgenommen, aber noch nicht ausprobiert hatte. Das habe ich eben - auf meine IPs angepasst - nachgeholt:

Code Auswählen Erweitern


attr Sonos usedonlyIPs /192.168.188.2[2-7]/

derzeit leider noch ohne Erfolg (möglicherweise löst es aber das Problem des gelegentlichen Verschwindens, wenn der dauerhafte Disappeared-Status überwunden ist - ist also "vorgemerkt").

Viele Grüße

Martin.

PS: Am Harmony-Hub liegen die Probleme übrigens nicht, weil ich ihn zwischenzeitlich bis auf Weiteres komplett gelöscht habe (man muss ja manchmal erst lesen, was man schreibt, bevor man weiß, was man denkt  ).

Was genau verstehst du unter gelegentlichem bzw. dauerhaftem Verschwinden?

Ich habe übrigens das Gefühl, dass wir bei der Ursache für dieses Problem alle im Dunkeln tappen...

Geuß Hoppel

[Kläwwerhäusle0.1]

Hallo Hoppel,

vielen Dank für den Transfer!

Also bei dem "gelegentlichen" Verschwinden, das bis vor ein paar Tagen mein Sonos-Problem war, taucht zwar beim FHEM-Restart der bereits erwähnte Fehler zum Thread4 auf, danach sind die Geräte aber voll verfügbar und lassen sich aus FHEM vollumfänglich steuern (aus der App sowieso). In unregelmäßigen Abständen geht dann der state und auch der STATE in den Devices auf "disappeared" und man kann sie aus FHEM heraus nicht mehr ansprechen (wohl aber aus der App - auch aus der, die bei mir auf dem gleichen MacMini läuft). Wenn ich das bemerke (bei mir läuft nicht den ganzen Tag Musik), habe ich FHEM neugestartet und mit dem o.g. Fehler läuft alles wieder funktionstüchtig hoch - bis zum nächsten Mal. Das Ganze in der Regel so zwischen ein und drei oder vier Mal pro Tag.

Mit "dauerhaftem" Verschwinden meine ich den derzeitigen Zustand, in dem beim Restart zusätzlich der erwähnte Fehler zum Thread1 gelogged wird und bei dem die Devices im state und im STATE auf "Initialized" stehen, aber neben dem Plattencover steht "Player disappeared" und er lässt sich von FHEM aus nicht ansprechen (wohl aber weiterhin aus der App).

Ich bin für jeden Tipp dankbar.

Viele Grüße
Martin.

Edit: O.g. Verhalten tritt jeweils für alle 6 Devices (1x connect, 4x Play:1, 1x Play:3) gemeinsam auf.

[ch.eick]

Hallo zusammen,

bei mir laeuft auch einiges nicht ganz koscher. Bei dem Sonos Betrieb mit Lautsprechern in einer Gruppe scheint es hier schon Probleme mit dem Sonossystem an sich zu geben.
Zeitweise scheint der Stream in der Gruppe unterbrochen zu werden, dann ist er wieder da und auch mal wieder weg. Nach einiger Zeit laeuft dann alles wieder stabil.
Es ist wie verhext, auch ein Update auf die aktuellste Sonos Version hat daran nichts geaendert. Ob das vorher schon so war, kann ich nicht sagen, da ich das mit der Gruppe erst seit einigen Wochen nutze.
https://forum.fhem.de/index.php/topic,109199.msg1031494.html#msg1031494

Gruss
     Christian

[juemuc]

Hallo,

also be mir gibt es mit Gruppen kein Problem. Ich erzeuge in FHEM sogar eine Gruppe, wenn die Musik auf einem bestimmten Lautsprecher startet.

Viele Grüße

Jürgen

[ch.eick]

Hallo,

also be mir gibt es mit Gruppen kein Problem. Ich erzeuge in FHEM sogar eine Gruppe, wenn die Musik auf einem bestimmten Lautsprecher startet.

Viele Grüße

Jürgen

Sowas mache ich ja auch mit dem pseudo 7.1

Gesendet von meinem SM-G930F mit Tapatalk

[hoppel118]

Hallo Hoppel,

vielen Dank für den Transfer!

Moin,

gern!

Teste mal den hier beschriebenen Workaround (at und DOIF):

https://forum.fhem.de/index.php?topic=46058.msg937508#msg937508

Damit löst man zwar nicht die Ursache des Problems. Aber man hat Ruhe. Das funktioniert hier bei einigen von uns Betroffenen sehr gut, unter anderem bei mir.

Da sich niemand mit Modul-Entwickler- und UPnP-Knowhow der Ursachenergründung annimmt und das Problem löst, bleibt uns erstmal nichts anderes als dieser Workaround. Aber wie gesagt, das funktioniert 1A!

Gib mal Rückmeldung.

Gruß Hoppel

[Kläwwerhäusle0.1]

Hallo Hoppel,

sorry, war leider ein paar Tage in meinem Hauptberuf unter Wasser.

Ich habe den "at und DOIF"-Workaround eben mal probieren können, aber leider ohne Erfolg - was ich aber ehrlich gesagt auch fast ein bisschen erwartet hatte, weil die Sonos-Devices ja praktisch nur noch angezeigt werden, aber eben nicht ansprechbar sind. Da das vor nicht allzu langer Zeit anders war und ich mich zudem "im Nebenberuf" inzwischen mit meinem NAS vertieft vertraut gemacht habe, habe ich mich entschieden, die FHEM-Installation auf zwei Geräte zu verteilen und in diesem Zusammenhang die Sonos auf die NAS-Seite zu ziehen. Das wird aber ein paar Vorarbeiten brauchen und daher etwas Zeit in Anspruch nehmen. Ich würde mich hier wieder melden, wenn ich soweit bin und den dann aktuellen Stand berichten. Und bei Bedarf könnten wir von da aus dann weiter nach Lösungen suchen - dann hoffentlich "nur noch" für das "gelegentliche" Disappearen...

Mit anderen Worten, bitte nicht als Desinteresse o.ä. interpretieren, wenn es einige Tage keine Neuigkeiten von meiner Seite gibt.

Viele Grüße

Martin.

[hoppel118]

Moin,

da brauchst du dir keine Gedanken machen, dass ich das als Desinteresse auffasse. Es kommt öfters mal vor, dass jemand nicht reagiert. Wer nicht will der hat schon. Ich habe manchmal auch nicht die Zeit zu reagieren bzw. vergesse auch mal eine Antwort und manche Sachen müssen auch einfach erstmal getestet werden oder gebaut werden für einen Test.

Eigentlich sollte dieser Workaround auch bei dir funktionieren. Hattest du auch die beiden folgenden attr am Sonos-Hauptdevice konfiguriert?

Code Auswählen Erweitern

attr Sonos event-on-change-reading state
attr Sonos event-on-update-reading myStatus

Ohne das funktioniert der Workaround nicht.

Das Wording ,,gelegentliches bzw. dauerhaftes verschwinden" verstehe ich wohl immer noch nicht so ganz...

Wie ist der Status des Sonos-Hauptdevices bei dauerhaftem Verschwinden? (Es geht hier nicht um die einzelnen Geräte-Devices, sondern lediglich um die Zentrale.)

Ist der Status dann ,,disabled"? Wenn ja, sollte der Workaround funktionieren. Wenn nein, verstehe ich nicht, was da bei dir passiert.

Was passiert, wenn deine Geräte-Devices nicht mehr funktionieren und du am Sonos-Hauptdevice das ,,attr Sonos disable 1" setzt, 60 Sekunden wartest und das attr mit ,,deleteattr Sonos disable" wieder löschst? Funktioniert dann wieder alles?

Viele Grüße Hoppel

[87insane]

Hey zusammen,

wollte mal fragen ob es hier mittlerweile was anderes gibt als ein disapper doif Workaround...?

Ich selber löse es aktuell noch so:
defmod di_sonosdisappercheck DOIF ([05:00] and [?sonos] ne "opened" )(attr sonos disable 1)(attr sonos disable 0)

Allerdings nervt es wenn man mal eine Sonos umstellt und fhem genau das auch noch mitbekommt. Dann gehen alle auf disapper. Kann man hier irgendwie unterstützen oder hat jemand eine Vermutung warum das überhaupt so ist? Wenn ich unterstützen kann, werde ich das gern tun

[hoppel118]

Hey zusammen,

wollte mal fragen ob es hier mittlerweile was anderes gibt als ein disapper doif Workaround...?

Moin, es gibt bisher nichts anderes.

Ich selber löse es aktuell noch so:
defmod di_sonosdisappercheck DOIF ([05:00] and [?sonos] ne "opened" )(attr sonos disable 1)(attr sonos disable 0)

Warum nimmst du die Prüfung immer genau um 5 Uhr morgens einmalig vor? Was machst du, wenn das Sonos Device nach 5 Uhr in den Status ,,disabled" geht? Wartest du dann den Rest des Tages? Verstehe ich das DOIF richtig? Du brauchst dafür kein ,,at"?

Allerdings nervt es wenn man mal eine Sonos umstellt und fhem genau das auch noch mitbekommt. Dann gehen alle auf disapper. Kann man hier irgendwie unterstützen oder hat jemand eine Vermutung warum das überhaupt so ist? Wenn ich unterstützen kann, werde ich das gern tun

Willkommen im Club. Warum das so ist, weiß hier wohl niemand oder die Wissenden halten sich bedeckt. Hier würden einige gern bei der Fehlersuche unterstützen. Es fehlt der Entwickler.

Viele Grüße Hoppel

[87insane]

Guten Morgen,

meiner Erfahrung nach gehen die Sonos nur einmal max auf disapper und das auch nur noch, wenn ich mal eine box umstelle zb bei schönem wetter in den Garten und die Prüfung genau in den Zeitraum statt findet, wenn ich die Box vom Strom getrennt habe.

Probiert es mal aus. Genau wie es da steht - ohne at. Sollte euren Zustand erträglicher machen. Aber ich würde auch das gern weg haben...

Gesendet von meinem LM-G810 mit Tapatalk

[ch.eick]

Es fehlt der Entwickler.

Vielleicht sollten wir mal eine Ausschreibung machen

Gruss
     Christian

[hoppel118]

meiner Erfahrung nach gehen die Sonos nur einmal max auf disapper

Nö, das ist zumindest bei mir nicht der Fall, siehe Screenshot vom 11. Mai. Manchmal ist es so, manchmal läuft es monatelange durch. Manchmal passiert das nur ein oder zwei Mal an einem Tag. Also völlig willkürlich.

Bei deiner Lösung wird aber so wie ich dein DOIF verstehe, nur um 5:00 Uhr morgens geprüft, ob der Status ungleich opened ist. Wenn dein Sonos Device also bspw. um 16:00 Uhr eines Tages auf disappeared geht, bleibt der Zustand ,,disappeared" bis 5:00 Uhr morgens des nächsten Tages erhalten.

Bei mir wird der Zustand sofort korrigiert. Ich lasse mir dann immer noch eine Nachricht per WhattsApp schicken, damit ich weiß dass es passiert ist. Ich hatte mir eigentlich erhofft, dadurch zu verstehen, was ich geändert habe, um den Fehlerverursacher zu finden. Aber leider nicht, das Problem tritt einfach irgendwann auf, manchmal auch mitten in der Nacht, wenn sich an meiner Netzwerk-Umgebung definitiv nichts ändert.

und das auch nur noch, wenn ich mal eine box umstelle zb bei schönem wetter in den Garten und die Prüfung genau in den Zeitraum statt findet, wenn ich die Box vom Strom getrennt habe.

Ich stelle meine Sonos nicht um. Alle haben Ihren berechtigten und festen Platz.

Ich werde mir dein DOIF aber auch nochmal genauer anschauen. Evtl. kann man durch eine Kombination deines DOIFs und dem hier geposteten at-DOIF auf das at verzichten.

Vielleicht sollten wir mal eine Ausschreibung machen

Wie hoch soll dann das Ausschreibungsvolumen sein? Irgendwie widerspricht das dem Open Source Gedanken...

Die Frage ist, ob es wirklich so kritisch ist, wie wir alle denken. Mit dem Workaround haben wir einen nahezu störungsfreien Betrieb. Bald kommt das neue Sonos OS. Ich könnte mir vorstellen, dass wir dann einen Entwickler für das vorhandene oder ein neues Modul brauchen. Evtl. läuft aber auch einfach alles wie gehabt weiter... Wir werden sehen.

[87insane]

Teste es mal wie ich schrieb. Der Dienst hängt sich dann nicht mehr weg. Diese Willkür hatte ich auch...mal so mal so... Sobald aber das doif einmal zuschlägt geht es listigerweise ewig ohne Probleme. Ich nutze die Sonos als Klingel. Also muss das zuverlässig laufen.

Ich prüfe das um 5 weil das reinitiallisieren  um diese Zeit am meisten Sinn macht. Wenn jemand um die Zeit klingelt will ich das eh nicht hören. Meines erachtens nach, gehen leider alle offline wenn nur ein Gerät was zu meckern hat. Ich habe das soweit auseinander genommen, wie es mir möglich war. Es helfen auch keine festen IPs oder sonst was.

Der reinitial Zeitraum ist meist so 30 bis 45 Sekunden. Dann ist wieder alles gut. Das doif führt das auch nur aus wenn eben nicht = opened... Teste es mal...bin gespannt was du sagst. Für mich sollte das entweder behoben werden oder so eine Art Workaround direkt ins Modul.

Gesendet von meinem LM-G810 mit Tapatalk

[hoppel118]

Ok, bin gespannt. Verstehe zwar nicht warum das so sein soll, aber gut. Habe momentan allerdings nicht wirklich die Gelegenheit für Tests, da gerade ein längerer Urlaub, bei dem ich nicht zu Hause sein werde, ansteht.

Viele Grüße