Sonos Player disappeared

[aski71]

Hallo zusammen,

ich habe nicht nur das Problem, dass meine Sonos regelmäßig auf disappeared gehen.
Seit kurzem ist es auch so, dass das alle fhem-Seiten (incl. Floorplan), auf denen sich Sonos-Elemente (z.B. ReadingGroups mit den Favoriten) befinden auf allen iOS Geräten blockiert sind. Diese Raumseiten, bzw. der floorplan, wird nicht geladen. Die Fortschrittsanzeige des Browsers bleibt auf der Hälfte hängen.
Wer hat Rat?

VG Alex

[gestein]

Hallo,

ich habe das selbe. Sonos geht immer wieder auf "disappeared".
Zur Zeit funktioniert die Lösung von Networker aus #70.
Ich habe nur das Wort "disabled" durch "disappeared" ersetzt.

Warum allerdings zweimal das "(set Sonos RescanNetwork)" ausgeführt wird, verstehe ich noch nicht ganz.
Ansonsten funktioniert es bei mir.
Ich muss nur schauen, ob das auf Dauer eine Lösung ist.

lg, Gerhard

[aski71]

Kann mir mal jemand bitte die Syntax dieser Zeile erklären?

Code Auswählen Erweitern


defmod di_SonosWatchdog DOIF ([Sonos] eq "disabled")(attr Sonos disable 1)(deleteattr Sonos disable)(set Sonos RescanNetwork)(set Sonos RescanNetwork)DOELSE


Ich habe dazu folgende Fragen:

1) Ein DOELSE am Ende einer Zeile stellt meine komplette Programmierkenntnis auf den Kopf. Ich würde erwarten, dass ein DOELSE ausgeführt wird, wenn die Bedingung von DOIF nicht zutritt. Dazu müsste aber doch hinter dem DOELSE stehen, was getan werden soll?! Was hat das hier für eine Bewandtnis?

2) Warum wird zweimal ein RescanNetwork durchgeführt?

Danke!

[aski71]

Hallo,

ich habe das selbe. Sonos geht immer wieder auf "disappeared".
Zur Zeit funktioniert die Lösung von Networker aus #70.
Ich habe nur das Wort "disabled" durch "disappeared" ersetzt.

Warum allerdings zweimal das "(set Sonos RescanNetwork)" ausgeführt wird, verstehe ich noch nicht ganz.
Ansonsten funktioniert es bei mir.
Ich muss nur schauen, ob das auf Dauer eine Lösung ist.

lg, Gerhard

Also, bei mir funktionierte die Lösung aus #70 gar nicht und ich habe das jetzt durchanalysiert, warum:

1) das SonosStatus at-Modul setzt ein Reading myStatus. Abgeprüft wird im DOIF aber  nur [Sonos]. Also das state. Dann kann man im Zweifel warten, bis man schwarz wird.
2) im DOIF muss also [Sonos:myStatus] abgefragt werden.
3) Das wiederum liefert nur ein Event, wenn im Sonos-Device 'myStatus' im event-on-change-reading oder event-on-update-reading angegeben ist.
4) Das hat bei mir alles trotzdem nix genutzt. Erst als ich das DOIF mit 'define' statt 'defmod' definiert hatte, ging es.
5) Das DOELSE am Schluss kann man sich sparen, wenn man keine Befehle mehr dahinter schreibt. Vielleicht wollte der Originalautor aber aus irgendeinem Grund "DOELSE (set Sonos RescanNetwork)" machen und hat es versehentlich falschherum gemacht. Das würde auch die beiden (set Sonos RescanNetwork) hintereinander erklären. Nach meinem Verständnis ist (im Zusammenspiel mit dem do always) gemeint: Auch, wenn das Sonos Device nicht abgestürzt ist, mach trotzdem einen Rescan des Sonos Netzwerks. Ich hab das bei mir jetzt weg gelassen.

Meine Variante sieht jetzt so aus:

Code Auswählen Erweitern

