SONOS: Neue Version vom 26.2.2018

Reinerlein · 26 Februar 2018, 09:57:42

Hallo zusammen,

da der Test bzgl. Sonos im Docker-Container, bzw. die Erkennung des Verlusts des Fhem-Prozesses, erfolgreich war, und ich mit der Umstellung von ExportSonosBibliothek in einen eigenen Thread fertig bin, hier also eine neue Version.

Folgende Änderungen im Detail:

ComObjectTransportQueue in Client_ReceiveQueue umbenannt.
If-Abfrage um die can_read-Schleife im SubProzess eingebaut, Um Signalunterbrechungen zu berücksichtigen.
Neuer Getter "WifiPortStatus". Liefert Active, wenn das WLAN aktiviert ist, sonst Inactive.
Drei neue (automatisch ermittelte) Readings "Orientation", "WifiEnabled" und "WirelessMode".
Warnung mit "unescaped left brace" in Tag.pm wurde korrigiert.
ExportSonosBibliothek wird nun in einem eigenen Thread (LongJobs-Thread) ausgeführt. Dadurch bleibt das System steuerbar, auch wenn gerade ein langwieriger Export läuft.
Prüfmethode eingebaut, um verlorengegangene Fhem-Prozessverbindungen (aus Sicht des SubProzesses) zu erkennen, und entsprechende Thread-Bereinigungmaßnahmen durchführen zu können.

Wie immer ab sofort im SVN, oder ab Morgen per update...

Grüße
Reinerlein

Elektrolurch · 26 Februar 2018, 10:31:49

Hallo Reinerlein,

vielen Dank für den Einbau des Exportes. Werde es morgen ausprobieren.
Ach ja, hatte gestern seit langem mal wieder Meldungen mit dem Hinweis auf fehlendes readingsBeginUpdate im log. Mein monit hatte gemeldet, dass der load des Systems bei 71 % stand. Vermutlich müsste diese Problematik ja nun auch mit Deinem update behoben sein.

Elektrolurch

kjmEjfu · 04 März 2018, 11:01:38

Aus irgendeinem Grund stellt sich bei mir das Sonos-Device automatisch auf disabled (zeigt jedenfalls der State an). Dadurch gehen die ganzen Player auf disappeared und natürlich funktionieren meine diversen Sprachansagen nicht mehr.

Im Logfile sehe ich dazu nur:

Code Auswählen

2018.03.03 12:44:13 2: SONOS0: LastProcessAnswer way too old (Lastanswer: 1520077410 ~ 2018-03-03 12:43:30)... try to restart the process and connection...
2018.03.03 12:44:14 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...

eine Idee?
Vorher lief es recht zuverlässig.

Reinerlein · 04 März 2018, 11:10:50

Hi kjmEjfu,

als Veraltungsmaßstab wird der bei der Sonos-Definition angegebene Interval-Wert verwendet, und mit 4 multipliziert.

Da bei dir schon nach 43 Sekunden ein Ausfall festgestellt wird, scheint der Wert vielleicht auf 10 zu stehen?
Das scheint für deine Installation ein bißchen zu kurz zu sein.

Setz den doch mal auf 30 oder so...

Grüße
Reinerlein

det. · 04 März 2018, 11:25:20

Hallo Reiner,
Auch bei mir tritt folgender Effekt auf: wenn ich ohne morgendliches FHEM Update versuche Sonos zu starten, passiert nichts, da SONOS auf disabled steht und mir keine Möglichkeit bekannt ist, das manuell zu starten. Das war bisher auch nicht nötig. Letzter Eintrag dazu im Log:

Code Auswählen

2018.03.03 23:08:33 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...
Da ich über etwas Fhem Code angestoßen durch einschalten der Funksteckdose starte, wäre es leicht SONOS0 vorher zu rebooten, aber wie?

Reinerlein · 04 März 2018, 12:15:20

Hi det.,

es wäre jetzt noch Interessant zu wissen, was davor passiert, damit dieser Prozess sterben musste

Wenn es auch so eine Veraltungsgeschichte ist, dann könntest du auch mit dem Interval rumspielen...

Ansonsten müssen wir mal untersuchen, was da das Problem ist...

Neustarten kannst du den SubProzess immer über Setzen des Attributs "disable" am Sonos-Device. Kurz auf "1" setzen, warten, dann wieder löschen oder auf "0" setzen...

Grüße
Reiner

OdfFhem · 04 März 2018, 14:31:14

Hallo,

