RESIDENTS: Wakeup-Timer und offset

Begonnen von KernSani, 20 August 2016, 17:48:54

Vorheriges Thema - Nächstes Thema

KernSani

Hallo,

ich habe gerade ein wenig mit dem Wakeuptimer experimentiert. Eigentlich will ich folgendes erreichen:
* Ich stelle meinen Wecker auf 06:00 Uhr
* Ich werde um 6 Uhr informiert, dass es 6 Uhr is und ich aufstehen soll, Licht geht an, Musik geht an.
* Normalerweise stehe ich dann auch auf, beende das Weckprogramm (Musik geht aus) und gut
* Manchmal habe ich am Abend zuvor zu lange an FHEM rumgebastelt und komme deshalb nicht aus den Federn, dann wird um 06:05 die Musik lauter, um 6:10 werde ich nochmal ermahnt usw...

Prinzipiell funktioniert das auch so, das einzige Problem, das ich dabei habe - damit mein Weckprogramm durchläuft brauche ich einen offset von 30 Minuten, der führt aber dazu, dass mein Weckprogramm schon um 5:30 Uhr losläuft. Oder anders gesagt: ich muss den Wecker auf 06:30 stellen, um um 06:00 geweckt zu werden?
Verstehe ich hier irgendwas falsch, oder wie erreiche ich mein Ziel?

Danke,

Oli
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Loredo

Der Offset-Wert ist dafür gedacht, dass du beim Wecker eine Uhrzeit einstellst, zu der du aufstehen willst und der Weckvorgang jedoch früher anfängt.
Während dieser Offset-Zeit läuft dann ein Weckprogramm, welches dann (wie in den Beispiel-Makros zu sehen) schrittweise etwas tut, um dich bis zur Weckzeit sanft aufzuwecken. Das kann das schrittweise Hochfahren des Rollladens sein, eine Lampe, aber auch sanfte Musik ab einem bestimmten Zeitpunkt, die dann bis zum Erreichen der Weckzeit immer lauter wird. So ein Beispiel ist in den Beispiel-Makros enthalten.


Dann gibt es noch das Attribut wakeupEnforced, was dir hier ggf. noch etwas weiterhelfen kann.


Im Beispiel-Makro ist dafür ein extra Bereich vorgegeben. Das bedeutet, dass das Weckprogramm am Ende zunächst nichts weiter unternimmt. Mit gesetztem Attribut werden jedoch auch nach erreichen der Weckzeit weitere Befehle ausgeführt. Im Beispiel ist es das automatische setzen des Bewohners auf "awoken", um die daran verknüpften anderen Dinge auszulösen (in der Annahme, dass er dadurch quasi aus dem Bett geworfen wird  ;) ). Dort kannst du aber natürlich auch mehr oder was anderes definieren wie z.B. die Musik noch lauter zu drehen oder was auch immer. Das Framework ist da eigentlich flexibel genug für das genau so zu programmieren, wie du es vom Verhalten her haben möchtest.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

KernSani

Hi Loredo,

dann habe ich das ja alles richtig verstanden :-) das wakeupEnforced hilft mir leider auch nicht wirklich weiter, da ich ja einen offset von 0 möchte (und mir dann alle "at"s, die nach der Weckzeit kommen weggelöscht werden. Das könnte ich natürlich auch ändern und mir da was eigenes basteln, aber irgendwann gehen dann die Vorteile des Frameworks verloren)
Ich habe mir jetzt mit dem Wakeuptimer als Vorlage einen eigenen Dummy und ein paar DOIFs gebaut - da habe ich zwar nicht so viel Flexibilität (und vieles was im Wakeuptimer schon vorgedacht ist habe ich garnicht) aber für meine Zwecke reicht es und es entspricht eher meinen Aufsteh-Gewohnheiten. Ein gotosleep-DOIF hatte ich ohnehin schon... Der Wakeuptimer (und die vorgedachten Aktionen in den Makros) waren mir aber eine große Hilfe, somit Danke für den Gehirnschmalz der da schon reingeflossen ist...

Grüße,

Oli
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Loredo


Du brauchst aber keinen Offset, wenn du vorher nichts hast.


Das mit dem weglöschen der at-Timer stimmt nicht so ganz.


Das geschieht ja durch das Macro selbst direkt am Anfang. Wenn du aber ganz am Ende im Bereich nach "$EVTPART0 eq "stop"" deine temporären at-Devices anlegst, die nach der Weckzeit ausgeführt werden sollen, bleiben diese erhalten. Allerdings sind sie damit auch endgültig und können nicht mehr automatisch gelöscht bzw. abgebrochen werden. Deshalb sind im Beispiel auch nur zwei unterschiedliche Beispiele drin. Du kannst dort problemlos alles, was nach der Weckzeit passieren soll, hineinschreiben und auch zeitversetzt mit den temporären at-Devices reinschreiben. Aber ich gebe zu, ein DOIF ist vielmals sehr elegant und ich habe auch vor mir irgendwann nochmals Gedanken darüber zu machen, wie man das mit DOIF übersichtlicher und gar noch besser ausführen kann. Bisher fehlte mir dafür aber die Kraft denn wie du sagst, da steckt schon sehr viel Schmalz drin und man ist froh wenn es erstmal alles so läuft, wie man es möchte ;)
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

KernSani

Zitat von: Loredo am 21 August 2016, 19:22:06
Das mit dem weglöschen der at-Timer stimmt nicht so ganz.
Da hast du natürlich recht (ändert aber Grunde nichts daran, dass ich basteln müsste ;-))

Ich habe festgestellt, dass DOIF seit kurzem auch innerhalb eines DOIF-Zweiges mehrere Befehle/Befehlsketten zeitgesteuert abarbeiten kann... das macht das Ganze sehr angenehm... :-)
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...