define SonosStatus at +*00:05:00 sleep 0.1;; setreading Sonos myStatus [Sonos:state]


und

Code Auswählen Erweitern

define di_SonosWatchdog DOIF ([Sonos:myStatus] eq "disabled")(attr Sonos disable 1)(deleteattr Sonos disable)(set Sonos RescanNetwork)
attr di_SonosWatchdog checkReadingEvent 1
attr di_SonosWatchdog do always
attr di_SonosWatchdog wait 0,20,60,60

und am Sonos Device

Code Auswählen Erweitern

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

So läuft es jetzt.
Optimierungpotenzial wäre aus meiner Sicht, das SonosStatus Device wegzulassen, im Watchdog ':myStatus' wegzulassen, weil durch das 'event-change-reading state' im Sonos Device eigentlich der Watchdog schon mitkriegen müsste, wenn sich das Sonos Device disabled.

Werde ich mal ausprobieren.

Wie das bei Dir mit "disappeared" funktionieren kann, ist mir ein Rätsel, weil: Das Sonos Haupdevice geht nie auf disappeared. Sondern auf disabled. Jedenfalls bei mir. 

[THZ_Haus]

Hallo
zu Antwort #75
Bei mir ist das selbe problem vorhanden.
Auf iOS Geräten werde Seiten (Floorplan) von Sonos Device nicht mehr angezeigt.
Die "ladeuhr" verschwindet  nicht mehr.

Eine Lösung weiß ich leider auch nicht!

[hoppel118]

Hallo Leute,

auch bei mir gibt es sporadisch immer wieder den state "disabled" am "Sonos" Device. Mal dauert es einen Tag, mal eine Woche und ich habe keine Ahnung, wie ich das zugrunde liegende Problem analysieren/lösen kann. Wenn da jemand eine Idee hat, immer her damit.

Also, bei mir funktionierte die Lösung aus #70 gar nicht und ich habe das jetzt durchanalysiert, warum:

1) das SonosStatus at-Modul setzt ein Reading myStatus. Abgeprüft wird im DOIF aber  nur [Sonos]. Also das state. Dann kann man im Zweifel warten, bis man schwarz wird.
2) im DOIF muss also [Sonos:myStatus] abgefragt werden.
3) Das wiederum liefert nur ein Event, wenn im Sonos-Device 'myStatus' im event-on-change-reading oder event-on-update-reading angegeben ist.
4) Das hat bei mir alles trotzdem nix genutzt. Erst als ich das DOIF mit 'define' statt 'defmod' definiert hatte, ging es.
5) Das DOELSE am Schluss kann man sich sparen, wenn man keine Befehle mehr dahinter schreibt. Vielleicht wollte der Originalautor aber aus irgendeinem Grund "DOELSE (set Sonos RescanNetwork)" machen und hat es versehentlich falschherum gemacht. Das würde auch die beiden (set Sonos RescanNetwork) hintereinander erklären. Nach meinem Verständnis ist (im Zusammenspiel mit dem do always) gemeint: Auch, wenn das Sonos Device nicht abgestürzt ist, mach trotzdem einen Rescan des Sonos Netzwerks. Ich hab das bei mir jetzt weg gelassen.

Meine Variante sieht jetzt so aus:

Code Auswählen Erweitern

define SonosStatus at +*00:05:00 sleep 0.1;; setreading Sonos myStatus [Sonos:state]


und

Code Auswählen Erweitern

define di_SonosWatchdog DOIF ([Sonos:myStatus] eq "disabled")(attr Sonos disable 1)(deleteattr Sonos disable)(set Sonos RescanNetwork)
attr di_SonosWatchdog checkReadingEvent 1
attr di_SonosWatchdog do always
attr di_SonosWatchdog wait 0,20,60,60

und am Sonos Device

Code Auswählen Erweitern

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

So läuft es jetzt.

Hallo @aski71

danke das du die angepasste Lösung hier bereitgestellt hast. Diese funktioniert nun auch bei mir.

