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

Begonnen von Loredo, 19 Januar 2014, 23:12:34

Vorheriges Thema - Nächstes Thema

moskito

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

Gruß
Danny
FHEM auf Intel NUC/Proxmox & Debian 12 + HM-CFG-USB + zigbee2mqtt + Zwave + Enocean

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
Jessie@RasPi 3, nanoCUL868 (SlowRF), nanoCUL868 (HM), nanoCUL433 (IT)

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
Jessie@RasPi 3, nanoCUL868 (SlowRF), nanoCUL868 (HM), nanoCUL433 (IT)

Loredo

Zitat von: Chris76FiSi am 29 März 2017, 18:31:41
@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
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

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
Wissen ist Macht.
Ich weiß nix.
Macht nix.

Loredo

Da warst du etwas zu schnell, ist bereits gefixt. Habe den DL-Link aktualisiert.
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

l2r

Wissen ist Macht.
Ich weiß nix.
Macht nix.

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

CoolTux

Hallo Julian,

Welche genau sind das?

wd_rr_Steven_asleep
wd_rr_Steven_gotosleep
wd_rr_Steven_awoken

Und so???
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Loredo

Ja genau die.
Ich traue mich gerade nicht daran die ganzen Watchdog- und at-Devices alle in ein einzelnes DOIF zusammenzufassen. DamalsTM 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... :-)
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

CoolTux

Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

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


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


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

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

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