ich habe folgende "Probleme", mit denen ich gerade kämpfe:

- Ist bei einem SONOSPLAYER das Attribut disable auf 1 und/oder das Readings state bzw. presence auf disappeard gesetzt, wird trotzdem versucht, das Cover herunterzuladen.
Dies führt regelmäßig zum Einfrieren des FHEM-Systems, bis wohl die Timeouts zuschlagen. Evtl. wichtig in dem Zusammenhang - ich verwende die Option "generateProxyAlbumArtURLs".

Code Auswählen


2018.03.04 14:05:11 1: SONOS0: Cover couldn't be loaded "http://192.168.178.39:1400/getaa?...": 500 Can't connect to 192.168.178.39:1400

- Bei einem Stereopaar schlägt der Versuch, das Cover herunterzuladen, ebenfalls regelmäßig fehl. Ich bin mir nicht ganz sicher, aber es könnte daran liegen, dass es sich dabei um den "abhängigen" Stereopartner handelt, der vermutlich gar keine Cover vorhält.

Code Auswählen


2018.03.04 14:05:17 1: SONOS0: Cover couldn't be loaded "http://192.168.178.38:1400/getaa?...": 404 Not Found

Noch eine zusätzliche Anmerkung: Wird die Wiedergabe auf dem Stereopaar gestoppt, steht einer von beiden auf STOPPED und der andere weiterhin auf PLAYING.

- Wenn bei einem SONOSPLAYER das Attribut disable vor dem "Start" des Sonos-Device entfernt wird, wird der Player beim "Start" des Sonos-Device erkannt und kann komplett gesteuert werden.
Wird das Attribut disable beim SONOSPLAYER nach dem "Start" des Sonos-Device entfernt, wird der Player nicht nachträglich erkannt und bleibt auf disappeared stehen.
Gibt es hier einen Weg, wie ein Player auch nachträglich noch integriert werden kann - ohne Neustart des Sonos-Device?

Viele Grüße

det. · 04 März 2018, 18:21:42

Zitat von: Reinerlein am 04 März 2018, 12:15:20
Neustarten kannst du den SubProzess immer über Setzen des Attributs "disable" am Sonos-Device. Kurz auf "1" setzen, warten, dann wieder löschen oder auf "0" setzen...

Hallo Reinerlein,
Danke, so geht es. Da ich die Dinger immer über ein event einschalte (Funksteckdose oder WOL vom PC), hätte ich auch ein definiertes Ausschaltevent zur Verfügung. Gibt es eine Möglichkeit die Sonos Player und Prozesse beim Ausschalten zu killen. Da Sonos seit längerem bei mir nicht mehr unter root läuft (da ging es früher), werden die Player gern noch als appeared angezeigt, obwohl sie schon lange keinen Strom mehr bekommen.

Reinerlein · 04 März 2018, 18:50:23

Hi det.,

du könntest mal mit dem pingType spielen. Root ist nur für pingType=ICMP (Ping) notwendig. Irgendwer bei Unix/Linux hielt das mal für Megagefährlich, nur ein gelernter Systemverwalter solle das benutzen dürfen

Grüße
Reinerlein

Reinerlein · 05 März 2018, 09:11:25

Hallo OdfFhem,

mit den disabled-Playern und Covern, sowie disappeared und Covern baue ich gerade etwas ein...

Das Problem mit den Stereopartnern und den Covern muss ich mir mal anschauen. Der Transportstate ist so normal, da das der Zustand ist, der von Sonos geliefert wird. Das ist wie bei anderen Gruppen auch.

Zu dem Thema Player nachträglich "enablen": Du kannst ein "RescanNetwork" am Sonos-Device ausführen. Dann sollte der wieder gefunden werden. Ich versuche mal etwas entsprechendes einzubauen...

Grüße
Reinerlein

OdfFhem · 05 März 2018, 18:36:52

@Reinerlein
Schon mal vielen Dank fürs Prüfen/Ändern.

Das mit dem "RescanNetwork" hatte ich schon mal ausprobiert.
Dies funktioniert insoweit, dass er den neu eingeschalteten SONOSPLAYER findet; er taucht u.a. auch im Readings "AllPlayer" vom Sonos-Device auf.
Allerdings bedienbar sind anschließend nur die, die beim "Start" des Sonos-Device online waren; der nachträglich eingeschaltete SONOSPLAYER bleibt weiterhin unbedienbar.

Code Auswählen