Wofür benötigt man im DOIF "set Sonos RescanNetwork"?

Im Wiki steht folgendes dazu:

RescanNetwork: Startet die Erkennung der im Netzwerk vorhandenen Player erneut.

Ist das nicht Bestandteil des normalen Startvorgangs des Moduls? Also wenn im DOIF "deleteattr Sonos disable" ausgeführt wird...

Optimierungpotenzial wäre aus meiner Sicht, das SonosStatus Device wegzulassen, im Watchdog ':myStatus' wegzulassen, weil durch das 'event-change-reading state' im Sonos Device eigentlich der Watchdog schon mitkriegen müsste, wenn sich das Sonos Device disabled.

Werde ich mal ausprobieren.

Ohne diesen Thread zu kennen, hatte ich ein eigenes DOIF entwickelt. Dieses wurde aber nicht getriggert, wenn der "state" des Devices "Sonos" auf "disabled" gewechselt ist. Das war ja anscheinend dein Optimierungspotential. Hattest du das mal ausprobiert?

Code Auswählen Erweitern

define di_Sonos_Reload DOIF ([Sonos:state] eq "disabled")
  (attr Sonos disable 1)(deleteattr Sonos disable)(set Hoppels_WhatsApp send Sonos Zentrale: automatically enabled by DOIF)
attr di_Sonos_Reload do always
attr di_Sonos_Reload wait 0,60,60

• Kann mir jemand sagen, warum meine Lösung nicht funktioniert? (Hängt das mit dem fehlenden "attr Sonos event-on-change-reading state" zusammen? Wenn ja, warum funktionieren andere DOIFs, die auf "state" triggern auch ohne "event-on-change-reading state"?)
• Warum kann mein DOIF nicht auf "state" von meinem "Sonos" Device triggern?
• Warum klappt es mit dem at in der von @aski71 beschriebenen Lösung?

Ich möchte das einfach gern verstehen. Bisher brauchte ich bei meinen DOIFs kein at, damit sie funktionieren.


Danke euch und Gruß Hoppel

[hoppel118]

Ich habe es nun nochmal wie folgt getestet:

Code Auswählen Erweitern

define di_Sonos_Reload DOIF ([Sonos] eq "disabled")
  (attr Sonos disable 1)(deleteattr Sonos disable)(set Hoppels_WhatsApp send Sonos Zentrale: automatically enabled by DOIF)
attr di_Sonos_Reload checkReadingEvent 1
attr di_Sonos_Reload do always
attr di_Sonos_Reload wait 0,60,60

Code Auswählen Erweitern

attr Sonos event-on-change-reading state

Vorhin gegen 20 Uhr ist das Problem erneut aufgetreten. Das DOIF hat nicht gegriffen.

Woran kann das liegen, dass das DOIF nicht getriggert wird?

Viele Grüße Hoppel

[sTaN]

Hallo liebe Community,

auch ich muss mich leider den täglichen disappear-Nachrichten anschließen. Zuletzt gestern Nacht um 00:32 Uhr

Ich habe bereits diverse Forenbeiträge durchforstet und verschiedenste Lösungensvorschläge versucht. Bisher leider ohne Erfolg. Den zuletzt hier im Beitrag beschriebenen Workaround mit DOIF di_Sonos_Reload werde ich noch probieren aber mir stellt sich nach wie vor die Frage, wo die wirkliche Ursache des Problems liegt?

Ich habe auch mein Netzwerk u.a. bestehend aus einem Unifi Acess AP-Pro komplett auf den Kopf gestellt. Es gab hier sogar eine neue Option, mit der man Multicast und Broadcast Traffic blocken und den ARP Timeout erhöhen konnte. Da ich auch dbzgl. so einiges gelesen habe.

Kann hier Reinerlein als Entwickler des Moduls vielleicht noch mal eine konkrete Zusammenfassung liefern oder konkrete Anweisungen geben, wie wir bei der Fehlersuche unterstützen können? Ich habe großes Interesse, dass die Sonos Player stabil laufen, da wir die Steuerung primär über unser Tablet an der Wand machen und leider mit jedem Abbruch die Steuerung nicht mehr funktioniert.

