Problem mit Sonos-Alarm Aktualisierung

Begonnen von aski71, 27 Dezember 2018, 20:17:21

Vorheriges Thema - Nächstes Thema

aski71

Hallo zusammen,

ich habe mir ein Dummy Device "Wecker" gebaut, mit dem ich kombiniert den Sonos-Wecker und den Hue-Wecker aus- und einschalten kann.
Das funktioniert auch ziemlich gut, bis auf die Statusausgabe.

Der State meines Dummy Devices wird mittels eines Skripts (99_myUtil...)gesetzt, das den Zustand der Hue Schedules und des Sonos Weckers in Readings packt und daraus einen Status generiert. Sind alle Wecker an: "on". Sind alle Wecker aus: "off". Ist es ein Mischzustand: "mixed".

Der Sonos-Weckerzustand wird wiefolgt geschrieben:

my $sonosSZenabled = eval(ReadingsVal("Sonos_Schlafzimmer","AlarmList","{}"))->{1}->{Enabled};
fhem "setreading Wecker sonosSZenabled $sonosSZenabled";


Klicke ich auf das devStateIcon, wird ein "on" oder "off" Event ausgelöst. Über ein notify wird dann ein Skript (99_myUtil...) gestartet, das alle Hue Schedules und den Sonos Wecker ein-/ausschaltet. Dies passiert mittels:


fhem "set Sonos_Schlafzimmer Alarm $sonosToggle 1";


Am Ende dieses Skripts wird das obige Skript aufgerufen, das nun die Readings im Dummy Device Wecker aktualisiert.

So weit so gut, funktioniert das auch alles. Ich sehe in der Alarmlist im Sonos-Device, dass der Zustand erfolgreich umgeschaltet wurde.

Allerdings:
Im Dummy Device Wecker wird das Reading nicht korrekt aktualisiert.
Beispiel:
Alle Wecker werden über das Dummy Device Wecker ausgeschaltet -> Im Sonos Device sieht man, dass der Wecker aus ist -> Im Dummy Device steht, dass er immer noch an ist.
Im Anschluss werden alle Wecker über das Dummy Device Wecker wieder eingeschaltet -> Im Sonos Device sieht man, dass der Wecker wieder an ist -> Im Dumm Device steht: Er ist aus.
Ruft man dann das Skript zur Aktualisierung nochmal händisch auf, wird der Zustand richtig gesetzt.

Ich hielt das zunächst für ein Laufzeitproblem und habe die Statusaktualisierung mit einem Sleep verzögert: Fehlanzeige. Löst das Problem nicht.
Dann habe ich die Statusaktualisierung zweimal hintereinander aus dem Skript gestartet: Fehlanzeige. Löst das Problem nicht.
Auch ein Sleep zwischen der ersten und der zweiten Statusaktualisierung löst das Problem nicht.
Die einzige Möglichkeit ist: Statusaktualisierung händisch nochmal starten, bzw. nochmal die gleiche Ein-/Ausschaltung durchführen.

Hat jemand eine Idee, wie ich das beheben kann?

Danke, Alex

Otto123

Hallo Alex,

ich habe nicht alles verstanden was Du beschrieben hast. Aber meine Gedanke geht in die Richtung:
https://commandref.fhem.de/commandref_DE.html#setreading
ZitatAchtung: setreading generiert kein Event für ein Gerät X, falls es aus einem notify für Gerät X aufgerufen wurde. In so einem Fall könnte man auf "sleep 0.1; setreading X Y Z" ausweichen.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

aski71

Danke, Otto. Der Sachverhalt ist tatsächlich etwas schwer zu erklären.  :D

Das Problem ist nicht, dass kein Event generiert wird.
Das Problem ist, dass


my $sonosSZenabled = eval(ReadingsVal("Sonos_Schlafzimmer","AlarmList","{}"))->{1}->{Enabled};
fhem "setreading Wecker sonosSZenabled $sonosSZenabled";


das falsche Ergebnis liefert:

Obwohl im Sonos-Device in der AlarmList "Enabled" schon umgestellt worden ist, liefert $sonosSZenabled immer noch den alten Wert zurück.

Der Ablauf ist quasi:
Im ersten Skript wird ein Befehl ausgeführt, der "Enabled" zwischen 0 und 1 hin und her toggelt.
Aus diesem Skript wird dann ein anderes Skript aufgerufen, das mittels obigen Zeilen den aktuellen Wert für "Enabled" ausliest und ihn dann in das Reading schreibt.
Und das liest den alten Wert aus, egal wie lange ich "sleep"en lasse.
Nur wenn ich das Skript im Anschluss händisch starte, wird der richtige Wert für "Enabled" ausgelesen und ins Reading geschrieben.

Otto123

Moin,

da auch kein Anderer eine Idee hat: Ich kann das gedanklich nicht nachvollziehen und zum nachstellen fehlt mir aktuell die Muße. Ich empfehle Dir: bau ein paar Log Ausgaben in Deinen Scripts damit Du nachvollziehen kannst was an welcher Stelle und Reihenfolge passiert.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

aski71

Hab ich schon. :-)
Es geht genau an der Stelle schief, an der $sonosSZenabled gesetzt wird.
Die Abfrage liefert den falschen Wert, obwohl der richtige Wert in Alarmlist steht.
Wenn ich danach das Skript nochmal händisch aufrufe, wird der richtige Wert zurück geliefert.

Otto123

Da ich zu wenig Perl kann, verstehe ich schon deine Abfrage nicht.
Deine Abfrage klappt auch bei mir in keinem Fall! Also nicht wenn 'Enabled' => '1' nicht wenn 'Enabled' => '0' und auch nicht wenn die Alarmliste leer ist!
Ich denke deine Scripts verwurschteln da was - aber sicher bin ich nicht!

