Meine Weckautomation

Loredo · 01 April 2015, 23:23:32

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).

rretsiem · 01 April 2015, 23:46:22

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

Code Auswählen


attr rr_Julian_wakeuptimer1 wakeupEnforced 1

heißen? Zumindest gibt es ein wakeupEnfore attribut.

Kuzl · 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.

mrbreil · 02 April 2015, 13:46:39

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

rretsiem · 04 April 2015, 00:01:15

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.

Loredo · 04 April 2015, 11:05:07

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?

rretsiem · 04 April 2015, 20:52:35

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?

Loredo · 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

Kuzl · 04 April 2015, 21:07:11

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

Loredo · 04 April 2015, 21:11:07

Cool, darüber ließe sich auch der wakeuptimer Dummy setzen.
Lebe allerdings lieber im i-Universum, schade also

rretsiem · 04 April 2015, 23:04:57

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:

Code Auswählen


rgr_Residents:asleep 00:00:03 rgr_Residents:(home|absent|gone|none|gotosleep|awoken) trigger Macro_rgr_Residents_asleep

muss dann so aussehen?

Code Auswählen


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?

Loredo · 05 April 2015, 10:14:36

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

rretsiem · 07 April 2015, 22:55:31

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:

Code Auswählen

# $Id: 10_RESIDENTS.pm 8376 2015-04-05 08:16:49Z loredo $

Loredo · 07 April 2015, 23:49:00

Hm da war wohl noch ein Tippfehler, den ich gerade korrigiert habe...

rretsiem · 08 April 2015, 10:09:24

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:

Code Auswählen


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.