Aktuell sieht mein Sonos device wie folgt aus:

Code Auswählen Erweitern

Internals:
   DEF        127.0.0.1:4711 120 1 5
   DELAYTIME  5
   DeviceName 127.0.0.1:4711
   FUUID      XXXXXXXXXXXXXXXXXXXXXXXX
   INTERVAL   120
   NAME       Sonos
   NOTIFYDEV  global
   NR         107
   NTFY_ORDER 50-Sonos
   STATE      disabled
   TYPE       SONOS
   WAITTIME   1
   READINGS:
     2020-04-07 20:34:04   AllPlayer       ['Sonos_Bad','Sonos_Buero','Sonos_Kueche','Sonos_Schlafzimmer','Sonos_Wohnzimmer']
     2020-04-07 20:34:04   AllPlayerCount  5
     2020-04-07 20:34:04   AllPlayerNotBonded ['Sonos_Bad','Sonos_Buero','Sonos_Kueche','Sonos_Schlafzimmer','Sonos_Wohnzimmer']
     2020-04-07 20:34:04   AllPlayerNotBondedCount 5
     2020-04-14 00:24:02   LastProcessAnswer 1586816642
     2020-04-14 00:32:07   LastProcessRestart 2020-04-14 00:32:07
     2020-04-14 00:32:07   LastProcessRestartCount 38
     2019-01-10 17:07:54   LineInPlayer    []
     2020-04-08 11:49:01   LineInPlayerList
     2020-04-08 11:49:01   LineInPlayerListAlias
     2020-04-13 12:04:22   MasterPlayer    ['Sonos_Bad','Sonos_Buero','Sonos_Kueche','Sonos_Schlafzimmer','Sonos_Wohnzimmer']
     2020-04-13 12:04:22   MasterPlayerCount 5
     2020-04-13 13:34:50   MasterPlayerNotPlaying ['Sonos_Bad','Sonos_Buero','Sonos_Kueche','Sonos_Schlafzimmer','Sonos_Wohnzimmer']
     2020-04-13 13:34:50   MasterPlayerNotPlayingCount 5
     2020-04-13 13:34:50   MasterPlayerPlaying []
     2020-04-13 13:34:50   MasterPlayerPlayingCount 0
     2020-04-04 16:17:01   MusicServicesList {XXXXXX --> falls relevant bitte Info}
     2020-04-04 16:17:01   MusicServicesListVersion RINCON_XXXXXXXXX:343
     2019-01-10 17:08:19   ShareIndexInProgress 0
     2019-07-28 16:26:20   UserID_Spotify  SXXXXXXXXX
     2020-04-13 17:47:52   ZoneGroupState  XXXXXXXXXX
     2020-04-14 00:32:08   state           disabled
Attributes:
   SubProcessLogfileName sonoslog
   getFavouritesListAtNewVersion 1
   getListsDirectlyToReadings 1
   getPlaylistsListAtNewVersion 1
   getQueueListAtNewVersion 1
   getRadiosListAtNewVersion 1
   ignoredIPs 192.168.XXX.XXX,192.168.XXX.XXX
   pingType   tcp
   reusePort  1
   room       Sonos
   verbose    5

Ich habe den gestrigen Absturz um 00:32 Uhr auch über verbose 5 in einem separaten Log aufgezeichnet. Hier der Auszug kurz vor dem Abbruch und Neustart von FHEM erfolgte um 22:14 Uhr:

Code Auswählen Erweitern