Ich würde es so machen. Als Test für die FHEM Kommandozeile. Liefert 1 wenn Enabled und 0 in jedem anderen Fall
{ReadingsVal("Sonos_Kueche","AlarmList","")=~m/'Enabled' => '1'/ ? 1 : 0}

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

aski71

Die Abfrage habe ich aus einem anderen Thread, in dem detailliert erforscht wurde, wie man 'Enabled' raus operiert.  :)
Wenn das bei Dir nie ein richtiges Ergebnis liefert, könnte es sein, dass Du in Deiner Alarmlist für das Sonos-Gerät keinen Alarm mit der ID 1 hast.
Das 'eval' liefert einen Hash zurück. Diesen kann man dann hinabsteigen: <hash>->{<AlarmID>}->{<parameter innerhalb der AlarmID>}
In meinem Fall wird also der Wert für Enabled innerhalb der AlarmID 1 zurück geliefert.

Ich bin auch nicht wahnsinnig tief in Perl und verstehe Deine Abfrage nicht ganz.
Aber ich interpretiere, dass Du in der AlarmList nach 'Enabled' suchst und auf 1 prüfst. Danach lieferst Du in Abhängigkeit 1 oder 0 zurück.
Das funktioniert aber nur, wenn es nur ein einziges Enabled gibt. Sobald mehrere Alarme definiert sind, gibt es aber mehrere Enabled. Und da gilt es, auf das richtige Enabled zuzugreifen.

Mich verwirrt bei meiner Abfrage immer noch:
Wird aus dem Skript der Sonos-Alarm von 0 auf 1 gestellt und danach abgefragt, liefert die Abfrage weiterhin 0, obwohl ich in Fhem sehe, dass da beim Device 1 steht.
Frage ich zeiteverzögert oder mehrmals aus dem Skript ab, bleibt der Wert bei 0.
Rufe ich das gleiche Abfrageskript nach einem Durchlauf nochmal händisch auf, kommt der richtige Wert 1.

Otto123

Das mit den mehreren Alarmen klingt logisch, aber: Ich habe ein Sonos Device mit einem Alarm in der Liste (steht schon ewig dort und wird nie benutzt)
{'4' => {'Recurrence_Saturday' => 1,'Repeat' => 1,'Recurrence_Sunday' => 1,'Recurrence_Monday' => 0,'Volume' => '21','Recurrence_Wednesday' => 0,'Recurrence_Tuesday' => 0,'Recurrence_Thursday' => 0,'RoomUUID' => 'RINCON_000E58F42D5201400','ProgramURI' => 'x-sonosapi-stream:s1472?sid=254&flags=32','Duration' => '01:00:00','Recurrence_Once' => 0,'ProgramMetaData' => '<DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:r="urn:schemas-rinconnetworks-com:metadata-1-0/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"><item id="R:0/0/9" parentID="R:0/0" restricted="true"><dc:title>Relax FM</dc:title><upnp:class>object.item.audioItem.audioBroadcast</upnp:class><desc id="cdudn" nameSpace="urn:schemas-rinconnetworks-com:metadata-1-0/">SA_RINCON65031_</desc></item></DIDL-Lite>','Enabled' => '0','Shuffle' => 0,'Recurrence_Friday' => 0,'IncludeLinkedZones' => '1','StartTime' => '08:00:00'}}
Ich verstehe wie gesagt die Abfrage nicht (sagt aber nichts) aber ich verstehe auch den Inhalt nicht.
Fakt ist: geht bei mir nicht.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

aski71

Deine Alarm ID ist 4. Um den Wert von Enabled bei Dir aus dem Hash zu bekommen, musst Du also die 1 durch die 4 ersetzen. :-)


my $sonosSZenabled = eval(ReadingsVal("Sonos_Schlafzimmer","AlarmList","{}"))->{4}->{Enabled};


Dann steht der Wert von Enabled in der Variable $sonosSZenabled.

Die anderen Parameter beschreiben im Prinzip, wann der Alarm ausgelöst wird, wie oft er wiederholt wird, was abgespielt wird, für wie lange, etc. etc.

Hoffe nach wie vor, dass sich noch jemand findet, der meinem Problem auf die Schlicht kommt...

Otto123

Gut so funktioniert es bei mir auch.
ZitatWird aus dem Skript der Sonos-Alarm von 0 auf 1 gestellt und danach abgefragt, liefert die Abfrage weiterhin 0, obwohl ich in Fhem sehe, dass da beim Device 1 steht.
Frage ich zeiteverzögert oder mehrmals aus dem Skript ab, bleibt der Wert bei 0.
Klingt für mich nach wie vor danach, das die Abfrage irgendwas anderes abfragt. So wie Du es jetzt schreibt klingt es nach "Cache" Es wird der zwischengespeicherte Wert immer wieder gelesen ohne den echten Wert neu einzulesen. Wenn du es per Hand machst kommst Du aus einem anderen "Speicher"

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

aski71

Sowas habe ich gedanklich auch schon gemutmaßt.
Aber: Was soll das für ein Cache sein?
Und wie umgeht man ihn?

aski71

Ich habe es jetzt mit dem Gedanken eines Caches wiefolgt lösen können:

1) Die Abfrage auf den aktuellen Sonos-Alarmstatus und den aktuellen Hue Alarmstatus aus dem Skript heraus genommen und in ein eigenes Skript gesteckt.
2) Ein Notify gebaut, das Änderungen von "AlarmList" in meinem Sonos Device überwacht und dann das Abfrageskript aufruft.

Voila: Funktioniert.

Otto123

Naja dann hat doch das gemeinsame Nachdenken was gebracht  8)

Guten Rutsch
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

aski71