Sonos steuern

[Reinerlein]

Hi Joe,

nee, das UPnP-Modul ist pures Perl. Aber natürlich kann prinzipiell jeder den Port belegen, der ist ja nicht reserviert (auch wenn er manchmal verduftet

Ich würde im ersten Schritt versuchen, den Fehler in der myUtils zu beheben. Das kann alles Seiteneffekte haben.
Dann könntest du noch mittels "netstat" prüfen, welche Ports belegt sind, und, soweit ich weiß, auch von wem.
Damit solltest du dem ganzen auf die Spur kommen.

Manchmal dauert die Freigabe eines Port aber auch nur einen Augenblick, und man muss etwas warten...

Grüße
Reiner

[djhans]

Hi Reiner,
so! Seit gestern keinen Absturz mehr! Manchmal dauert es zwar eine ganze Zeit, bis fhem wieder reagiert (teilweise mehr als 30sec.), aber es scheint nicht mehr abzustürzen...

Eine Frage zur SleeptimerVersion:
Wird diese gesetzt, wenn der Sleeptimer eines bestimmten Players startet? Dann könnte ich, ähnlich wie bei der RunningAlarmID, auch auf bestimmte Sleeptimer reagieren, richtig?
Man müsste dann nur nach dem Start eines Sleeptimers, den Wert in einer Variablen ablegen um dann später gezielt auf diesen Timerablauf reagieren zu können.

Hintergrund:
Der Wecker im Schlafzimmer geht morgens um 6 Uhr an
nach 30min schaltet er den WohnzimmerPlayer hinzu und setzt einen Sleeptimer auf 1h
wenn dieser Sleeptimer abgelaufen ist, soll er das Wohnzimmer wieder aus der Gruppe entfernen, aber nur, wenn genau dieser Sleeptimer abgelaufen ist.

Dann muss man doch den Wert von  {ReadingsVal  ("Sonos_Schlafzimmer","SleepTimerVersion",0)} in einer globalen Variablen speichern um es in dem notify " Sonos_Schlafzimmer:SleepTimer.*off " verwenden zu können, oder kann man das geschickter lösen?

Danke und Gruß,
Christian.

[JoeALLb]

Grüß euch,

nach einem Reboot des OS hat auch mein fhem wieder sauber gestartet und ich hatte seit gestern auch keine aussetzer mehr.
Auch mein Wecker mit der Kalenderintegration hat wieder funktioniert ohne Änderung an der Config.

Sehr schön   

[Reinerlein]

Hi Christian,

ich würde einfach direkt auf das 'off' des Readings 'Sleeptimer' reagieren. An einem Player kann es ja nur einen Sleeptimer geben, der auch nirgendwo gespeichert wird. Deswegen ist mit dem Ablauf des Timers die Version auch immer wieder 0 (also genau in dem Augenblick, wenn das 'off' Event ausgelöst wirfd)

Du kannst aber auch auf "nicht off" reagieren, und dir ausrechnen, wann der Timer fertig sein wird (die Zeitangabe mit dem Readingstimestamp verrechnen).

Das Reading mit der Versionsnummer ist eher intern wichtig, da ich es zum Vergleich heranziehe, wenn ein SleepTimer-Event von Sonos kommt... Die Zahl ändert sich zum Beispiel, wenn du während des Timerlaufs diesen wieder veränderst (also eine Zeit setzt)...

Zu den Reaktionszeiten: Bei mir dauert der Aufruf der Weboberfläche oft sehr lange. Wenn ich dann einmal drauf bin, geht es eine Zeitlang völlig normal. Alles andere wird aber trotzdem normalschnell ausgeführt (bei mir wird beim Start des Connect der zugehörige Verstärker eingeschaltet, das passiert trotzdem normal, was bedeutet, das sowohl der Fhem-Kern, als auch das Sonos-Modul und der FS20-Infrarotsender normal laufen).

@Joe: Super, dann hoffen wir mal, das meine Anpassungen dauerhaften Erfolg bringen

Grüße
Reiner

[djhans]

Hi Reiner,
danke für die Info.
Vielleicht ist mein Ansatz falsch. Ich nutze die Alarm-Funktion von Sonos immer in Kombination mit dem Sleeptimer, da die Sleeptimer Funktion die Mucke sanft ausblendet und nicht einfach abschaltet. Deshalb steht der Sonos-Weck-Alarm auch immer auf "unbegrenzt" und wird nach dem Aktivieren von fhem durch einen Sleeptimer abgelöst.

Wenn ich nun auf "Sonos_Schlafzimmer:SleepTimer.*off" reagiere, um damit z.B. das Wohnzimmer-Gerät von einer Gruppe zu trennen, dann passiert das natürlich mit jedem Alarm, der vom Schlafzimmer ausgelöst wird. Um das gezielt steuern zu können, dachte ich an die SleepTimerVersion.

Da fällt mir gerade ein:
Man könnte sich ja auch die AlarmID in einer Variablen merken, bevor der Sleeptimer gesetzt wird. So könnte man dann auf den richtigen "SleepTimer.*off"  reagieren. Oder besteht die Möglichkeit, den "Alarm" langsam auszublenden, wenn er abläuft. Dann hätte man den gleichen Effekt erzielt. Der SleepTimer hat allerdings den Vorteil, dass die Restlaufzeit am Controller angezeigt wird. Beim Alarm geht das nicht...

Christian

[djhans]

Hallo,
da ist gerade wieder ein Absturz passiert: Das wurde auf der debian Konsole ausgegeben.

Code Auswählen Erweitern

2014.02.13 16:38:34 3: SONOS1: ProxyObject does not exists
2014.02.13 16:38:34 2: SONOS1: Error during UPnP-Handling, restarting handling:                                                            junk 'Type>
    ' after XML element

CPU Last liegt bei 99%
..und das steht als letztes im fhem log.

Code Auswählen Erweitern

2014.02.13 16:35:19 3: [STV] defined with host: 192.168.1.5 port: 52235 MAC:
2014.02.13 16:35:19 1: Including ./log/fhem.save
2014.02.13 16:35:20 1: statefile: Reading Sonos_Bad->LastActionResult must not be used out of statefile.
Christian

[JoeALLb]

Kurze Rückfrage dazu:
Welchen Logdevice hast Du?
Mir ist gerade bei einem test aufgefallen, dass das Sonos-Modul mit  DBlog und Mysql als DB-backend auf kleiner Hardware nicht möglich ist.
Wenn ich hier Sonos exclude, funktioniert es wieder.

[herman]

Hallo,

ich gehöre ja auch zu den Sonos-Modul Anwendern, die die Sonos-Geräte hinter Funksteckdosen verwenden. Mein System (aktuelles FHEM, aktuelle DEV-Version vom Sonos-Modul) stürzt ca. 1 bis 2x am Tag.

Ich habe mein mit dem attribut event-on-change-reading .* die Performance deutlich optimiert. Ich hatte das Problem, dass die Verbindung zum HMLAN verloren ging.

Mit APPTIME messe ich nun die Aktivitäten auf FHEM. Hier ein Beispiel mit einmaligem Einschalten von 2 Sonos-Geräten und dem Starten von einem Sonos-Favoriten und anschließendem Stopp nach einer Minute und Ausschalten des Systems, wobei das Sonos-Log auf Stufe 5 steht:

Code Auswählen Erweitern


                                name             function    max  count    total  average maxDly
                              HMLAN1           HMLAN_Read   9429   2914   134866    46.28      0 HASH(0x141bd10)
                               Sonos           SONOS_Read   7591     39    63212  1620.82      0 HASH(0x1acdf38)
                   batteryUebersicht readingsGroup_Notify    356   2349    36034    15.34      0 HASH(0x1adf8d0); HASH(0x22d6010)
                   HeizungUebersicht readingsGroup_Notify    226   2349    15949     6.79      0 HASH(0x1a80d40); HASH(0x18d2858)
                       EZ_Licht_Tuer          notify_Exec   9278      3    12046  4015.33      0 HASH(0x19e8a30); HASH(0x1a4c570)
            tmr-YAMAHA_AVR_GetStatus      HASH(0x19e9330)   6003    463     9036    19.52   8094 HASH(0x19e9330)
                         tmr-at_Exec      HASH(0x24021d8)   5381      1     5381  5381.00      5 HASH(0x24021d8)
                                 WEB               FW_Set    587     14     3990   285.00      0 HASH(0x11ac870); WEB; rereadicons
                            WEBphone               FW_Set    617     14     3832   273.71      0 HASH(0x12e1fe8); WEBphone; rereadicons
                           WEBtablet               FW_Set    583     14     3718   265.57      0 HASH(0x12e2180); WEBtablet; rereadicons
                               Media            dummy_Set   1669     59     3674    62.27      0 HASH(0x19d6a10); Media; off
                        Media_Change          notify_Exec   1646      3     3596  1198.67      0 HASH(0x19d6c20); HASH(0x19d6a10)
                           SonosPlay            dummy_Set   1432     60     2197    36.62      0 HASH(0x19d7558); SonosPlay; on
                         SonosPlayOn          notify_Exec   1381      3     2014   671.33      0 HASH(0x19d7660); HASH(0x19d7558)
              tmr-FW_closeOldClients                          15    232     1254     5.41   2330
                 tmr-HMLAN_KeepAlive     keepAlive:HMLAN1     12    555     1130     2.04   5308 keepAlive:HMLAN1
                              WZ_AVR       YAMAHA_AVR_Set    170     65      959    14.75      0 HASH(0x19e9330); WZ_AVR; off
                  FileLog_WZ_Heizung          FileLog_Get    776      2      955   477.50      0 HASH(0x19e7900); FileLog_WZ_Heizung; CURRENT; INT; 2014-02-13_00:00:00; 2014-02-14_00:00:01; 4:T\x3a:0:; 6:H\x3a:0:
                                CUL1             CUL_Read    578      4      932   233.00      0 HASH(0x1398eb0)
                               WZ_TV               IT_Set    347     57      692    12.14      0 HASH(0x19e3928); WZ_TV; on
                                CUL1              CUL_Get    342      2      683   341.50      0 HASH(0x1398eb0);  ; raw; is000000000F11


Vorhin hatte ich einen Absturz, da Stand das Log noch nicht auf 5, weshalb ich keine Infos habe, jedoch war die CPU-Auslastung seitens FHEM sehr hoch und der Sonos-Thread nicht mehr unter den Prozessen aufgeführt.

Deshalb habe ich das Log auf 5 gesetzt und beobachte weiter.

Grüße,
Merhan

[Reinerlein]

Hallo zusammen,

das ist ja alles etwas ärgerlich...
Ich habe in der aktuellen Dev-Version noch ein bißchen an der Bilder Aktualisierung für FhemWeb gedreht. Das geht jetzt mit viel weniger Aufwand und Belastung für Fhem...

Vielleicht hilft das ja wieder ein bißchen...

Grüße
Reiner

[djhans]

Hi Reiner,
Besten Dank! Ich werde berichten.....

Christian

[herman]

Hallo Reiner,

vielen Dank für Deine Mühen. Ich denke wir wissen das alle zu schätzen!

Leider war heute früh der Loglevel nicht auf 5 gestellt. Ich hatte wieder folgende Situation auf der Version von gestern Abend:

Code Auswählen Erweitern


2014.02.14 09:06:53 3: SONOS1: Event: Received Transport-Event for Zone "Sonos_Schlafzimmer".
2014.02.14 09:06:53 3: SONOS1: Event: End of Transport-Event for Zone "Sonos_Schlafzimmer".
2014.02.14 09:07:09 3: SONOS1: Event: Received Transport-Event for Zone "Sonos_Schlafzimmer".
2014.02.14 09:07:09 3: SONOS1: Event: End of Transport-Event for Zone "Sonos_Schlafzimmer".
2014.02.14 09:07:17 3: SONOS1: Event: Received Transport-Event for Zone "Sonos_Schlafzimmer".
2014.02.14 09:07:17 3: SONOS1: Event: End of Transport-Event for Zone "Sonos_Schlafzimmer".
2014.02.14 09:07:45 3: SONOS1: Event: Received Transport-Event for Zone "Sonos_Schlafzimmer".
2014.02.14 09:08:49 2: SONOS1: Error during UPnP-Handling: 500 Can't connect to 192.168.3.18:1400 (Die Wartezeit für die Verbindung ist abgelaufen) at FHEM/lib/UPnP/ControlPoint.pm line 799 thread 1

2014.02.14 09:12:08 3: SONOS1: UPnP-Thread wurde beendet.



FHEM hängt und der Sonos-Thread ist nicht mehr da.

Ich schraube noch Mal das Log hoch. Vielleicht erkennst Du aber auch schon was dran. Gestern Abend und heute früh lief alles ohne Probleme. Steckdosen einschalten, 3 Min warten, gruppieren, abspielen etc. Kurz nach 09:00 wurde das System ausgeschaltet. Seit wann FHEM hängt, weiß ich nicht.

Viele Grüße,
Merhan

[herman]

So mit Log-Level 5 verabschiedet sich irgendwann mein HM-LAN

Code Auswählen Erweitern


2014.02.14 10:35:30 4: SONOS0: DoWorkAnswer arrived for Sonos_Schlafzimmer->LastActionResult: 'DoWork-Exception ERROR: 500 Can't connect to 192.168.3.18:1400 (Keine Route zum Zielrechner) at FHEM/lib/UPnP/ControlPoint.pm line 799 thread$
2014.02.14 11:32:04 1: 192.168.3.11:1000 disconnected, waiting to reappear
2014.02.14 11:32:04 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.02.14 11:32:04 1: 192.168.3.11:1000 reappeared (HMLAN1)
2014.02.14 11:32:04 1: HMLAN_Parse: HMLAN1 new condition init


Bei diesem Scenario hängt FHEM aber der Sonos-Thread läuft noch.
Ich habe mein System stark aufgeräumt und deutlich weniger events auf die reagiert wird. Kann es sein, dass das Sonos-Modul aufgrund von Timeouts das FHEM etwas lahmt, wenn die Funksteckdosen aus sind -sprich die Lautsprecher nicht über das Netzwerk erreichbar?

Könnte ich testweise an eine zentrale Stelle im Sonos-Modul eine Zeile Code einbauen, die dafür sorgt, dass das Sonos-Modul nichts macht, wenn eine bestimmte Steckdose aus ist.

Vielen Dank & Grüße,
Merhan

[Reinerlein]

Hallo Merhan,

ich habe die "can't connect to"-Meldung nun auch so aufgenommen, dass das UPnP-Handling automatisch wieder angestartet wird. Das sorgt also in Zukunft nicht mehr für ein Ende des SubProzesses.

Bezogen auf das Eingreifen an eine zentralen Stelle: Im Normalfall macht das Modul nichts mehr mit den als abwesend erkannten Playern. Das ganze ist ja ein Event-System, sodass zunächst mal nur reagiert wird. Zusätzlich gibt es einen Thread, der die Player in regelmäßigen Abständen anpingt, um festzustellen, ob diese noch anwesend sind. Wird dort festgestellt, dass der Player endgültig weg ist, so wird dieser als "disappeared" markiert, und wird auch zukünftig nicht mehr überprüft werden...
Von dort aus sollte also nix mehr passieren...

Das einzige Problem können dann noch Zugriffe aus Fhem heraus auf den Player sein. Das sollte zwar eigentlich auch abgesichert sein, kann aber natürlich auch mal schiefgehen bzw. bei der Programmierung übersehen worden sein...

Zum HMLAN: Der wird bereits nach 30 Sekunden als disconnected geführt. Das kann da also noch nicht so lange her sein. Nun ist zwischen dem letzten Sonos-Log und dieser disconnected Nachricht ja fast eine Stunde vergangen, sodass ich da nicht unbedingt einen ursächlichen Zusammenhang sehen würde.
Was mich aber ein bißchen wundert, ist das Dollar-Zeichen am Ende der DoWorkAnswer-Zeile. Dort sollte vermutlich noch etwas kommen, da ich die zu schreibende Meldung in einfachen Anführungsstrichen (') ausgebe. Wie man ja vor dem Wort "DoWork-Exception ERROR" sehen kann, geht es damit auch los, nur hinten fehlt das...
Vielleicht ist aber auch genau das das Problem: Er kann die Meldung nicht in das Reading "LastActionResult" eintragen, weil ihn irgendein Sonderzeichen oder die Länge o.ä. stört...
Oder ist das beim pasten hier im Forum einfach nicht mitgekommen?

Grüße
Reiner

[JoeALLb]

Grüß Euch,

@Reiner: Wäre es möglich, für Sonos ebenfalls ein Disabled-Attribut wie aus anderen Modulen bekannt, zu haben?
Manchmal wäre das schöner als das ganze Sonos aus der Config zu löschen....

Anmerken wollte ich noch, dass ich auch einen HMLAN verwende. Mir ist bisher nie ein Zusammenhang aufgefallen, jedoch stelle ich soeben fest,
dass zu den ketzten 2 Zeitpunkten, als ich hänger hatte, über hmlan nichts mehr geloggt wurde. Über ein anderes System (LaCrosse) wurde
weitergeloggt... seltsam.

[CQuadrat]

Hallo Zusammen,

mal ein ganz anderes Thema:
Auf den SONOS-Geräten läuft doch auch ein Linux. Kommt man da irgendwie drauf? Wenn ja, wäre es doch interessant darauf die FHEM-Installation laufen zu lassen, wenn möglich.

Gut, ist vielleicht jetzt eine andere Baustelle...


Viele Grüße

Christoph