2020.04.14 00:25:58 4: SONOS1: SONOS_Client_Data_Retreive(RINCON_XXXXXXXXX_MR, def, NAME, RINCON_XXXXXXXXX_MR) -> Sonos_Wohnzimmer
2020.04.14 00:25:58 4: SONOS1: SONOS_Client_Data_Retreive(RINCON_XXXXXXXXX_MR, attr, disable, 0) -> DEFAULT
2020.04.14 00:25:58 3: SONOS1: Event: Received Alarm-Event for Zone "Sonos_Wohnzimmer".
2020.04.14 00:28:02 5: SONOS0: Received: 'DoWork:undef:refreshProcessAnswer:'
2020.04.14 00:28:02 4: SONOS1: SONOS_Client_Notifier(rePing:undef::)
2020.04.14 00:30:02 5: SONOS0: Received: 'DoWork:undef:refreshProcessAnswer:'
2020.04.14 00:30:02 4: SONOS1: SONOS_Client_Notifier(rePing:undef::)
2020.04.14 00:32:07 5: SONOS0: Received: 'DoWork:undef:refreshProcessAnswer:'
2020.04.14 00:32:07 4: SONOS1: SONOS_Client_Notifier(rePing:undef::)
2020.04.14 00:32:08 5: SONOS0: Received: 'shutdown'
2020.04.14 00:32:08 3: SONOS0: Disconnecting client and shutdown server...
2020.04.14 00:32:08 3: SONOS0: Trying to kill Sonos_Thread...
2020.04.14 00:32:08 3: SONOS0: Trying to kill LongJobs_Thread...
2020.04.14 00:32:08 3: SONOS0: Trying to kill IsAlive_Thread...
2020.04.14 00:32:08 3: SONOS0: Trying to kill PlayerRestore_Thread...
2020.04.14 00:32:08 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...
2020.04.14 22:14:21 5: SONOS0: Received:

Ich hoffe sehr es gibt hierfür eine nachhaltige Lösung.

Griß
sTaN

[Wuppi68]

Hallo liebe Community,

auch ich muss mich leider den täglichen disappear-Nachrichten anschließen. Zuletzt gestern Nacht um 00:32 Uhr

Ich habe bereits diverse Forenbeiträge durchforstet und verschiedenste Lösungensvorschläge versucht. Bisher leider ohne Erfolg. Den zuletzt hier im Beitrag beschriebenen Workaround mit DOIF di_Sonos_Reload werde ich noch probieren aber mir stellt sich nach wie vor die Frage, wo die wirkliche Ursache des Problems liegt?

Ich habe auch mein Netzwerk u.a. bestehend aus einem Unifi Acess AP-Pro komplett auf den Kopf gestellt. Es gab hier sogar eine neue Option, mit der man Multicast und Broadcast Traffic blocken und den ARP Timeout erhöhen konnte. Da ich auch dbzgl. so einiges gelesen habe.

Kann hier Reinerlein als Entwickler des Moduls vielleicht noch mal eine konkrete Zusammenfassung liefern oder konkrete Anweisungen geben, wie wir bei der Fehlersuche unterstützen können? Ich habe großes Interesse, dass die Sonos Player stabil laufen, da wir die Steuerung primär über unser Tablet an der Wand machen und leider mit jedem Abbruch die Steuerung nicht mehr funktioniert.

Aktuell sieht mein Sonos device wie folgt aus:

Code Auswählen Erweitern