Auszug aus den Readings des nachträglich eingeschalteten SONOSPLAYER
--> LastActionResult ... CheckProxyObject-ERROR: SonosPlayer disappeared? ... 2018-03-05 17:42:58

Grundsätzlich einsatzbereit ist er allerdings - die Sonos-App zeigt ihn an und er kann auch problemlos bedient werden.

Zustand nach dem RescanNetwork

Code Auswählen


device ... state ... presence ... disable

Bad ... initialized ... ~~NotLoadedMarker~~ ... 1
Büro ... PLAYING ... appeared ... 0
Küche ... initialized ... ~~NotLoadedMarker~~ ... 0

"Büro" war beim "Start" des Sonos-Device bereits eingeschaltet (ist in der Sonos-App gelistet und vollständig bedienbar).
"Bad" ist beim "RescanNetwork" ausgeschaltet und disabled (ist nicht in der Sonos-App gelistet).
"Küche" wurde irgendwann (lange nach) nach dem "Start" des Sonos-Device eingeschaltet (ist in der Sonos-App gelistet und vollständig bedienbar). "RescanNetwork" führt nicht zu "appeared".

Viele Grüße

Jamo · 08 März 2018, 11:51:36

Hallo Reiner,
Auch bei mir stellt sich das Sonos-Device manchmal automatisch auf disabled (zeigt jedenfalls der State an), zuletzt heute morgen nach einem FHEM update und shutdown/restart.
Hast Du eine Idee?

Reinerlein · 08 März 2018, 12:16:02

Hi inoma,

also selbsttätig setzt das Modul kein Attribut disable.

Aber als Folge eines Modify auf dem Sonos-Device wird dann auch versucht den SubProzess zu stoppen und als Folge davon wird alles auf disabled gesetzt.
Das ist notwendig, damit nach dem erfolgreichen Modify wieder von neuem begonnen werden kann. Es sollten sich dann ja Definitions-Parameter geändert haben, sonst würde man ja kein Modify durchführen...
Vielleicht passiert das als Folge eines "rereadcfg"?

Ist es vielleicht etwas in dieser Richtung?

Aber in diesem Fall sollte irgendwann auch wieder ein SubProzess da sein, und dementsprechend wieder alles laufen...

Grüße
Reiner

P.S.: Bei einem Neustart passiert das anscheinend auch (habe ich gerade gesehen, Fhem hat da manchmal kein sauberes Vorgehen $:-\$ ), aber es gibt noch keinen SubProzess, den man beenden kann, und somit sollte das gefahrlos sein.

Reinerlein · 10 März 2018, 17:32:40

Hi,

ich habe eine neue Version eingecheckt. Vielleicht ist es damit besser...
https://forum.fhem.de/index.php/topic,85554.0.html

Grüße
Reiner

f.f · 04 Juni 2018, 22:49:39

Hi,

habe seit neuestem auch das "disable" und "disappear" Phänomen.
Alles (zumindest Sonos Modul) lief zuvor völlig problemlos.
Jetzt springt das Modul nach "LastProcessAnswer way too old" auch in disable. Könnte es sein, dass meine Installation zu gross ist (obwohl ich die Tage eigentlich nicht viel geändert habe)? Ich habe relativ viele Boxen installiert: 4 Stereopaare mit je 2 Play1, 2 einzelne Play1, 3 Connect, 1 Connect Amp, 1 Play 5.

Ich habe in meiner Not schon alles rausgelöscht, das Sonos device gelöscht und neu definiert, aber ohne Erfolg. Wenn ich das Intervall auf 40 setze dauert es "gefühlt" etwas länger bis es passiert. Aufgrund der vielen Geräte ist das "probieren, also das mehrfache Löschen der Devices extrem nervig. Gibt es eine Möglichkeit das Sonusmodul zum Test nur auf genau die IP einer einzigen box festzulegen, dann könnte ich das Problem evtl eingrenzen und das log von monumentaler Größe erst mal auf überschaubare Zeilen herunterzubrechen?

Könnte das ganze auch mit einem extender was zu tun haben? Bei mir bricht in letzter Zeit des öftern mal das Internet ab, so dass ich den Router neu starten muss, dann nutzt das eine oder andere Gerät im Haus schon mal die Chance und nisted sich im moment des knockouts des Routers im Extender WLAN ein (der wiederum über powerline mit der Fritzbox kommuniziert). Die Verbindung ist dann allerdings eher schlecht. Wann springt das Modul in den "disable" modus?

Gruss
Frank