Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST

[moskito]

Auch bei mir meldet das Modul die "weekday restriction" - sogar wenn ich die Attribute "wakeupDays" und "wakeupHolidays" entferne.

Gruß
Danny

[Chris76FiSi]

Hallo zusammen,

auch bei mir funktionieren seit Montag die WakeUp-Timer nicht mehr. Habe gestern extra zum Test einen neuen zusätzlichen WakeUp-Timer erstellt, da ich hier im Forum noch nichts zu diesem Fehler gefunden hatte. Egal was ich auch mache, ich erhalte immer wieder den Fehler "weekday restriction in use - not triggering wake-up program this time".
Anbei ein Auszug aus dem Log mit Verbose 5:

2017.03.28 19:39:00 4: dummy set rr_Christian_wakeuptimer3 trigger
2017.03.28 19:39:00 4: RESIDENTStk rr_Christian_wakeuptimer3: lastRun = nextRun = 19:40
2017.03.28 19:39:00 4: RESIDENTStk rr_Christian_wakeuptimer3: weekday restriction in use - not triggering wake-up program this time
2017.03.28 19:39:00 4: RESIDENTStk rr_Christian_wakeuptimer3: Wakeuptime recalculation triggered by at-device at_rr_Christian_wakeuptimer3
2017.03.28 19:39:00 4: RESIDENTStk rr_Christian_wakeuptimer3: wakeupGetBegin source: nextRun
2017.03.28 19:39:00 4: RESIDENTStk rr_Christian_wakeuptimer3: wakeupGetBegin result: 19:40 = 70740 s - 1 m = 19:39:00

Viele Grüße, Chris

[Chris76FiSi]

Hi zusammen,

habe mir im SVN mal die letzten Änderungen angesehen und bin auf folgende Syntax gestoßen:
!grep { $wday eq $_ } @days (kommt in Summe 3x vor).

Dies habe ich nun bei mir im Modul RESIDENTStk.pm ersetzt durch
!( grep { $wday eq $_ } @days ).

Und siehe da, es funktioniert

@Loredo: vielleicht solltest Du Dir die Zeilen 1052, 1062 und 1077 nochmal anschauen

Viele Grüße, Chris

[Loredo]

@Loredo: vielleicht solltest Du Dir die Zeilen 1052, 1062 und 1077 nochmal anschauen

Danke, das sowas aber auch an Klammern scheitern muss... 
Habe inzwischen eine etwas andere Variante implementiert.

Außerdem konnte ich bei dem Deep-Dive jetzt auch herausfinden, weshalb Sonntags die Vorhersage für den nächsten Wecker am Montag nicht stimmt. Das sollte jetzt auch behoben sein.
Außerdem behoben: Wenn der nächste Wecker nicht innerhalb der nächsten 24 Stunden gesetzt ist, werden die Readings nextWakeup und nextWakeupDev jetzt korrekt auf "OFF" respektive "" gesetzt.

Wer morgen wieder richtig geweckt werden will und nicht auf das morgige Update warten möchte:
https://svn.fhem.de/trac/export/13851/trunk/fhem/FHEM/RESIDENTStk.pm



Gruß
Julian

[l2r]

Danke fürs schnelle ändern.habe mir die aktuelle Version aus dem SVN gezogen. Gerade als ich schlafen gehen wollte habe ich die Weckzeit minus dem eingestellten Offset angesagt bekommen. Gewollt oder bug?
Ich werde morgen früh berichten, wann ich geweckt wurde.

Gruß Michael

[Loredo]

Da warst du etwas zu schnell, ist bereits gefixt. Habe den DL-Link aktualisiert.

[l2r]

alles klar, danke ;-)

Gruß Michael

[Loredo]

Bei der Untersuchung des Wakeuptimers ist mir aufgefallen, dass "setstate watchdog defined" wohl nicht mehr dafür funktioniert, um die für die Weckfunktion verwendeten Watchdogs wieder zurückzusetzen. Das führt (bei mir) dazu, dass die Statuswechsel der ROOMMATE und GUEST Geräte nicht mehr richtig vom Weckprogramm gesteuert werden und das ROOMMATE Device z.B. im Status "awoken" hängen bleibt statt auf "home" zu wechseln.


Da es laut diesem Beitrag keine offizielle Funktion zu sein scheint und es inzwischen das Attribut autoReset gibt, habe ich die Templates entsprechend umgebaut. Bestehende Watchdogs, die für den Wakeuptimer bereits erstellt wurden, muss man allerdings einmalig händisch entsprechend anpassen.

[CoolTux]

Hallo Julian,

Welche genau sind das?

wd_rr_Steven_asleep
wd_rr_Steven_gotosleep
wd_rr_Steven_awoken

Und so???

[Loredo]

Ja genau die.
Ich traue mich gerade nicht daran die ganzen Watchdog- und at-Devices alle in ein einzelnes DOIF zusammenzufassen. Damals^TM gab es noch kein DOIF 
Das steht schon länger auf der Todo Liste, aber bedarf halt doch einiger Tests und vermutlich auch einiger Änderungen. Da die Tests für den Wecker aber so langwierig und aufwändig sind, ist das bisher noch so geblieben. Aber wenn sich jemand berufen fühlt hier ein DOIF zu basteln, was alles ersetzen und zusammenfassen kann... :-)

[CoolTux]

Bitte bitte kein DOIF. Das tut nicht Not

[peter0255]

Hallo Loredo,

hab ich das richtig verstanden, ich muß bei
wd_rr_Peter_asleep
wd_rr_Peter_gotosleep
wd_rr_Peter_awoken
 das attr. autoRestart auf 1 setzen ?

Viele Grüße Peter

[Loredo]

Genau. Optimalerweise änderst du die DEF noch so um, dass der setstate Befehl am Ende wegfällt.

Also aus

Code: [Auswählen]

defmod wd_rr_Son_asleep watchdog rr_Son:asleep 00:00:04 rr_Son:(home|absent|gone|none|gotosleep|awoken) trigger Macro_rr_Son_asleep; setstate wd_rr_Son_asleep defined

wird

Code: [Auswählen]

defmod wd_rr_Son_asleep watchdog rr_Son:asleep 00:00:04 rr_Son:(home|absent|gone|none|gotosleep|awoken) trigger Macro_rr_Son_asleep
attr wd_rr_Son_asleep autoRestart 1


[peter0255]

Hallo Loredo,

vielen Dank für Deine tolle Unterstützung.

Gruß
Peter

[Loredo]

Man kann es sich übrigens auch einfacher machen und alle at_r.* und wd_r.* Devices löschen. Sie werden beim nächsten stellen des Timers dann neu angelegt.
Wer das vor hat, dem sei geraten auf das morgige Update zu warten. Dort sind Anpassungen für die Unterstützung der deutschen Sprache enthalten, sofern man seine Devices über das r*_lang Attribut eingedeutscht hat.