Internals:
   DEF        127.0.0.1:4711 120 1 5
   DELAYTIME  5
   DeviceName 127.0.0.1:4711
   FUUID      XXXXXXXXXXXXXXXXXXXXXXXX
   INTERVAL   120
   NAME       Sonos
   NOTIFYDEV  global
   NR         107
   NTFY_ORDER 50-Sonos
   STATE      disabled
   TYPE       SONOS
   WAITTIME   1
   READINGS:
     2020-04-07 20:34:04   AllPlayer       ['Sonos_Bad','Sonos_Buero','Sonos_Kueche','Sonos_Schlafzimmer','Sonos_Wohnzimmer']
     2020-04-07 20:34:04   AllPlayerCount  5
     2020-04-07 20:34:04   AllPlayerNotBonded ['Sonos_Bad','Sonos_Buero','Sonos_Kueche','Sonos_Schlafzimmer','Sonos_Wohnzimmer']
     2020-04-07 20:34:04   AllPlayerNotBondedCount 5
     2020-04-14 00:24:02   LastProcessAnswer 1586816642
     2020-04-14 00:32:07   LastProcessRestart 2020-04-14 00:32:07
     2020-04-14 00:32:07   LastProcessRestartCount 38
     2019-01-10 17:07:54   LineInPlayer    []
     2020-04-08 11:49:01   LineInPlayerList
     2020-04-08 11:49:01   LineInPlayerListAlias
     2020-04-13 12:04:22   MasterPlayer    ['Sonos_Bad','Sonos_Buero','Sonos_Kueche','Sonos_Schlafzimmer','Sonos_Wohnzimmer']
     2020-04-13 12:04:22   MasterPlayerCount 5
     2020-04-13 13:34:50   MasterPlayerNotPlaying ['Sonos_Bad','Sonos_Buero','Sonos_Kueche','Sonos_Schlafzimmer','Sonos_Wohnzimmer']
     2020-04-13 13:34:50   MasterPlayerNotPlayingCount 5
     2020-04-13 13:34:50   MasterPlayerPlaying []
     2020-04-13 13:34:50   MasterPlayerPlayingCount 0
     2020-04-04 16:17:01   MusicServicesList {XXXXXX --> falls relevant bitte Info}
     2020-04-04 16:17:01   MusicServicesListVersion RINCON_XXXXXXXXX:343
     2019-01-10 17:08:19   ShareIndexInProgress 0
     2019-07-28 16:26:20   UserID_Spotify  SXXXXXXXXX
     2020-04-13 17:47:52   ZoneGroupState  XXXXXXXXXX
     2020-04-14 00:32:08   state           disabled
Attributes:
   SubProcessLogfileName sonoslog
   getFavouritesListAtNewVersion 1
   getListsDirectlyToReadings 1
   getPlaylistsListAtNewVersion 1
   getQueueListAtNewVersion 1
   getRadiosListAtNewVersion 1
   ignoredIPs 192.168.XXX.XXX,192.168.XXX.XXX
   pingType   tcp
   reusePort  1
   room       Sonos
   verbose    5

Ich habe den gestrigen Absturz um 00:32 Uhr auch über verbose 5 in einem separaten Log aufgezeichnet. Hier der Auszug kurz vor dem Abbruch und Neustart von FHEM erfolgte um 22:14 Uhr:

Code Auswählen Erweitern

2020.04.14 00:25:58 4: SONOS1: SONOS_Client_Data_Retreive(RINCON_XXXXXXXXX_MR, def, NAME, RINCON_XXXXXXXXX_MR) -> Sonos_Wohnzimmer
2020.04.14 00:25:58 4: SONOS1: SONOS_Client_Data_Retreive(RINCON_XXXXXXXXX_MR, attr, disable, 0) -> DEFAULT
2020.04.14 00:25:58 3: SONOS1: Event: Received Alarm-Event for Zone "Sonos_Wohnzimmer".
2020.04.14 00:28:02 5: SONOS0: Received: 'DoWork:undef:refreshProcessAnswer:'
2020.04.14 00:28:02 4: SONOS1: SONOS_Client_Notifier(rePing:undef::)
2020.04.14 00:30:02 5: SONOS0: Received: 'DoWork:undef:refreshProcessAnswer:'
2020.04.14 00:30:02 4: SONOS1: SONOS_Client_Notifier(rePing:undef::)
2020.04.14 00:32:07 5: SONOS0: Received: 'DoWork:undef:refreshProcessAnswer:'
2020.04.14 00:32:07 4: SONOS1: SONOS_Client_Notifier(rePing:undef::)
2020.04.14 00:32:08 5: SONOS0: Received: 'shutdown'
2020.04.14 00:32:08 3: SONOS0: Disconnecting client and shutdown server...
2020.04.14 00:32:08 3: SONOS0: Trying to kill Sonos_Thread...
2020.04.14 00:32:08 3: SONOS0: Trying to kill LongJobs_Thread...
2020.04.14 00:32:08 3: SONOS0: Trying to kill IsAlive_Thread...
2020.04.14 00:32:08 3: SONOS0: Trying to kill PlayerRestore_Thread...
2020.04.14 00:32:08 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...
2020.04.14 22:14:21 5: SONOS0: Received:

