Weckautomation
Die Module ROOMMATE und GUEST können dazu genutzt werden, Bewohner und Gäste in FHEM als ein Device zu repräsentieren und durch Events deren Status zu erfassen bzw. zu ändern (beispielsweise durch das GEOFANCY Modul für Anwesenheitserkennung). Das zur Modulfamilie dazugehörige Modul RESIDENTS fasst die Status mehrerer Bewohner logisch zusammen.
Inzwischen unterstützen die Module auch bei der Erstellung einer Weckautomation, indem sie die Logik kapseln und häufig verwendete Standardfunktionen bereitstellen. Die Verwendung soll in diesem Artikel anhand eines Beispiels näher erläutert werden.
Was soll erreicht werden?
Hier ein kurzer Überblick über die Funktionen, die wir am Ende realisiert haben werden:
- 3 unterschiedliche Wecker
- 1 für Werktage Mo-Fr
- 1 für werktägliche Samstage
- 1 für Sonn- und Feiertage
- Automatischer Reset der Weckzeiten
- werktäglicher Wecker soll auf einen Standardwert zurückstellen, falls er mal verstellt wurde
- automatischer Reset des werktäglicher Weckers soll zeitweise abschaltbar sein
- nach einem Sonn- oder Feiertagen soll der automatische Reset des werktäglichen Weckers immer wieder eingeschaltet werden
- die Samstags- und Sonntags-Wecker sollen immer nach ihrer Ausführung resettet werden
- jeder Wecker startet ein Weckprogramm 30 Minuten vor der programmierten Zeit
- langsames hochfahren der Rollläden
- Wakeup Light über eine HUE Birne von Warmweiß/2000K zu Kaltweiß/5600K
- an Werktagen: Chillout Weckmusik wird langsam lauter gestellt
- Snooze Funktion über die SONOS Taste am Gerät an Werktagen (erneutes Play nach 5 Minuten)
- forciertes Aufstehen an Werktagen durch automatischen Wechsel des Bewohner Devices zu "awake" und dadurch starten der "aufgestanden sein" Prozesse (siehe unten)
- Starten des Weckprogramms nur bei tatsächlicher Anwesenheit des betroffenen Bewohners
- Ansage der Uhrzeit zur gewählten Weckzeit
- Prozess / Automation für
- bettfertig machen: Lichtszene setzen, Chillout Musik in Schlafzimmer und Badezimmer abspielen
- schlafen legen: Ansage der eingestellten Weckzeit & Ausschalten aller Verbraucher
- aufgestanden sein: Ansage Raumluftqualität, Wettervorhersage; Lokalradio einschalten und in Räume verteilen; Küchenlicht an, HUE in Schlafzimmer mit Aufwach-Farbtemperatur
- Berücksichtigung / Steuerung des Haus Modus
- Wechsel zwischen Morgen-, Tag-, Abend- und Nacht-Modus entsprechend der Schlafgewohnheiten (zusätzlich zur Tageszeit abhängigen Steuerung/Umschaltung, die hier aber nicht Thema sein soll)
- Statuswerte, Events, Readings und Funktionen
- Wurde ein Wecker ausgelöst?
- Ist gerade ein Weckprogramm aktiv?
- Abbrechen/sofortiges beenden des Weckprogramms
- Verhindern von durch Fehlkonfiguration parallel ausgeführten Weckern für die selbe Person
- Welcher ist der nächste Wecker, der bis Mitternacht des nächsten Tages ausgeführt wird und wann ist das?
- Wann wurde ein Wecker zuletzt ausgeführt und welcher Wecker wurde überhaupt zuletzt ausgeführt?
- Wie viele Bewohner werden gerade geweckt?
- Wie viele Bewohner sind gerade aufgestanden?
- Schaltung bei erstem Bewohner, der geweckt wird
- Schaltung bei erstem Bewohner, der aufgestanden ist
- Statistik
- Wie lange dauerte der Schlaf des Bewohners?
- Wie lange war in dem Haus niemand wach?
Wichtig dabei zu erwähnen ist, dass die Prozesse so umgesetzt worden sind, dass Bewohner sowohl zeitgleich, als auch zeitversetzt oder komplett getrennt ins Bett gehen und aufwachen können. Dafür werden einige Schaltungen pro Bewohner und dessen Schlafzimmer vorgenommen und andere erst dann, wenn die RESIDENTS Bewohnergruppe einen bestimmten Status erreicht hat.
Notwendige Devices anlegen
RESIDENTS und ROOMMATE Devices
Wir starten mit einem RESIDENTS Device, um die Bewohner Status später logisch zusammenfassen zu können:
define rgr_Bewohner RESIDENTS
Anschließend legen wir pro Bewohner ein ROOMMATE Device an. Dafür verwenden wir eine Funktion, die in RESIDENTS eingebaut ist und die Devices korrekt untereinander verbindet (die Reihenfolge, in der RESIDENTS und ROOMMATE/GUEST Geräte definiert werden, sind hier entscheidend). Der Einfachheit halber definieren wir in diesem Beispiel nur einen Bewohner.
set rgr_Bewohner addRoommate Julian
Es wurde nun automatisch ein Device namens "rr_Julian" angelegt (abgeleitet aus dem angegebenen Vornamen aus dem addRoommate Befehl). Anschließend setzen wir einmalig den initialen Status für die Bewohner mittels set Befehl:
set rr_Julian home
Der automatische Wechsel des Status bei Anwesenheit/Abwesenheit wird hier nicht weiter thematisiert, hier sei auf den Artikel Anwesenheitserkennung verwiesen, insbesondere den GEOFANCY Teil.
Wecker Devices anlegen
Die Devices, über die die Weckzeit und das Auslöseverhalten eingestellt werden, sind eigentlich normale Dummy Devices. Das zugewiesene ROOMMATE/GUEST/RESIDENTS Device "versklavt" diese Geräte jedoch und führt bestimmte Befehle zur Wecksteuerung und -Verwaltung aus, sobald das Dummy-Device geändert wird. Der Vorteil dabei ist, dass man sich eine Menge eigenen Code und viele unterschiedliche Notify und Dummy Devices spart, was wiederum der Übersichtlichkeit zu Gute kommt.
Wir legen nun unsere drei Wecker für unseren Beispiel Bewohner an. Dafür führen wir einfach 3 mal den selben Befehl hintereinander aus:
set rr_Julian create wakeuptimer set rr_Julian create wakeuptimer set rr_Julian create wakeuptimer
In der Logdatei erscheinen verschiedene Meldungen über alle automatisch angelegte Devices inkl. Name und Typ:
2015.03.28 12:19:49 3: RESIDENTStk rr_Julian_wakeuptimer1: new notify macro device Macro_rr_Julian_wakeuptimer1 created 2015.03.28 12:19:50 3: RESIDENTStk rr_Julian_wakeuptimer1: new at-device at_rr_Julian_wakeuptimer1 created 2015.03.28 12:19:50 3: RESIDENTStk rr_Julian_wakeuptimer1: new macro device Macro_rr_Julian_gotosleep created 2015.03.28 12:19:50 3: RESIDENTStk rr_Julian_wakeuptimer1: new watchdog device wd_rr_Julian_gotosleep created 2015.03.28 12:19:50 3: RESIDENTStk rr_Julian_wakeuptimer1: new macro device Macro_rr_Julian_asleep created 2015.03.28 12:19:50 3: RESIDENTStk rr_Julian_wakeuptimer1: new watchdog device wd_rr_Julian_asleep created 2015.03.28 12:19:50 3: RESIDENTStk rr_Julian_wakeuptimer1: new macro device Macro_rr_Julian_awoken created 2015.03.28 12:19:50 3: RESIDENTStk rr_Julian_wakeuptimer1: new watchdog device wd_rr_Julian_awoken created 2015.03.28 12:19:50 3: RESIDENTStk rr_Julian_wakeuptimer1: new macro device Macro_rgr_Bewohner_gotosleep created 2015.03.28 12:19:50 3: RESIDENTStk rr_Julian_wakeuptimer1: new watchdog device wd_rgr_Bewohner_gotosleep created 2015.03.28 12:19:50 3: RESIDENTStk rr_Julian_wakeuptimer1: new macro device Macro_rgr_Bewohner_asleep created 2015.03.28 12:19:50 3: RESIDENTStk rr_Julian_wakeuptimer1: new watchdog device wd_rr_Julian_asleep created 2015.03.28 12:19:50 3: RESIDENTStk rr_Julian_wakeuptimer1: new macro device Macro_rgr_Bewohner_awoken created 2015.03.28 12:19:51 3: RESIDENTStk rr_Julian_wakeuptimer1: new watchdog device wd_rr_Julian_awoken created 2015.03.28 12:21:49 3: RESIDENTStk rr_Julian_wakeuptimer2: new notify macro device Macro_rr_Julian_wakeuptimer2 created 2015.03.28 12:21:49 3: RESIDENTStk rr_Julian_wakeuptimer2: new at-device at_rr_Julian_wakeuptimer2 created 2015.03.28 12:21:56 3: RESIDENTStk rr_Julian_wakeuptimer3: new notify macro device Macro_rr_Julian_wakeuptimer3 created 2015.03.28 12:21:56 3: RESIDENTStk rr_Julian_wakeuptimer3: new at-device at_rr_Julian_wakeuptimer3 created
Als Rückgabe in FHEMWEB erhält man eine Meldung wie diese hier:
Dummy rr_Julian_wakeuptimer1 and other pending devices created and pre-configured. You may edit Macro_rr_Julian_wakeuptimer1 to define your wake-up actions and at_rr_Julian_wakeuptimer1 for optional at-device adjustments.
Wie man sieht wurden anfänglich eine ganze Menge von Notify-Macros und Watchdogs sowie ein at-Device pro Wecker angelegt. Dabei sind vor allem die Macro-Devices und die Wecker Dummy Devices interessant. Hier werden Weck- und Auslöseverhalten konfiguriert. die at- und Watchdog-Devices können aber für fortgeschrittene Nutzer beliebig angepasst werden. Auch die Dummy Devices können bis auf wenige Ausnahmen (Attribut "userattr") vollständig umkonfiguriert werden. Wer Devices umbenennt, sollte unbedingt darauf achten, dass auch das entsprechende Attribut im Wecker-Dummy-Device angepasst wird.
Allen Devices ist ein entsprechender Kommentar hinzugefügt, der dessen Funktion kurz erklärt. Alle Macros enthalten bereits ein Gerüst für den Weckprozess mit einigen Beispielen. Die Beispielschaltungen sind dabei noch auskommentiert. Nicht auskommentierter Code sollte als notwendiger Teil für die Weckautomation betrachtet werden und wird dort auch durch einen entsprechenden Kommentar erklärt.
Im Folgenden werden wir jetzt Schritt für Schritt das oben beschriebene Szenario konfigurieren.
Konfiguration des Auslöseverhaltens
In der Grundkonfiguration löst jeder Wecker sein eigenes Weckprogramm täglich zur voreingestellten Zeit aus. Dabei wird allerdings kein längeres Programm gestartet, sondern lediglich einmalig das im Attribut wakeupMacro hinterlegte Notify-Macro getriggert. Das ist in der Beispiel-Grundkonfiguration kein Problem und lässt lediglich einen Logfile Eintrag erstellen.
Als erstes möchten wir, dass alle 3 Timer das selbe Macro zum Wecken verwenden, damit wir den Code nur einmal pflegen müssen. Die anderen beiden Macros löschen wir anschließend:
attr rr_Julian_wakeuptimer2 wakeupMacro Macro_rr_Julian_wakeuptimer1 attr rr_Julian_wakeuptimer3 wakeupMacro Macro_rr_Julian_wakeuptimer1 delete Macro_rr_Julian_wakeuptimer2 delete Macro_rr_Julian_wakeuptimer3
Nun konfigurieren wir die Auslöseverhalten so, wie wir es oben vorgegeben haben:
Wake-up Timer 1
Wecker nur Mo-Fr auslösen:
attr rr_Julian_wakeuptimer1 wakeupDays 1,2,3,4,5
Wecker zusätzlich auf Tage beschränken, die keine Feiertage sind:
attr rr_Julian_wakeuptimer1 wakeupHolidays andNoHoliday
Hinweis: Hierfür muss ein holiday-Device erstellt sein und in der global Config im Attribut 'holidays2we‘ verlinkt sein. Ansonsten erhält man beim setzen einer Weckzeit später entsprechende Fehlermeldungen, die darauf hinweisen.
Länge des Weckprogramms auf 30 Minuten festlegen (sprich 30 Minuten vor der eingestellten Weckzeit beginnen):
attr rr_Julian_wakeuptimer1 wakeupOffset 30
Aufstehen forcieren:
attr rr_Julian_wakeuptimer1 wakeupEnforced 1
Standard Weckzeit hinterlegen:
attr rr_Julian_wakeuptimer1 wakeupDefaultTime 07:30
Weckzeit nur an diesen Tagen automatisch zurückstellen:
attr rr_Julian_wakeuptimer1 wakeupResetdays 1,2,3,4,5
Hinweis: Ein Reset findet normalerweise nach jeder Auslösung statt, sprich wenn das Weckprogramm tatsächlich gestartet wurde. Dies kann man auf bestimmte Tage einschränken.
Zum einfacheren Aktivieren/Deaktivieren des Resets wollen wir ein weiteres Dummy nutzen:
attr rr_Julian_wakeuptimer1 wakeupResetSwitcher rr_Julian_wakeuptimer1_resetswitcher
Hinweis: Der Dummy-Gerätename kann frei gewählt werden. Sofern es nicht existiert wird es automatisch angelegt und vorkonfiguriert.
Wake-up Timer 2
Wecker nur Samstags auslösen:
attr rr_Julian_wakeuptimer2 wakeupDays 6
Wecker zusätzlich auf Tage beschränken, die keine Feiertage sind:
attr rr_Julian_wakeuptimer2 wakeupHolidays andNoHoliday
Länge des Weckprogramms auf 30 Minuten festlegen (sprich 30 Minuten vor der eingestellten Weckzeit beginnen):
attr rr_Julian_wakeuptimer2 wakeupOffset 30
Aufstehen forcieren:
attr rr_Julian_wakeuptimer2 wakeupEnforced 1
Standard Weckzeit hinterlegen:
attr rr_Julian_wakeuptimer2 wakeupDefaultTime 09:30
Weckzeit nur an diesen Tagen automatisch zurückstellen:
attr rr_Julian_wakeuptimer2 wakeupResetdays 6
Wake-up Timer 3
Wecker nur Sonntags auslösen:
attr rr_Julian_wakeuptimer3 wakeupDays 0
Wecker zusätzlich auch an Feiertagen ausführen:
attr rr_Julian_wakeuptimer3 wakeupHolidays orHoliday
Aufstehen nur forcieren, wenn eine frühere Weckzeit als die Standard Weckzeit eingestellt wurde:
attr rr_Julian_wakeuptimer3 wakeupEnforced 3
Länge des Weckprogramms auf 30 Minuten festlegen (sprich 30 Minuten vor der eingestellten Weckzeit beginnen):
attr rr_Julian_wakeuptimer3 wakeupOffset 30
Standard Weckzeit hinterlegen:
attr rr_Julian_wakeuptimer3 wakeupDefaultTime 10:30
Definition des Weckprogramms
Die Aktionen, welche innerhalb der 30 Minuten Weckzeitraum abgearbeitet werden sollen, sind im Device Macro_rr_Julian_wakeuptimer1 hinterlegt. Dieses Macro wird 2 Mal aufgerufen: Das erste Mal beim Beginn des Weckprogramms und ein zweites Mal beim Ende des Weckprogramms. Der Hintergrund ist, dass das Macro beim Beenden dann entsprechend dafür sorgen kann bisher nicht ausgeführte Befehle des Programmablaufes zu stornieren. Hierfür ist der delete-Befehl am Anfang des Macros gedacht.
Das Macro Template hat bereits alle oben beschriebenen Funktionen als auskommentierte FHEM Befehle enthalten. Diese sollen natürlich nur dem Beispiel und der eigenen Inspiration dienen. Wir müssten diese an dieser Stelle lediglich einkommentieren... Insgesamt fällt bei genauerem hinsehen folgendes auf:
- es stehen bestimmte Umgebungsvariablen bereit, die während des Programmablaufes genutzt werden können
- das Macro ist in 3 Bereiche unterteilt und nutzt dafür die Umgebungsvariable $EVTPART0 bzw. ob deren Wert auf "start" oder "stop" steht
- der erste Bereich mit dem delete-Befehl wird immer ausgeführt. Er räumt durch das Macro erzeugte temporäre at-Devices auf (entweder weil das Programm früher beendet werden soll oder von vorne beginnen soll)
- der zweite Bereich "start" führt erste FHEM Befehle direkt nach dem Beginn des Weckprogramms aus. Außerdem werden weitere Befehle in bestimmten Etappen zur zeitversetzten Ausführung vorgemerkt. Dafür werden temporär erzeugte at-Devices verwendet.
- der Name der at-Devices folgt einem bestimmten Schema, nämlich atTmp_<LAUFENDE-NUMMER>_$NAME. Die laufende Nummer muss man manuell hochzählen, der Rest kann einfach kopiert werden. Wenn man davon abweicht, muss man den delete-Befehl am Anfang auch anpassen.
- bei der Definition der at-Devices müssen mehrere FHEM Befehle hintereinander mit 2 Semikolon statt einem getrennt werden (siehe auch Kommando-Referenz).
- bei bedingten Schaltungen empfehlt es sich für übersichtlicheren Code die :FILTER Funktion zu nutzen (siehe auch Kommando-Referenz).
- es ist unbedingt darauf zu achten, dass das letzte at-Device nicht nach der wakeupOffset Zeit definiert wird, da es ansonsten automatisch gelöscht und somit nicht mehr ausgeführt wird
- nach einem ordentlichen Ende des Weckprogramms wird ein at-Device erzeugt, welches das Benutzer-Device automatisch nach "awoken" oder "home" schaltet, abhängig davon ob das Wecken forciert werden soll oder nicht. Dieser Teil wird tatsächlich nur geplant, wenn das Weckprogramm ordentlich beendet wurde. Wurde das Weckprogramm durch ein "set rr_Julian_wakeuptimer1 stop" bzw. durch Klick auf das blaue Device-Icon beendet, so werden die Post-Wakeup Befehle nicht mehr ausgeführt, weil man davon ausgehen kann, dass ein Abbruch des Programms und somit aller seiner weiteren Schaltungen gewünscht ist.
Man kann sein Weckprogramm auf zwei Arten testen:
- durch senden des set-Befehls "trigger": hier werden die aktuellen Auslösedefinitionen berücksichtigt; sprich, wenn heute nicht der richtige Tag ist, wird das Programm nicht gestartet
- durch senden des set-Befehls "start" kann man alle Auslösedefinitionen umgehen und das Weckprogramm direkt auslösen
Zu Debug-Zwecken kann man auf das Wecker Dummy-Device das Attribut "verbose" auf 4 setzen. Im Logfile wird dann sehr ausführlich geloggt, warum wie geschaltet oder nicht geschaltet wird und wie die Entscheidungen getroffen worden sind, Readings zu aktualisieren etc. Damit lässt sich prüfen, ob das gewünschte Auslöseverhalten tatsächlich richtig funktioniert.
Definition der Aktionen für den Prozess "bettfertig machen"
Möchte der Bewohner nun ins Bett gehen und sich dabei noch etwas darauf einstimmen, kann er sein "bettfertig machen"-Programm dadurch starten, dass er den Status seines ROOMMATE-Devices in FHEM auf "gotosleep" setzt. In unserem Beispiel werden dann die Aktionen aus Macro_rr_Julian_gotosleep ausgeführt.
Zeitgleich wird im RESIDENTS-Device rgr_Bewohner das Reading "residentsGotosleep" um 1 erhöht und ein Event erzeugt. Befinden sich gar alle anwesenden Bewohner im Status "gotosleep" wechselt der Gesamtstatus von rgr_Bewohner auch auf "gotosleep". Dies löst dann Macro_rgr_Bewohner_gotosleep aus. Dort werden dann Schaltungen vorgenommen, die von größerer Tragweite sind, als wenn nur ein einzelner Bewohner ins Bett geht. Beispielsweise könnte man in bestimmten Räumen das Licht oder Geräte ausschalten, die man ansonsten unberührt gelassen hätte, wenn andere noch wach blieben.
Definition der Aktionen für den Prozess "schlafen legen"
Legt sich der Bewohner ins Bett und möchte schlafen, wechselt er den Status seines ROOMMATE-Devices auf "asleep". Ich mache das bei mir durch einen extra Wandschalter.
In unserem Beispiel werden jetzt die Aktionen aus Macro_rr_Julian_asleep ausgeführt. In dem Macro wird besonders Wert darauf gelegt, dass ausschließlich Aktionen ausgeführt werden, die mit dem Schlafzimmer des Bewohners zu tun haben, damit andere Bewohner in anderen Räumen nicht beeinträchtigt werden.
Zeitgleich werden im RESIDENTS-Device rgr_Bewohner das Reading "residentsGotosleep" um 1 erniedrigt, das Reading "residentsAsleep" um 1 erhöht und ein Event erzeugt. Befinden sich gar alle anwesenden Bewohner im Status "asleep" wechselt der Gesamtstatus von rgr_Bewohner auch auf "asleep". Dies löst dann Macro_rgr_Bewohner_asleep aus. Dort werden dann auch wieder Schaltungen vorgenommen, die von größerer Tragweite sind. Beispielsweise werden alle noch übrigen Lichter im Haus ausgeschaltet und die Musikwiedergabe in Gemeinschaftsräumen (wie hier dem Badezimmer) gestoppt.
Definition der Aktionen für den Prozess "aufgestanden sein"
Wir gehen nun davon aus, dass irgendwann morgens das Weckprogramm wie oben zuvor definiert abgespielt wird. Dabei wechselt im Device rgr_Bewohner das Reading residentsTotalWakeup auf 1 (oder höher bei mehreren gleichzeitig aktiven Weckprogrammen unterschiedlicher Bewohner).
Während des Weckprogramms (oder natürlich auch davor) kann der Bewohner jederzeit in den Status "awoken" wechseln. Ich nutze bei mir auch hier wieder den Wandschalter. Dadurch wird ein evtl. noch laufendes Weckprogramm unterbrochen (die at-Devices in FHEM werden automatisch aufgräumt) und die Aktionen in Macro_rr_Julian_awoken werden ausgeführt.
Neben dem expliziten Wechsel zum Status "awoken" kann aber, wie oben beschrieben, auch das Weckprogramm selbst den Bewohner auf diesen Status setzen. Dies wird dann als forciertes Wecken bezeichnet; sozusagen um seinen Hintern aus dem Bett zu bewegen :-) Sinnvollerweise wechselt der Status des Bewohners nach kurzer Zeit dann automatisch von "awoken" auf "home", also den Standard-Status wenn man zuhause ist.
Zeitgleich zum Wechsel des ROOMMATE-Devices auf "awoken" wird auch wieder das RESIDENTS-Device automatisch angepasst: Das Reading "residentsAsleep" wird um 1 erniedrigt, das Reading "residentsAwoken" um 1 erhöht und ein Event erzeugt. Außerdem wird der Gesamtstatus auf "awoken" gesetzt. Dies löst Macro_rgr_Bewohner_awoken aus. Hier werden auch wieder Schaltungen vorgenommen, die das Haus dann für den ersten, der aufsteht, entsprechend einzustellen, also beispielsweise das Licht in der Küche einschalten. Zusätzlich wird dann ein temporäres at-Devices angelegt, welches dafür sorgt, dass der Haus Modus nach 1,5h von "Morgen" auf "Tag" wechselt. Allerdings ist der Haus Modus wie schon erwähnt hier nicht das Hauptthema und wird aktuell auch noch nicht direkt vom RESIDENTS Toolkit unterstützt (Sneak-Peek auf zukünftige Erweiterungen ;-)).
Snooze Funktion bei SONOS
Damit man an gewissen Tagen auch dem Wecker mal auf'n Kopp hauen kann (bzw. auf den Start/Stop Button am SONOS Gerät), kann man ein einfaches DOIF erzeugen, welches dafür sorgt, dass man nach 5 Minuten wieder daran erinnert wird aufzustehen:
define di_Sonos_Snooze DOIF ( [Sonos_Bedroom:?transportState] and ( ([rr_Julian:wakeup] == 0 and [rr_Julian:wakeup:sec] >= 600) or $we ) or ( ([rr_Julian:wakeup] == 0 and [rr_Julian:wakeup:sec] >= 600) or $we ) ) DOELSEIF ( [Sonos_Bedroom:?transportState] and ([Sonos_Bedroom:transportState] eq "STOPPED" or [Sonos_Bedroom:transportState] eq "PAUSED_PLAYBACK") and ([?rr_Julian:wakeup] == 1 or [rr_Julian:wakeup:sec] < 600) and !$we ) ( set Sonos_Bedroom:FILTER=transportState!=PLAYING Play ) DOELSE attr alias Automation: Sonos Snoozing attr cmdState off|on|standby attr comment snooze function for wake-up program via SONOS device button attr devStateIcon off:general_aus on:general_an@green standby:general_an@orange attr wait 0:300:0
Das DOIF hier greift nur während ein Weckprogramm läuft oder maximal noch 10 Minuten danach; zudem nur wochentags :-)
Außerdem zeigt der DOIF Status an, ob die Snooze Funktion gerade scharf geschaltet ist oder nicht.
Wichtig ist auch, dass das ROOMMATE Device ein Event bei der Änderung des wakeup Readings auslöst, also z.B. das Attribut event-on-change-reading dann entsprechend auch "wakeup" enthält.