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.

Darstellung der Beispiel-Konfiguration

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 eine 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 "aufgewacht 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

bettfein machen: Lichtszene setzen, Chillout Musik in Schlafzimmer und Badezimmer abspielen

schlafen legen: Ansage der eingestellten Weckzeit & Ausschalten aller Verbraucher

aufgewacht 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 aufgewacht?

Schaltung bei erstem Bewohner, der geweckt wird

Schaltung bei erstem Bewohner, der aufgewacht 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 Weckverhalten 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 wakeupEnforce 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 täglich zur angegebenen Weckzeit statt; unabhängig davon, ob das Weckprogramm tatsächlich gestartet wird. Dies kann man auf bestimmte Tage einschränken. Wenn wir also beispielsweise am Freitag Abend bereits die Weckzeit für nächsten Montag einstellen, möchten wir nicht, dass diese am Samstag oder Sonntag wieder zurückgesetzt wird.

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 wakeupEnforce 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

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 die for-Schleife am Anfang des Macros gedacht und deckt per Default 10 Arbeitsschritte ab (ansonsten einfach die Zahl entsprechend erhöhen).

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 der for-Schleife wird immer ausgeführt. Sie 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. Dadurch wird das aufräumen oben im Macro einfacher.
• 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 "bettfein machen"

Möchte der Bewohner nun ins Bett gehen und sich dabei noch etwas darauf einstimmen, kann er sein "bettfein 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 "aufgewacht 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-Peak auf zukünftige Erweiterungen ;-)).