Ich hoffe sehr es gibt hierfür eine nachhaltige Lösung.

Griß
sTaN

ich habe den Kampf mit meinen Sonos Playern aufgegeben. Als letztes Mittel habe ich sogar einen Raspberry in mein Media VLAN mit dem Sonos UPNP Server gesetzt und auch dieser hat die Verbindung immer wieder verloren. Da ich primär nur noch die Sonos ein und wieder ausschalte bin ich auf sonos2mqtt gewechselt. Dort habe bis dato keinerlei Ausfälle die ich nicht selber verschuldet habe

[hoppel118]

Moin,

bei mir funktioniert die von @aski71 beschriebene Variante bestehend aus einem at um einem DOIF hervorragend, siehe meinen vorletzten Beitrag.

Ich kann mir nicht erklären, warum das reine DOIF in meinem letzten Beitrag nicht funktioniert, obwohl ich das eigentlich lieber nutzen würde.

Kannst ja mal berichten.

Gruß Hoppel

[TomLee]

warum das reine DOIF in meinem letzten Beitrag nicht funktioniert

Ohne es selbst getestet zu haben, meine Vermutung:

attr <DOIF-module> wait <Sekunden für Befehlsfolge des ersten DO-Falls>:<Sekunden für Befehlsfolge des zweiten DO-Falls>:...

Was du mit Komma machst, sind Verzögerungen innerhalb eines Klammerblocks.

Nimm mal Doppelpunkte

Code Auswählen Erweitern

attr di_Sonos_Reload wait 0:60:60

Gruß

Thomas

[hoppel118]

Ohne das jetzt ausprobiert zu haben, habe ich nochmal ins Wiki geschaut. Da habe ich auch deinen Code-Block gefunden. Direkt darunter steht folgendes:

Sollen Verzögerungen innerhalb von Befehlsfolgen stattfinden, so müssen diese Kommandos in eigene Klammern gesetzt werden, das Modul arbeitet dann mit Zwischenzuständen.

Beispiel: Bei einer Befehlssequenz, hier: (set lamp1 on, set lamp2 on), soll vor dem Schalten von lamp2 eine Verzögerung von einer Sekunde stattfinden. Die Befehlsfolge muss zunächst mit Hilfe von Klammerblöcke in eine Befehlssequenz aufgespalten werden: (set lamp1 on)(set lamp2 on). Nun kann mit dem wait-Attribut nicht nur für den Beginn der Sequenz, sondern für jeden Klammerblock eine Verzögerung, getrennt mit Komma, definieren werden, hier also: wait 0,1. Damit wird lamp1 sofort, lamp2 eine Sekunde danach geschaltet. Die Verzögerungszeit bezieht sich immer auf den vorherigen Befehl.

Demnach sind meine Kommas richtig.

Die zeitliche Abfolge der einzelnen Befehle ist auch gar nicht das Problem. Das DOIF wird erst gar nicht getriggert, wenn ,,Sonos" in den Status ,,disabled" wechselt. Weitere Ideen?

Gruß Hoppel

[TomLee]

Dann zitiere ich mal noch die komplette Commandref zu Verzögerungen 
Wiki hab ich nich nachgeschaut.

Verzögerungen

Verzögerungen für die Ausführung von Kommandos werden pro Befehlsfolge über das Attribut "wait" definiert. Syntax:

attr <DOIF-module> wait <Sekunden für Befehlsfolge des ersten DO-Falls>:<Sekunden für Befehlsfolge des zweiten DO-Falls>:...

Sollen Verzögerungen innerhalb von Befehlsfolgen stattfinden, so müssen diese Kommandos in eigene Klammern gesetzt werden, das Modul arbeitet dann mit Zwischenzuständen.

