Mit Bezug auf die hier (http://forum.fhem.de/index.php/topic,34897.msg272123.html#msg272123) erwähnten Neuerungen in den Modulen RESIDENTS, ROOMMATE und GUEST habe ich nun einmal einen sehr ausführlichen Wiki Artikel zu meiner Weckautomation geschrieben.
FHEM Wiki: Weckautomation (http://www.fhemwiki.de/wiki/Weckautomation)
Darin beschreibe ich beispielhaft, was man so alles machen kann und wieso ich dafür die genannten 3 Module so erweitert habe, dass die Automation damit realisiert werden kann. Ich hoffe daraus wird ersichtlich, dass die Module inzwischen deutlich mehr sind und tun, als es ein normales Dummy Device nebst individueller Programmierungen tun kann (zumindest wenn nicht jeder das Rad neu erfinden soll oder im Räder erfinden nicht sonderlich begabt ist).
Ein Zitat aus dem Beginn, was das Beispiel der Weckautomation am Ende leistet:
Zitat
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 Weckzeit
- 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.
Mein besonderer Dank gilt übrigens Reinerlein und seinem SONOS Modul, ohne das meine Automation niemals so genial geekig hätte werden können ;D
Gruß
Julian
PS:
Hoffentlich bekomme ich diesmal etwas mehr Feedback, da stecken inzwischen hunderte Stunden Arbeit über die Jahre drin... :D (ja, ich weiß...)
Hi Loredo,
ich hätte auch gerne so eine coole Weck-Automation, leider fehlen mir SONOS und HUE... Trotzdem danke für die ausführliche Beschreibung (und natürlich das Modul selbst).
Wie stellst du fest, dass jemand ins Bett geht? Also, wie setzt du gotosleep oder asleep (selbe Frage beim Aufwachen)
Grüße,
Oli
Hi Oli,
dass jemand ins Bett geht, kann man meines Erachtens nach nicht automatisch feststellen.
Ich setze aktuell im Bedarfsfall den Status "gotosleep" über mein Smartphone, wenn mir nach einer Zubettgehzeremonie ist oder gehe eben direkt ins Bett. Dort schalte ich über einen Homematic Wandtaster in den Status "asleep". Gleiches gilt fürs aufwachen: Ich betätige den gleichen Taster, um morgens in den Status "awoken" zu schalten (wenn der Status "awoken" nicht automatisch durch das Weckprogramm gesetzt wird, Stichwort Enforced Wakeup ;) .
Gruß
Julian
Hallo Loredo,
Ich werde sicher einiges von deinen Ideen aufgreifen, meinen Bedürfnissen anpassen und nutzen.
Ähnliches steht bei mir auf der Agenda und ist nun mit deinem Gerüst erheblich einfacher umzusetzen ;)
Vielen Dank für deine Mühe alles für die Allgemeinheit zur Verfügung zu stellen.
Zitatdass jemand ins Bett geht, kann man meines Erachtens nach nicht automatisch feststellen.
aber ob er im bett ist mit temperatur- oder drucksensor.
Zitat von: frank am 30 März 2015, 13:18:24
aber ob er im bett ist mit temperatur- oder drucksensor.
Davon halte ich nix (gab es schonmal die Diskussion) :)
Noch gibt es dafür kaum geeignete Sensoren und außerdem will ich mich auch mal so aufs Bett legen oder setzen können, ohne dass gleich irgendwas ausgelöst wird. Das wäre für manche Situation sicher eher verstörend ;D
Zitat von: Noxus am 30 März 2015, 13:17:06
Ich werde sicher einiges von deinen Ideen aufgreifen, meinen Bedürfnissen anpassen und nutzen.
Ähnliches steht bei mir auf der Agenda und ist nun mit deinem Gerüst erheblich einfacher umzusetzen ;)
Vielen Dank für deine Mühe alles für die Allgemeinheit zur Verfügung zu stellen.
Bittesehr! Genau dafür ist das Gerüst auch gedacht: Flexibel den eigenen Bedürfnissen anpassen aber eben mit Rahmenbedingungen, die man eigentlich gerne so haben würde ;)
Ein Präsenzmelder unterm Bett und ein Türkontakt wäre die ultimative Lösung...
Zitat von: der-Lolo am 30 März 2015, 15:09:21
Ein Präsenzmelder unterm Bett und ein Türkontakt wäre die ultimative Lösung...
Genau... dann kannst du auch gleich das Rotlicht einschalten und je nachdem wie stürmisch sich aufs Bett geworfen wird noch dazu die passende Rockmusik erklingen lassen!
Im Ernst: Ich halte das für zu beschränkt, aber das muss jeder selbst wissen ;)
Kann ja jeder lösen, wie er meint.
Naja wäre ja schon toll nach dem ins Bett gehen nur noch gedimmtes Licht für den Toiletten gang zu haben.
Und eben nicht noch einen Extra Schalter zu drücken.
Dafür ist eigentlich der Status "gotosleep" da; da stelle ich genau dies her. Den wähle ich ja sinnvollerweise explizit aus - ich möchte mich nicht kurz ins Bett legen müssen, um diese Szene zu aktivieren nur um dann wieder aufzustehen und ins Bad zu wandern ;D
Aber wie gesagt, da hat jeder andere Bedürfnisse, Vorstellungen und Gewohnheiten.
Was übrigens noch geplant ist zu implementieren:
1. Dynamischer Beginn des Weckprogramms auf Grundlage der 1,5h Schlafzyklus Regel
2. Weckzeit automatisch bei Terminen im Kalender anpassen (z.B. früher als die normale Weckzeit)
etwas offtopic...
Zitat
Dort schalte ich über einen Homematic Wandtaster in den Status "asleep"
Das ist irgendwie mein Problem, man könnte so vieles so schön automatisieren, wenn man es automatisch machen könnte (Bei An-/Abwesenheitssteuerung das selbe).
Ich gehe auf "gotosleep", wenn mein IPhone an das Ladegerät am Nachttisch gehängt wird (das wiederum an einer PCA301 hängt). Da kann meine Frau schon im Bett sein, oder auch nicht... Ihr Handy ist auf jeden Fall irgendwo, nur nicht am Ladegerät. Und irgendwelche Taster zu drücken um schlafen zu gehen? Waf gegen null...
Ändert natürlich nichts daran, dass RESIDENTS & Co. tolle Möglichkeiten bieten
Anregungen sind natürlich willkommen...
Grüße,
Oli
Zitat von: KernSani am 30 März 2015, 22:15:10
Und irgendwelche Taster zu drücken um schlafen zu gehen? Waf gegen null...
Also ich habe einen Lichtschalter an der Schlafzimmertür, der bei langem Tastendruck an Abend alle Lichter außer Schlafzimmer und den Fernseher im Wohnzimmer ausschaltet, die Heizung im Wohnzimmer runter fährt und die anwesenden Bewohner auf "asleep" setzt - der letzte der ins Bett geht drückt den Taster (und da der alles ausschaltet macht meine Frau das auch, wenn ich nicht da bin...)
Ronny
Hallo Loredo,
Vielen Dank für diese Klasse Implementierung eines Weckers!
Ich teste das gerade und hätte dazu folgende Frage:
Wenn ich einen wakeuptimer erstelle, dann werden ja auch die at's dazu erstellt, diese stehen per default auf 5 Uhr morgens. Was mir dazu noch nicht ganz klar ist, was passiert denn wenn ich eine Weckzeit von 04:30 einstelle mit einem Offset von 30. Wird dies Weckzeit dann überhaupt getriggert? Oder muss ich dazu das auto-create AT umstellen auf 04 Uhr?
Du musst an den at-Devices nichts verstellen. Die Zeiten werden automatisch umgestellt, wenn du die Weckzeit am dummy-Device veränderst. Das at-device steht nur auf 05:00, wenn die Weckzeit auf OFF steht und du gleichzeitig noch keine default-Weckzeit im Dummy-Device hinterlegt hast. Dies ist notwendig, damit darüber die tägliche Reset-Funktion gewährleistet bleibt.
Use-Case: Man kann also z.B. den Wecker an einem Tag ausschalten und er schaltet sich dann am nächsten Tag automatisch wieder an (je nach Einstellung).
Danke für die Aufklärung.
Ich habe am rr_Rene_wakeuptimer1 eine wakeupDefaultTime von 04:30 eingestellt, dazu einen Offset von 30 Minuten.
Jetzt muss ich also nur noch den "nextRun" auf 04 Uhr stellen am rr_Rene_wakeuptimer1, ab dann läuft der Wecker automatisch los, ist das so korrekt?
Ein kleiner Hinweis (bitte nicht hauen! :) )
Im Wiki bei den Beispielen mit "wakeupEnforced" ist ein kleiner Tip-Fehler enthalten, das muss doch sicherlich
attr rr_Julian_wakeuptimer1 wakeupEnforced 1
heißen? Zumindest gibt es ein wakeupEnfore attribut.
Evtl. auch eine Anregung für andere:
Ich hole mir via Tasker von meinem Handy einfach die nächste Weckzeit und stelle dem entsprechend 10 min vorher ein AT, das dann das Wakeuplight, Wetteransagen, Dimmer ect. zur richtigen Zeit startet.
Zitat von: Kuzl am 02 April 2015, 08:47:15
Evtl. auch eine Anregung für andere:
Ich hole mir via Tasker von meinem Handy einfach die nächste Weckzeit und stelle dem entsprechend 10 min vorher ein AT, das dann das Wakeuplight, Wetteransagen, Dimmer ect. zur richtigen Zeit startet.
Das interessiert mich sehr, kannst du das vielleicht ein bisschen genauer beschreiben.
Danke
Hallo,
Nachdem der Wecker nun 2 Tage hervorragend funktionierte, scheint er jetzt zu streiken. Die Watchdogs stehen alle auf "triggered" und gehen nicht mehr in de Modus "defined" zurück, was natürlich dazu führt das ein setzen eines Roommates oder aller Residents keine Macros mehr ausführt und somit weder gotosleep noch asleep getriggert werden.
Warum es seit heute nicht funktioniert kann ich noch nicht sagen, meine Vermutung scheint vielleicht mit dem Feiertag zusammenzuhängen? Ich habe einen WakupTimer der an 0,5,6 orHoliday auslöst. Das awoken Macro heute Früh wurde nämlich noch getriggert. Mal sehen ob das der Wakeuptimer am Samstag früh also morgen (schon heute mittlerweile) getriggert wird und die Watchdogs wieder auf defined gehen.
Die Watchdogs haben alle ein "setstate XXX defined" mit drin. Hast du vielleicht die Watchdogs angepasst und dies rausgelöscht oder hast du die Watchdogs umbenannt und dabei das setstate-Kommando nicht angepasst?
Genau das mit dem "setstate" hat mich gewundert. Weil ich dieses bei keinem der Watchdogs gesehen habe. Ich wollte es schon selbst dazu schreiben aber erst einmal auf deine Antwort warten, da ich nicht genau weiß ob du vielleicht im Hintergrund irgendein "Voodoo" machst und das deshalb da nicht benötigt wird.
Edit: irgendwie hat Tapatalk den halben Beitrag verschluckt.
Nachtrag:
Ich habe die Timer/Makros nicht umbenannt oder direkt daran gedreht. Es hat ja auch schon 2 Tage funktioniert. Nur die Besonderheit mit dem 2. WakupTimer der 0,5,6 orHolidays auslöst hat eben nicht funktioniert. Deshalb ist es mir ja erst aufgefallen. Als ich in der Liste der Watchdogs im Residents Room eine Menge an "triggered" Watchdogs hatte.
Wenn ich das setState hinzufüge, dann wie bei anderen Watchdogs auch mit ";; setState <wd name> defined;" oder?
Da es bei dir anfänglich ja ging und sie definitiv so angelegt werden, hast du sie wohl unwissentlich irgendwie entfernt ;-)
Zitat von: mrbreil am 02 April 2015, 13:46:39
Das interessiert mich sehr, kannst du das vielleicht ein bisschen genauer beschreiben.
Ich frage mit Tasker auf das Android Intent android.intent.action.ALARM_CHANGED ab. Anschließend wird mit dem Tasker-plugin "AutoAlarm" die nächste Weckzeit ausgelesen und via Http-get ein dummy in fhem gesetzt.
Gruß
Kuzl
Cool, darüber ließe sich auch der wakeuptimer Dummy setzen.
Lebe allerdings lieber im i-Universum, schade also 8)
Zitat von: Loredo am 04 April 2015, 20:56:03
Da es bei dir anfänglich ja ging und sie definitiv so angelegt werden, hast du sie wohl unwissentlich irgendwie entfernt ;-)
Ich muss da nochmal nachfragen, weil ich mir beim besten Willen nicht vorstellen kann, dass ich bei allen "versehentlich" des setstate entfernt haben sollte. Bei einem sehe ich das ja noch ein, aber bei allen?
Da ich eben ein update und shutdown restart durchgeführt habe sind natürlich erst einmal alle watchdogs wieder auf "defined".
Trotzdem wäre ich für einen Hinweis dankbar wo das setstate denn fehlen soll, ist das direkt beim CMD der watchdogs?
So sieht es bei mir im Moment aus:
rgr_Residents:asleep 00:00:03 rgr_Residents:(home|absent|gone|none|gotosleep|awoken) trigger Macro_rgr_Residents_asleep
muss dann so aussehen?
rgr_Residents:asleep 00:00:03 rgr_Residents:(home|absent|gone|none|gotosleep|awoken) trigger Macro_rgr_Residents_asleep; setstate wd_rgr_Residents_asleep defined
Edit:
Ich habe eben mal einen neuen Roommate angelegt und diesen mit einem Wakeuptimer "versorgt". Die watchdogs für gotosleep, asleep und awoken sehen exakt so aus wie mein erstes Codeschnipsel oben, also kein "setstate" am Ende? Irgendwelche Tipps? Schaue ich an der falschen Stelle?
Ja, das zweite Beispiel entspricht dem, wie es sein müsste.
Habe es auch gerade nachvollzogen, wie es scheint habe ich es versäumt das setstate aus meiner Testumgebung in das Toolkit zu übertragen... habe das gerade nachgeholt und ins SVN eingecheckt. Danke für das aufmerksame testen ;)
Hallo Loredo,
ich habe das heute nach einem Update und restart von FHEM bei mir ausprobiert, es werden auch weiterhin die watchdogs wie bisher bei mir angelegt, also ohne den "setstate <wd..._asleep> defined"
Die Version die ich nutze ist:
# $Id: 10_RESIDENTS.pm 8376 2015-04-05 08:16:49Z loredo $
Hm da war wohl noch ein Tippfehler, den ich gerade korrigiert habe...
Hallo Loredo,
ich poste das mal hier, weil ich den wakeuptimer als erstes in Verdacht habe dafür:
Heute früh lief kein Wecker an und auch sonst lief kein Prozess an, keine Heizungssteuerung usw. Der RasPi lief, ein "top" zeigte mir aber das der Perl-Prozess mit 100% CPU den RasPi Komp.. ausgelastet hat.
Warum schreibe ich das hier? Weil:
Um 4:30 ist "normalerweise" ein Wecker gestellt mit einem Offset von 30 Minuten. Also um 4 Uhr sollte der wakeuptimer1 losrennen. Den Wecker hatte ich aber gestern Abend auf "OFF" gestellt.
Der letzte Eintrag in meinem hem.log ist von 03:59:23, also kurz vor 4 Uhr, deshalb habe ich erstmal den wakeuptimer in Verdacht. Ich finde aber keinen Fehler oder sonstiges im fhem.log, das Log hört einfach um 03:59:23 auf. Nach einem Restart wird das auch brav weitergeschrieben.
So sieht das um die Zeit aus:
2015.04.08 03:55:19 3: CUL_HM set Buero_virtTemp_Sensor1 virtTemp 18.5
2015.04.08 03:55:23 3: CUL_HM set BAD.Heizung_virtTemp_Sensor1 virtTemp 18.4
2015.04.08 03:57:19 3: CUL_HM set Buero_virtTemp_Sensor1 virtTemp 18.5
2015.04.08 03:57:23 3: CUL_HM set BAD.Heizung_virtTemp_Sensor1 virtTemp 18.4
2015.04.08 03:59:19 3: CUL_HM set Buero_virtTemp_Sensor1 virtTemp 18.5
2015.04.08 03:59:23 3: CUL_HM set BAD.Heizung_virtTemp_Sensor1 virtTemp 18.4
2015.04.08 09:15:07 1: Including fhem.cfg
2015.04.08 09:15:07 3: telnetPort: port 7072 opened
2015.04.08 09:15:09 3: WEB: port 8083 opened
2015.04.08 09:15:09 3: WEBphone: port 8084 opened
Um 9:15 habe ich fhem restartet.
Könnte es etwas mit dem "off" zu tun haben, vielleicht irgendwo mit dem wakeuptimer einen Zusammenhang.
Bisher haben die Wecker immer funktioniert und auch FHEM lief in der früh noch normal und hat alles gesteuert. Nun habe ich gestern das erste mal einen Wecker auf "off" gestellt und fhem hing. Daher die Vermutung.
Das ist eher unwahrscheinlich bis unmöglich. Die Weckfunktion ist rein Event gesteuert, da läuft nix im Hintergrund außer dem normalen at-Device bzw. dessen Modul.
Aber was in deinen Macros so aufgeführt wird, darauf hab ich keinen Einfluss. Entweder ist der Zusammenfall also reiner Zufall oder in deiner Automation wird was verhaspelt.
Ein Macro sollte doch gar nicht ausgeführt werden, wenn der Wakeuptimer auf OFF steht, oder?
Der AT läuft zwar an um z.B. 4:00 stellt aber fest das der Timer auf Off steht und macht nichts weiter. Oder sehe ich das falsch?
Kein Macro, richtig. Es wird nur der Reset Teil durchlaufen und das läuft bei mir seit Wochen bombenfest.
Ich wüsste nicht, was du mit dem Timer falschen machen würdest und denke auch nicht, dass du den Fehler hier suchen musst. Zu hast vermutlich zu viele Baustellen zeitlich in deiner Installation und kannst es deshalb jetzt nicht richtig zuordnen.
War ja auch nur erst einmal eine naheliegende Vermutung. Ich werde das mal beobachten. Der Wakeuptimer ist erstmal wieder angeschaltet aber nicht wegen dem Fehler sondern weil er morgen wirklich benötigt wird. Mal sehen wie sich Fhem morgen früh verhält.
Hatte so ein Phänomen ja bisher auch noch nicht. Ich steuere noch sehr sehr wenig mit Fhem aber heute früh ist es mir dann direkt negativ aufgefallen wenn es nicht funktioniert.
Erstmal Danke für die tolle Arbeit, Wecker und Makros funktionieren so weit ganz gut. Allerdings habe ich ein ähnliches Verhalten wie rretsiem
Punkt 4:30 fängt das System das spinnen an (ich bekomme dann z.b. auch kein Notify mehr wenn ich meine Haustüre öffne) :
2015.04.09 02:08:43 3: FS20 set BadBewegungsmelder off
2015.04.09 04:30:00 1: Error: 0 has no TYPE
2015.04.09 04:30:00 1: Error: 0 has no TYPE
2015.04.09 04:30:00 1: Error: 0 has no TYPE
2015.04.09 04:30:02 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
2015.04.09 04:30:21 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
2015.04.09 04:30:33 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
2015.04.09 04:30:57 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
2015.04.09 04:31:03 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
2015.04.09 04:31:34 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
2015.04.09 04:31:34 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
2015.04.09 04:32:05 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
2015.04.09 04:32:10 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
2015.04.09 04:32:36 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
2015.04.09 04:32:46 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
2015.04.09 04:33:07 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
2015.04.09 04:33:22 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
2015.04.09 04:33:37 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
2015.04.09 04:33:58 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
2015.04.09 04:33:59 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
2015.04.09 04:34:08 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
2015.04.09 04:34:34 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
2015.04.09 04:34:39 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
2015.04.09 04:35:09 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
Ich habe ebenfalls den ausgeschalteten Wecker in Verdacht, der um 6:30 funktioniert perfekt und wie gewünscht :
at_rr_Martin_wakeuptimer1 Next: 06:30:00
at_rr_Martin_wakeuptimer3 Next: 04:30:00
Nach einem restart läuft es wieder rund aber ich bekomme die Fehlermeldung ins motd geschrieben :
Error messages while initializing FHEM:
configfile: rr_Martin_wakeuptimer1_resetswitcher already defined, delete it first
Ich habe jetzt mal das Logging auf 5 gestellt für alle Module und schau was da Morgen früh alles drin steht zu der Zeit
Zitat von: MartinMuc am 09 April 2015, 09:09:37
Error messages while initializing FHEM:
configfile: rr_Martin_wakeuptimer1_resetswitcher already defined, delete it first
Den Fehler habe ich bei mir ebenfalls
Error messages while initializing FHEM:
configfile: rr_Rene_wakeuptimer1_resetswitcher already defined, delete it first
rr_Rene_wakeuptimer2_resetswitcher already defined, delete it first
rr_Sabine_wakeuptimer1_resetswitcher already defined, delete it first
Das "already defined" ist kein großartiger Fehler, es ist nur eine Warnung und ich habe es gerade unterdrückt.
Den Rest kann ich mir leider aktuell nicht erklären; ich habe das früher auch schonmal bei mir gesehen und konnte die Ursache nicht finden, es war auch schließlich irgendwann weg ohne erkennbaren Grund.
Ich habe mir jetzt auch mal einen ausgeschalteten Timer angelegt (habe ich eigentlich die ganze Zeit schon, allerdings für das GUEST Device. Das kann nen Unterschied machen, also mal sehen...)
Gruß
Julian
Ich beobachte morgen vormittag mal und wenn ich was im ausführlichen Log morgen finde poste ich mal die Logs. Wäre ja gelacht wenn wir die Ursache ned finden und beheben (kann ja auch irgend ne blöde Kombi in meiner Konfig sein)
viele Grüße
Martin
heute nacht kam das Problem wieder hier mal das Log aus dem Zeitraum.
was mich irritiert : rr_Martin_wakeuptimer2 und rr_Martin_wakeuptimer4 habe ich nirgends mehr den hatte ich gelöscht weil zu viel, ebenso den 2er : No device named rr_Martin_wakeuptimer4 found
015.04.10 04:30:00 5: Cmd: >setreading rr_Martin_wakeuptimer3:FILTER=state!=OFF state OFF<
2015.04.10 04:30:00 5: Triggering rr_Martin_wakeuptimer3 (2 changes)
2015.04.10 04:30:00 5: Triggering rr_Martin_wakeuptimer3 (2 changes)
2015.04.10 04:30:00 4: RESIDENTStk rr_Martin: 00 - checking for next wake-up candidate rr_Martin_wakeuptimer1
2015.04.10 04:30:00 4: RESIDENTStk rr_Martin_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=0
2015.04.10 04:30:00 4: RESIDENTStk rr_Martin_wakeuptimer1: 02 - possible candidate found
2015.04.10 04:30:00 4: RESIDENTStk rr_Martin_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=06:30 wakeupOffset=30
2015.04.10 04:30:00 4: RESIDENTStk rr_Martin_wakeuptimer1: 04 - this is a candidate for today
2015.04.10 04:30:00 4: RESIDENTStk rr_Martin_wakeuptimer1: 05 - until now, will be NEXT WAKE-UP RUN today based on weekday decision
2015.04.10 04:30:00 4: RESIDENTStk rr_Martin_wakeuptimer1: 06 - won't be running today based on holiday decision (wakeupHolidays=andNoHoliday)
2015.04.10 04:30:00 4: RESIDENTStk rr_Martin: 00 - checking for next wake-up candidate rr_Martin_wakeuptimer2
2015.04.10 04:30:00 4: RESIDENTStk rr_Martin_wakeuptimer2: 01 - Not considering any holidays
2015.04.10 04:30:00 4: RESIDENTStk rr_Martin_wakeuptimer2: 02 - set to OFF so no candidate
2015.04.10 04:30:00 4: RESIDENTStk rr_Martin: 00 - checking for next wake-up candidate rr_Martin_wakeuptimer3
2015.04.10 04:30:00 4: RESIDENTStk rr_Martin_wakeuptimer3: 01 - Holidays to be considered - today=0 tomorrow=0
2015.04.10 04:30:00 4: RESIDENTStk rr_Martin_wakeuptimer3: 02 - set to OFF so no candidate
2015.04.10 04:30:00 4: RESIDENTStk rr_Martin: 00 - checking for next wake-up candidate rr_Martin_wakeuptimer4
2015.04.10 04:30:00 4: RESIDENTStk rr_Martin_wakeuptimer4: 01 - Not considering any holidays
2015.04.10 04:30:00 4: RESIDENTStk rr_Martin_wakeuptimer4: 02 - set to OFF so no candidate
2015.04.10 04:30:00 4: RESIDENTStk rr_Martin: 07 - next wake-up result: today at 07:00:00, wakeupDevice=rr_Martin_wakeuptimer1
2015.04.10 04:30:00 5: Cmd: >setreading rr_Martin:FILTER=nextWakeupDev!=rr_Martin_wakeuptimer1 nextWakeupDev rr_Martin_wakeuptimer1<
2015.04.10 04:30:00 1: Error: 0 has no TYPE
2015.04.10 04:30:00 5: Cmd: >setreading rr_Martin:FILTER=nextWakeup!=07:00 nextWakeup 07:00<
2015.04.10 04:30:00 1: Error: 0 has no TYPE
2015.04.10 04:30:00 5: Cmd: >setreading rr_Martin:FILTER=wakeup!=0 wakeup 0<
2015.04.10 04:30:00 1: Error: 0 has no TYPE
2015.04.10 04:30:00 5: redefine at command at_rr_Martin_wakeuptimer3 as *{RESIDENTStk_wakeupGetBegin("rr_Martin_wakeuptimer3")} set rr_Martin_wakeuptimer3 trigger
2015.04.10 04:30:00 5: Cmd: >{RESIDENTStk_wakeupGetBegin("rr_Martin_wakeuptimer3")}<
2015.04.10 04:30:00 4: RESIDENTStk rr_Martin_wakeuptimer3: wakeupGetBegin source: defaultValue
2015.04.10 04:30:00 4: RESIDENTStk rr_Martin_wakeuptimer3: wakeupGetBegin result: 05:00 = 16200 s - 30 m = 04:30:00
2015.04.10 04:30:02 4: BlockingCall created child (8442), uses telnetForBlockingFn to connect back
2015.04.10 04:30:02 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4159.
Ich konnte den Fehler jetzt darauf einkreisen, dass ihr alle wohl kein wakeupDefaultTime Attribut gesetzt habt, ich aber schon überall ;)
Ohne das Attribut kam es zu einem Loop, was dann vermutlich das eingefrohrene FHEM erklärt. Die Meldung "has no TYPE" kann ich mir in dem Zusammenhang trotzdem nicht erklären. Bei mir steht auch noch konkreter im Log, dass er damit das at-Device meint. Ich habe keine Ahnung zu welchem Zeitpunkt das at-Device dieses INTERNAL nicht haben soll... im at-Modul selbst konnte ich dazu auch nichts finden (dort wird nichtmal ein TYPE gesetzt seltsamerweise...).
Anyway, ich denke ich konnte den Loop jetzt soweit beheben. Ab morgen per Update oder jetzt im SVN.
Gruß
Julian
Ich werde es morgen testen :)
Sehr gut, danke dir!
Inzwischen habe ich wohl auch die Quelle für die "has no TYPE" Geschichten gefunden und gefixt.
Alles klar Julian, ich aktualisiere Morgen und lasse dann nochmal im hohen Loglevel alles laufen falls noch was kommt
Gesendet von iPhone mit Tapatalk
Zitat von: Loredo am 12 April 2015, 13:52:47
Ich konnte den Fehler jetzt darauf einkreisen, dass ihr alle wohl kein wakeupDefaultTime Attribut gesetzt habt, ich aber schon überall ;)
Ohne das Attribut kam es zu einem Loop, was dann vermutlich das eingefrohrene FHEM erklärt.
Da muss ich kurz einhaken, alle 3 von mir genutzten Wakeuptimer haben das Attribut "wakeupDefaultTime" gesetzt. Habe es eben mal überprüft.
Auch wenn ich die Weckzeit auf "OFF" stelle bleibt das Attribut bestehen mit der letzten eingestellten Uhrzeit. Also Weckzeit ist 04:30, wakeupDefaultTime ist es ebenso. Dann auf "OFF" gestellt, das Attribut verändert sich auch nicht. Ist also weiterhin vorhanden (wollte da nur etwas ausschließen wie ein "löschen" des Atttibutes beim setzen des Weckers auf OFF)
Ich bin nicht sicher, ob ich alles verstehe, was du schreibst ;D
Es waren zumindest mehrere Fallstricke, die in bestimmten Konstellationen einzeln oder zusammen auftreten konnten. Und ihr habt die offenbar alle erwischt (z.B. Timer löschen ohne das dazugehörige at auch zu löschen...).
Hi Julian,
kurzes Feedback heute alles so wie gewünscht verlaufen keine Fehler mehr.
DAnke dir fürs schnelle fixen.
viele Grüße
Martin
Sehr schön, das freut mich :)
Hi Loredo,
hat sich durch die Fixes irgendwas an den Macros/watchdogs auch geändert? Ich frage ob es Sinn macht die mit den älteren Versionen angelegten "Devices" durch create wakeuptimer noch einmal zu löschen und neu anzulegen oder sollte das an der Stelle keinen Unterschied machen?
Ein "OFF" habe ich noch nicht wieder getestet, allerdings vertraue ich den Wakeuptimer leider noch nicht so wie es sein sollte. Heute früh um 04:30 wurde der Wecker nicht ausgelöst, er ist definitiv gestellt und auch das "at" dazu steht auf next run 4 Uhr. Der awoken Zustand ist aber heute nicht eingetreten für den Roommate.
Das klingt, als hättest du deine Macros verkonfiguriert. Ich denke es ist eine gute Idee, wenn du nochmals von vorne startest.
Hallo Loredo,
nachdem der Wakeuptimer die letzte Woche gut lief, hat heute das AT um 7 Uhr nicht ausgelöst. Der Wecker ist auf 7:30 Uhr gestellt mit einem Offset von 30 Minuten.
lastRun 07:30 2015-04-16 07:00:00
nextRun 07:30 2015-04-20 09:30:49
running 0 2015-04-16 07:30:01
state 07:30 2015-04-20 09:30:49
Der LastRun war also 16.04. und nicht wie gewünscht HEUTE.
Hier der List auf den AT:
Internals:
COMMAND set rr_Rene_wakeuptimer1 trigger
DEF *{RESIDENTStk_wakeupGetBegin("rr_Rene_wakeuptimer1","at_rr_Rene_wakeuptimer1")} set rr_Rene_wakeuptimer1 trigger
NAME at_rr_Rene_wakeuptimer1
NR 161
NTM 07:00:00
PERIODIC yes
RELATIVE no
REP -1
STATE Next: 07:00:00
TIMESPEC {RESIDENTStk_wakeupGetBegin("rr_Rene_wakeuptimer1","at_rr_Rene_wakeuptimer1")}
TRIGGERTIME 1429592400
TRIGGERTIME_FMT 2015-04-21 07:00:00
TYPE at
Readings:
2015-04-20 09:30:49 state Next: 07:00:00
Attributes:
comment Auto-created by RESIDENTS Toolkit: trigger wake-up timer at specific time
room Residents
wakeupAtdevice at_rr_Rene_wakeuptimer1
wakeupDays 2,3,4
wakeupDefaultTime 07:30
wakeupEnforced 1
wakeupHolidays andNoHoliday
wakeupMacro Macro_rr_Rene_wakeuptimer1
wakeupOffset 30
wakeupResetSwitcher rr_Rene_wakeuptimer1_resetswitcher
wakeupResetdays 2,3,4
wakeupUserdevice rr_Rene
Ich weiß das es vermutlich wieder mal an mir liegt, aber da ich an dem Wecker nichts geändert habe seit letzter Woche und er heute nicht mehr auslöst, vielleicht hast du ja noch eine Idee oder kannst mal in der Implementierung schauen ob es da einen Ansatz gibt warum der AT nicht ausgelöst hat?
Zitat von: rretsiem am 20 April 2015, 09:50:33
wakeupAtdevice at_rr_Rene_wakeuptimer1
wakeupDays 2,3,4
wakeupDefaultTime 07:30
wakeupEnforced 1
wakeupHolidays andNoHoliday
wakeupMacro Macro_rr_Rene_wakeuptimer1
wakeupOffset 30
wakeupResetSwitcher rr_Rene_wakeuptimer1_resetswitcher
wakeupResetdays 2,3,4
wakeupUserdevice rr_Rene
Laut Attribut wakeupDays möchtest du nur Dienstags, Mittwochs und Donnerstags geweckt werden, wenn diese keine Feiertage sind (wakeupHolidays = andNoHoliday). Heute ist aber Montag.
Er hätte sicherlich heute ausgelöst, wenn du wakeupDays auf 1,2,3,4 gesetzt hättest :-)
Zitat von: Loredo am 20 April 2015, 11:38:34
Er hätte sicherlich heute ausgelöst, wenn du wakeupDays auf 1,2,3,4 gesetzt hättest :-)
??? :-[
Danke! Bei den ganzen versch. Implementierungen komme ich einfach durcheinander. Also Layer-8 Problem, danke! :)
Hi Loredo,
eine kurze Frage, wie verhält sich denn ein Wecker der z.B. für morgen früh 7:30 Uhr gestellt ist, der Roommate aber nicht im Status asleep/gotosleep ist, sondern im Status "gone"? Wird der Wecker trotzdem loslaufen oder "nur" wenn vorher z.B. asleep oder gotosleep eingestellt ist?
Falls der Wecker nicht losgeht müsste ich wohl schnell noch einen programmieren via VPN, sonst steht meine Frau morgen im dunkeln auf :-\
Hi,
der Wecker wird sinnvollerweise nur ausgelöst, wenn das ROOMMATE Device einen Status ungleich gone/away hat.
Das ist ja Sinn der Kopplung mit dem ROOMMATE Device. Hilft dir aber natürlich jetzt nicht weiter. Ich empfehle dir dich mal mit dem Thema Anwesenheit vertraut zu machen: http://www.fhemwiki.de/wiki/Anwesenheitserkennung (http://www.fhemwiki.de/wiki/Anwesenheitserkennung)
Ich verwende bei mir Geofency.
Gruß
Julian
Ab morgen gibt es per Update eine Verbesserung im Verhalten:
Sofern während eines aktiven Weckprogramms das RESIDENTS/ROOMMATE/GUEST Device auf "away" oder "gone" (bzw "none" im Fall von GUEST) wechselt, wird das Weckprogramm automatisch abgebrochen.
Ich habe das Verhalten nochmals angepasst:
1. Laufende Weckprogramme werden jetzt generell immer gestoppt, wenn sich der Status des ROOMMATE/GUEST/RESIDENTS Device ändert, zu welchem der Wecker zugeordnet ist. Jedoch werden im Macro nachgelagerte Dinge weiterhin wie beim normalen beenden ausgeführt, sofern der Bewohner weiterhin zu Hause (präsent/present) ist.
2. Sofern das Attribut wakeupDefaultTime verwendet wird, wurde das Weckprogramm bisher doppelt am selben Morgen ausgeführt, wenn manuell für einen Tag eine frühere Weckzeit eingestellt wurde (das erste Mal bei der eingestellten Weckzeit, danach an der Default Weckzeit nochmals, nachdem der Wecker ja nach dem ersten Lauf darauf zurückgesetzt wurde). Die letzte Ausführung eines Weckprogramms muss jetzt mindestens 6 Stunden her sein, bevor es nochmals ausgeführt werden kann. Der Wert lässt sich über das neue Attribut wakeupWaitPeriod anpassen.
Die Änderungen stehen ab sofort im SVN oder morgen per Update zur Verfügung.
Hallo Loredo,
danke für die Anpassungen, dass klingt so jetzt deutlich "besser".
Noch eine Frage, ich lasse mir wie in den mitgelieferten Skripten eine Push-Nachricht schicken wenn ein Bewohner "asleep" geht, dabei wird die Aufweckzeit und der Bewohner in der Push-Nachricht übermittelt. Dabei scheint es so, als würde nicht die Weckzeit des NÄCHSTEN Weckers, sondern die des "heutigen" Weckers übermittelt.
Das ist der Code: (angepasst vom Default)
## Push mit Weckzeiten
my $nextWakeup = ReadingsVal("rr_Rene","nextWakeup",0);
my $text = "Es ist kein Wecker gestellt. Du könntest verschlafen! Trotzdem eine gute Nacht.";
if ($nextWakeup ne "OFF") {
$text = "Dein Wecker ist auf $nextWakeup Uhr gestellt. Gute Nacht und schlaf gut.";
}
fhem "set pushover msg \"Wecker\" \"$text\"";
Wenn ich jetzt 2 Wakeuptimer habe, am Wochenende 8 Uhr steht, unter der Woche 07:30, dann wird am Sonntag Abend trotzdem als Uhrzeit 08 Uhr übermittelt, obwohl dann ja eigentlich 07:30 drin stehen sollte.
Die WakeupDefaultTime steht bei beiden eben auf 07:30 und am Wochenende auf 08 Uhr. Kannst du das irgendwie nachvollziehen?
Das ist ne wirklich coole Sache, Kompliment. Habe es gestern auch mal "nachgebaut" und heute funktionierte es schon wie es soll.
Ich habe allerdings noch eine Verständnisfrage:
Der Wecker löst ja nicht aus, wenn ich nicht da bin (=gone). Wenn jetzt aber meine Frau den Wecker nutzen will ohne dass ich da bin, muss ich ja (so wie ich das verstanden habe) für sie auch die Macros einrichten. Aber mein Macro wakeuptimer1 würde ja genau das gleiche tun was ihr Macro wakeuptimer1 auslösen würde. Wenn dann beide zu Hause wären, was der Regelfall ist... wäre das dann nicht alles doppelt?
Wie habt ihr diesen Fall bei euch abgebildet?
Zitat von: andy19850 am 27 Mai 2015, 07:49:31
Wenn jetzt aber meine Frau den Wecker nutzen will ohne dass ich da bin, muss ich ja (so wie ich das verstanden habe) für sie auch die Macros einrichten. Aber mein Macro wakeuptimer1 würde ja genau das gleiche tun was ihr Macro wakeuptimer1 auslösen würde. Wenn dann beide zu Hause wären, was der Regelfall ist... wäre das dann nicht alles doppelt?
Wie habt ihr diesen Fall bei euch abgebildet?
Dieser Fall ist bereits vorgesehen. Du kannst bei jedem ROOMMATE Device einfach das zu verwendende Macro ändern, indem du den Namen im Attribut wakeupMacro entsprechend abänderst. Ein zuvor automatisch angelegtes Macro "wakeuptimer2" kannst du anschließend einfach löschen.
Das wakeuptimer1 Macro wird dann entweder durch den Wecker deiner Frau oder deines eigenen Weckers ausgelöst (je nachdem welcher Wecker zuerst "läutet").
Sind die Weckzeiten überlappend, sprich ist das Macro bereits aktiv, wird es nicht nochmals neu angestoßen. Ist der erste Wecker jedoch bereits abgelaufen und der Weckvorgang von Wecker1 "beendet", wird Wecker2 das Macro erneut ausführen, wenn er eingeschaltet ist.
Gruß
Julian
Hallo Loredo,
warum auch immer wird ein Resident nicht in den State "awoken" gesetzt nachdem der Wakeuptimer durchgelaufen ist. Das ganze hat bereits funktioniert (seit Wochen) aber irgendwas scheint wohl anders zu sein (Update?)
Hier mal das Log von heute morgen:
Der Wakeuptimer setzt alles korrekt: (Heute 6:30 Weckzeit)
2015.05.29 06:00:00 3: Macro_rr_Sabine_wakeuptimer2: Wake-up program started for rr_Sabine with target time 06:30
2015.05.29 06:30:01 3: Macro_rr_Sabine_wakeuptimer2: Wake-up program ended for rr_Sabine with target time 06:30
2015.05.29 06:35:01 2: ROOMMATE set rr_Sabine awoken
2015.05.29 06:35:05 3: Watchdog wd_rgr_Residents_awoken triggered
2015.05.29 06:35:05 3: FRITZBOX: set FritzBox wlan on
2015.05.29 06:35:06 3: CUL_HM set KUE.Strom.Boiler.OnOff on
2015.05.29 06:35:06 3: Residents state awoken, twilight is off
2015.05.29 06:35:07 3: Watchdog wd_rr_Sabine_awoken triggered
2015.05.29 06:35:07 3: Macro_rr_Sabine_awoken return value: HASH(0x3149cc8)
Man sieht das der Watchdog rgr_Residents_awoken ausgelöst wurde.
Nun der nächste Wecker (Weckzeit 7:30)
2015.05.29 07:30:00 3: Macro_rr_Rene_wakeuptimer2: Wake-up program started for rr_Rene with target time 08:00
2015.05.29 08:00:01 3: Macro_rr_Rene_wakeuptimer2: Wake-up program ended for rr_Rene with target time 08:00
Nichts weiter. Er setzt den Bewohner rr_Rene nicht auf "awoken" Im Wakeuptimer2 Skript ist der Default Wert drin beim STOP Event:
if ($EVTPART3) {
fhem "define atTmp_9_$NAME at +00:05:00 set $EVTPART4:FILTER=STATE=asleep awoken";
# Without enforced wake-up, be jentle and just set user state to 'home' after some
# additional long nap time
}
Ich bemerke es dann immer erst wenn der "awoken" Bewohner das Haus verlässt, weil dann dadurch die Residents Gruppe wieder auf "asleep" triggert.
Wie gesagt, hat das Ganze schon einmal zuverlässig funktioniert, daher die Frage ob jemand weiß weshalb der letzte Trigger beim EVENT STOP im wakeuptimer2 nicht ausgelöst wird.
Die Vermutung liegt nahe, dass rr_Rene sich nicht im Status "asleep" befinet, sprich abends nicht als schlafend markiert wurde.
Wenn du in jedem Fall bei egal welchem Status auf "awoken" gehen möchtest, solltest du den Befehl entsprechend abändern. Das Script ist ja nicht statisch, sondern du kannst das Framework frei nutzen und so anpassen, wie es für dich funktionieren soll.
So könnte es aussehen:
fhem "define atTmp_9_$NAME at +00:05:00 set $EVTPART4:FILTER=STATE!=awoken awoken";
Ich vermute aber, dass rr_Sabine abends auf "asleep" schaltet und du deine Automation nicht darauf ausgelegt hast, dass alle Bewohner schlafen und dann zB das Licht ausgeht, sondern rr_Sabine alleine ausreichend dafür ist. Das ist dann ein Denkfehler in der Art wie du das Drumherum des Wakeuptimer bei dir nutzt und implementiert hast. Jeder Schläfer sollte abhängig von den Lebensgewohnheiten getrennt oder eben immer gemeinsam mit seinem Partner als schlafend markiert werden. Bei getrennten Schlafzimmern funktioniert das natürlich ganz einfach. Bei einem gemeinsamen Schlafzimmer und noch dazu vielleicht zusammen Zubettgehen muss man aber beim Schalten der ROOMMATE Devices darauf achten, dass dann eben alle beteiligten Schläfer entsprechend in den richtigen Status geschaltet werden. Wie das genau gehen soll, muss jeder für sich selbst überlegen. Die einen Lesen noch was im Bett und haben dafür eine eigene Nachttischlampe, während der andere bereits schlafen will. Dann muss auch jeder getrennt sein "schlafen" bestätigen. Oder es wird immer gemeinsam das Licht aus gemacht, dann kann man die Events des einen ROOMMATE Devices auch mit dem anderen koppeln und direkt übernehmen. Wie gesagt, eine pauschale Aussage kann man hier nicht machen, weil sich darunter jeder etwas anderes vorstellt.
Zitat von: rretsiem am 16 Mai 2015, 22:26:22
Dabei scheint es so, als würde nicht die Weckzeit des NÄCHSTEN Weckers, sondern die des "heutigen" Weckers übermittelt.
...
Kannst du das irgendwie nachvollziehen?
Unter bestimmten Konstellationen konnte es sein, dass die Readings nextWakeup* nicht aktualisiert wurden.
Habe gerade eine verbesserte Version ins SVN geladen.
Ich habe den Wiki Eintrag für die Sonos Snooze Funktion aktualisiert:
http://www.fhemwiki.de/wiki/Weckautomation#Snooze_Funktion_bei_SONOS
Sie wird jetzt mit einem DOIF realisiert.
Hallo Loredo
Habe mit deiner Weckautomation ein kleines Problem wenn während des Weckens die Sprachausgabe
dazwischenfunkt (sagt mir z.b die aktuelle Temperatur an nicht aus deinen script heraus sondern extern)
mein Sonos keine Befehle mehr annimmt Radio bleibt einfach an. Erst wenn ich per Handy stop mache wird
die Sprachausgabe gestartet sowie der rest in der queue vom Player.
Hier mal der code
Macro_rr_andreLG2_wakeuptimer1 {
##=============================================================================
## This is an example wake-up program running within a period of 30 minutes:
## - drive shutters upwards slowly
## - light up a HUE bulb from 2000K to 5600K
## - have some voice notifications via SONOS
## - have some wake-up chill music via SONOS during program run
##
## Actual FHEM commands are commented out by default as they would need
## to be adapted to your configuration.
##
## Available wake-up variables:
## 1. $EVTPART0 -> start or stop
## 2. $EVTPART1 -> target wake-up time
## 3. $EVTPART2 -> wake-up begin time considering wakeupOffset attribute
## 4. $EVTPART3 -> enforced wakeup yes=1,no=0 from wakeupEnforced attribute
## 5. $EVTPART4 -> device name of the user which called this macro
## 6. $EVTPART5 -> current state of user
##=============================================================================
##-----------------------------------------------------------------------------
## DELETE TEMP. AT-COMMANDS POTENTIALLY CREATED EARLIER BY THIS SCRIPT
## Executed for start to cleanup in case this wake-up automation is re-started.
## Executed for stop to cleanup in case the user ends this automation earlier.
##
for (my $i=1; $i <= 10; $i++) {
if (defined($defs{"atTmp_".$i."_".$NAME})) {
fhem "delete atTmp_".$i."_".$NAME;
}
}
##-----------------------------------------------------------------------------
## BEGIN WAKE-UP PROGRAM
## Run first automation commands and create temp. at-devices for lagging actions.
##
if ($EVTPART0 eq "start") {
Log3 $NAME, 3, "$NAME: Wake-up program started for $EVTPART4 with target time $EVTPART1. Current state: $EVTPART5";
fhem "set Schalter_Dach on ; set RemotePI cmd set vitrinen_beleuchtung on; set Sonos_Schlafzimmer stop" ;
fhem "define atTmp_1_$NAME at +00:06:30 set Wz.DeckeFarbe HSV 60,70,80";
fhem "define atTmp_2_$NAME at +00:11:30 set Wz.DeckeFarbe HSV 0,50,80";
fhem "define atTmp_4_$NAME at +00:15:00 set Sonos_Schlafzimmer Speak 50 de |Hint| Es ist jetzt bereits ".$EVTPART1." Uhr, Zeit zum aufstehen raus aus den Federn!;;sleep 2;; set Wz.DeckeFarbe HSV 200,50,70 100 q;; sleep 8 ;;set Sonos_Schlafzimmer:FILTER=Volume<15 Volume 15 15 ";
fhem "define atTmp_5_$NAME at +00:30:00 set Sonos_Schlafzimmer stop ;;sleep 5 ;; set RemotePI cmd set vitrinen_beleuchtung off;;sleep 2;;set Schalter_Dach off ;; sleep 2;;set Wz.DeckeFarbe off ;;sleep 2;; set Sonos_Schlafzimmer Speak 30 de Licht wird wieder ausgeschalten du bist aufgestanden und gehst gleich zur Arbeit";
# if wake-up should be enforced
if ($EVTPART3) {
Log (4, "$NAME: planning enforced wake-up");
fhem "define atTmp_3_$NAME at +00:17:00 set Sonos_Schlafzimmer:FILTER=Volume>4 Volume 4;; sleep 0.5;; set Sonos_Schlafzimmer:FILTER=Shuffle=0 Shuffle 1;; sleep 0.5;; set Sonos_Schlafzimmer PlayURITemp http://www.antenne.de/webradio/antenne.m3u";
fhem "define atTmp_6_$NAME at +00:18:00 set Sonos_Schlafzimmer Volume 7";
fhem "define atTmp_7_$NAME at +00:20:00 set Sonos_Schlafzimmer Volume 9";
fhem "define atTmp_8_$NAME at +00:23:00 set Sonos_Schlafzimmer Volume 15";
}
}
##-----------------------------------------------------------------------------
## END WAKE-UP PROGRAM (OPTIONAL)
## Put some post wake-up tasks here like reminders after the actual wake-up period.
##
## Note: Will only be run when program ends normally after minutes specified in wakeupOffset.
## If stop was user-forced by sending explicit set-command 'stop', this is not executed
## assuming the user does not want any further automation activities.
##
if ($EVTPART0 eq "stop") {
Log3 $NAME, 3, "$NAME: Wake-up program ended for $EVTPART4 with target time $EVTPART1. Current state: $EVTPART5";
# if wake-up should be enforced, auto-change user state from 'asleep' to 'awoken'
# after a small additional nap to kick you out of bed if user did not confirm to be awake :-)
# An additional notify for user state 'awoken' may take further actions
# and change to state 'home' afterwards.
if ($EVTPART3) {
fhem "define atTmp_9_$NAME at +00:05:00 set $EVTPART4:FILTER=STATE=asleep awoken";
# Without enforced wake-up, be jentle and just set user state to 'home' after some
# additional long nap time
} else {
fhem "define atTmp_9_$NAME at +01:30:00 set $EVTPART4:FILTER=STATE=asleep home";
}
}
}
Wenn das Radio normal läuft und ich bekomme eine durchsage funktioniert es dagegen
Andre
Klingt eher nach einem Sonos-Problem. Die Befehle während des Weckens werden sequenziell abgearbeitet, da kommt sich eher nichts gegenseitig ins Gehege. Im Falle der Sprachausgabe ist es auch egal, denn soweit ich weiß hat das Sonos Modul dafür eine Queue.
Mit der Sprachsynthese über Google TTS gibts aktuell auch größere Probleme, vielleicht hängt es auch eher damit zusammen. Siehe SONOS Thread (http://forum.fhem.de/index.php/topic,10033.0.html).
Die Sprachausgabe funktioniert ja nur halt wenn dieser Fall auftritt stopt der Player nicht.
Werde jetzt versuchen die Ansage mit in dein Script einzubauen so kommt
sich da nichts in die Quere.
Andre
Hallo,
so nachdem eigentlich alles prima lief, geht seit ein paar Wochen (Weiß nicht wie lange genau, da ich im Sommer nicht alles per Wecker steuere) irgendwie das wakeuptimer Makro nicht mehr korrekt. Ich komme dem einfach nicht auf die Spur. Gestern habe ich dann mal ein verbose 5 bei den einzelnen Bestandteilen gesetzt um vielleicht so etwas zu erkennen:
2015.11.18 04:00:00 5: exec at command at_rr_Sabine_wakeuptimer1
2015.11.18 04:00:00 4: dummy set rr_Sabine_wakeuptimer1 trigger
2015.11.18 04:00:00 4: RESIDENTStk rr_Sabine_wakeuptimer1: lastRun = nextRun = 04:30
2015.11.18 04:00:00 5: RESIDENTStk rr_Sabine_wakeuptimer1: wakeupWaitPeriod threshold reached (expLastRun=1444292999 nowRunSec=1447817400 expNextRun=1447710548 localtime=1447815600)
2015.11.18 04:00:00 4: RESIDENTStk rr_Sabine_wakeuptimer1: weekday restriction in conjunction with andHoliday in use - not triggering wake-up program this time
2015.11.18 04:00:00 4: RESIDENTStk rr_Sabine_wakeuptimer1: Resetting based on wakeupDefaultTime
2015.11.18 04:00:00 4: dummy set rr_Sabine_wakeuptimer1 nextRun 04:30
2015.11.18 04:00:00 5: redefine at command at_rr_Sabine_wakeuptimer1 as *{RESIDENTStk_wakeupGetBegin("rr_Sabine_wakeuptimer1","at_rr_Sabine_wakeuptimer1")} set rr_Sabine_wakeuptimer1 trigger
2015.11.18 04:00:00 4: RESIDENTStk rr_Sabine_wakeuptimer1: wakeupGetBegin source: nextRun
2015.11.18 04:00:00 4: RESIDENTStk rr_Sabine_wakeuptimer1: wakeupGetBegin result: 04:30 = 14400 s - 30 m = 04:00:00
Das Makro "Macro_rr_Sabine_wakeuptimer1" wird wie man sieht nicht ausgeführt, nicht einmal Log-Anweisungen darin werden ausgegeben. Ich sehe die Meldung im Log von "weekday restriction in conjunction with andHoliday..." aber verstehe sie nicht wirklich. Ist das hier das Problem? Kann ich keinen Wecker mehr (weil das nicht geändert wurde) setzen der nur an bestimmen Werktagen aktiv ist UND an holiday=TRUE?
Oder suche ich an der falschen Stelle?
Hallo,
so nachdem ich gestern den WakeupTimer mal umgestellt habe auf
- Days: 1,2,3,4
- WakeUpHolidays: orHoliday (vorher andHoliday)
führt FHEM den Wecker wieder aus. Allerdings weiß ich nicht weshalb ein "andHoliday" den Wecker blockieren sollte. Das widerspricht sich doch nicht.
doch, weil neben Mo-Do zusätzlich einer dieser Tage auch ein Feiertag sein muss (deshalb heisst es and ;-)).
Bei orHoliday muss nur eines von beidem zutreffen
Gruß
Julian
Ist ja eigentlich auch logisch, weshalb ich das wohl mal so eingestellt hatte, bleibt ein Rätsel. :-X
Danke!
Nabend,
danke ist eine tolle Idee und Umsetzung.
Leider scheint mein System nicht 100% zu funktionieren.
Bisher meldet das Sonos-Gerät immer nur die Weckzeit ist auf 0:00 Uhr eingestellt.
Aber in der Anzeigt wird der eingestellt Wert angezeigt.
Wie kann ich diesen Fehler beseitigen und an welcher Stelle mit ich ggf. etwas miloggen?
Und wie könnte ich ,,asleep" und ,,awoken" dauerhaft in die Auswahlliste bekommen?
Danke
Gruß aherby
Ich habe den Wecker auch implementiert und er funktioniert hervorragend, vielen Dank schon einmal :).
Ich habe jedoch noch ein kleines Problem...der Wecker referenziert auf mein Roommate-Objekt, welches mittels geofancy auf home, gone etc. gestellt wird.
Wenn ich nun jedoch nicht zuhause bin, geht der Wecker ja logischerweise nicht an, da der Wecker ja nicht auf das Roommate-Objekt meiner Frau referenziert.
Besteht eine Möglichkeit, dass der Wecker beide Roommate-Objekte berücksichtigt oder der Wecker auf das Residents-Objekt reagiert, welches bei einer anwesenden Person ja einen entsprechenden Status hat?
Vielen Dank,
Dennis
Hallo Dennis,
Wie alt ist Dein FHEM? Hast Du ein aktuelles? Es gibt einige User inklusive mir, welche Probleme mit dem Wecker haben.
http://forum.fhem.de/index.php/topic,47338.0.html
Ich hatte in letzter Zeit auch ein paar Probleme, hab den Wecker dann einfach neu angelegt und soweit funktioniert er wieder. Das Verhalten, was ich beschrieben habe ist ja auch normal und ich denke auch so gewollt, ich würde das Standardverhalten gerne ein bisschen verändern / drehen.
Gruß,
Dennis
Zitat von: dennis87 am 14 Januar 2016, 13:00:18
Wenn ich nun jedoch nicht zuhause bin, geht der Wecker ja logischerweise nicht an, da der Wecker ja nicht auf das Roommate-Objekt meiner Frau referenziert.
Besteht eine Möglichkeit, dass der Wecker beide Roommate-Objekte berücksichtigt oder der Wecker auf das Residents-Objekt reagiert, welches bei einer anwesenden Person ja einen entsprechenden Status hat?
Gedacht ist es so, dass jede Person ihren eigenen Wecker hat. Deine Frau sollte also ein eigenes ROOMMATE Objekt haben und für dieses einen Wakeuptimer anlegen. Ihr Wakeuptimer und dein Wakeuptimer können aber das selbe Macro verwenden (einfach das Attribut wakeupMacro entsprechend abändern, das zweite Macro-Template kann man dann wieder löschen), damit man ein Weckprogramm zentral programmieren kann.
Man muss sich dabei aber natürlich überlegen was es bedeutet, wenn das Programm ggf. mehrfach/parallel ausgeführt wird, weil jede Person einen eigenen Wecker hat. Oft ist es deshalb trotzdem leichter einzelne Makros zu pflegen, damit man dort ein paar wenn-dann-sonst Regeln einbauen kann. Also zB dafür, wenn die Weckmusik schon durch den anderen Wecker angeschaltet wurde und man keine Unterbrechung o.ä. möchte.
Ich überlege mal, ob man bei Nutzung des selben Macros noch zentral ein paar Abfragen einbauen kann, damit es dann nicht doppelt ausgeführt wird. Der Anwendungsfall wäre aber sehr speziell (und diskriminierend, wenn dann nur der "Mann" einen Wecker hat und die "Frau" dann gefälligst zur selben Zeit aufzustehen hat, weil sie keinen eigenen Wecker hat; gilt natürlich auch umgekehrt ;D ). Das wäre dann wohl eher für Paare, die sich wie Zwillinge verhalten und nix alleine machen können/wollen... (den konnt ich mir nicht verkneifen, sorry ;) )