Beispiel: Bei einer Befehlssequenz, hier: (set lamp1 on, set lamp2 on), soll vor dem Schalten von lamp2 eine Verzögerung von einer Sekunde stattfinden. Die Befehlsfolge muss zunächst mit Hilfe von Klammerblöcke in eine Befehlssequenz aufgespalten werden: (set lamp1 on)(set lamp2 on). Nun kann mit dem wait-Attribut nicht nur für den Beginn der Sequenz, sondern für jeden Klammerblock eine Verzögerung, getrennt mit Komma, definieren werden, hier also: wait 0,1. Damit wird lamp1 sofort, lamp2 eine Sekunde danach geschaltet. Die Verzögerungszeit bezieht sich immer auf den vorherigen Befehl.

Beispieldefinition bei mehreren DO-Blöcken mit Befehlssequenzen:

DOIF (Bedingung1)
(set ...) ## erster Befehl der ersten Sequenz soll um eine Sekunde verzögert werden
(set ...) ## zweiter Befehl der ersten Sequenz soll um 2 Sekunden nach dem ersten Befehl verzögert werden
DOELSEIF (Bedingung2)
(set ...) ## erster Befehl der zweiten Sequenz soll um 3 Sekunden verzögert werden
(set ...) ## zweiter Befehl der zweiten Sequenz soll um 0,5 Sekunden nach dem ersten Befehl verzögert werden

attr <DOIF-module> wait 1,2:3,0.5

Das Aufspalten einer kommagetrennten Befehlskette in eine Befehlssequenz, wie im obigen Beispiel, sollte nicht vorgenommen werden, wenn keine Verzögerungen zwischen den Befehlen benötigt werden. Denn bei einer Befehlssequenz werden Zwischenzustände cmd1_1, cmd1_2 usw. generiert, die Events erzeugen und damit unnötig FHEM-Zeit kosten.

Für Kommandos, die nicht verzögert werden sollen, werden Sekundenangaben ausgelassen oder auf Null gesetzt. Die Verzögerungen werden nur auf Events angewandt und nicht auf Zeitsteuerung. Eine bereits ausgelöste Verzögerung wird zurückgesetzt, wenn während der Wartezeit ein Kommando eines anderen DO-Falls, ausgelöst durch ein neues Ereignis, ausgeführt werden soll.

Statt Sekundenangaben können ebenfalls Status, Readings in eckigen Klammern, Perl-Funktionen sowie Perl-Berechnung angegeben werden. Dabei werden die Trennzeichen Komma und Doppelpunkt in Klammern geschützt und gelten dort nicht als Trennzeichen. Diese Angaben können ebenfalls bei folgenden Attributen gemacht werden: cmdpause, repeatcmd, repeatsame, waitsame, waitdel

Beispiel:

attr my_doif wait 1:[mydummy:state]*3:rand(600)+100,Attr("mydevice","myattr","")

[TomLee]

Nimm alles zurück, hast Recht, mach zu selten was mit DOIF (wie mit homebridge).

Aber definiert hatte ich auch mal eins, dass nicht wollte, aber welches jetzt genau weiß ich nicht mehr.

Bei mir hatte  ich das LGTV_WebOS-Modul ausgemacht als Verursacher für das disappearen.

[sTaN]

Bei mir hatte  ich das LGTV_WebOS-Modul ausgemacht als Verursacher für das disappearen.

Das ist mal interessant. Habe zwar nicht das LG Modul im Einsatz aber habe einen LG65 Zoll TV. Meinst du der UPnP Server könnte das Problem sein? Allerdings hatte ich extra die IP des TV mit im Attribut ignoredIPs gesetzt. Sodass er eigentlich schon nicht mehr reinfunken dürfte

EDIT: Wollte ihn setzen, habe es bisher aber wohl vergessen. [emoji85] Habe den LG TV jetzt mal auf ignorieren gesetzt.