Hallo zusammen,
nachdem WeekdayTimer jetzt schon eine ganze Weile meinereinen als Maintainer hat, Heating_Control ausgephast ist und manche Teile von Twilight irgendwie immer noch in der Codebasis drin sind, ist es jetzt an der Zeit, auch den Thread "Neues Modul - Heating_Control, WeekdayTimer" mal in Rente zu schicken und einen neuen anzufangen...
Dieser Thread soll also zukünftig als erste Anlaufstelle für den WeekdayTimer werden, und anfangen möchte ich zum einen mit einer Testversion, die einen Syntaxcheck bei der DEF beinhaltet (zum aktuellen Anlass siehe https://forum.fhem.de/index.php/topic,114131.0.html (https://forum.fhem.de/index.php/topic,114131.0.html)). Wäre also nett, wenn jemand das austesten will, sonst checke ich das wie immer "irgendwann" mal ein ;) .
Bei Gelegenheit werde ich dann auch den WeekdayTimer vermutlich in ein package-Format packen, wer also derzeit noch mit Heating_Control unterwegs ist, sollte möglichst zeitnah umstellen, denn wenn das gemacht ist, wird dieses Modul nicht mehr funktionieren.
Grüße,
Beta-User
Bisher alles ok.
Viele Grüße
Jürgen
Danke für die Rückmeldung, hab's dann mal eingecheckt (es gab jüngst wieder so eine DEF, bei der der Check evtl. geholfen hätte...).
Danke, Fehler gefunden! Syntaxprüfung funktioniert!
Hallo,
ich nutze schon lange Zeit Weekdaytimer (vorher HeatingControl) zur Steuerung meiner Homematic Thermostate. Dazu habe ich pro Thermostat unterschiedliche Timer angelegt, die abhängig von Parametern wie "Homeoffice", "Büro", "Urlaub zuhause" etc. bezüglich einzelner Bewohner greifen.
Nun ist mir letztens aufgefallen, dass die jeweils letzten Schaltpunkte am Tag manchmal nicht stattfinden. Auf der Suche nach einer Lösung fand ich die Threads:
https://forum.fhem.de/index.php/topic,105571.msg994968.html#msg994968 (https://forum.fhem.de/index.php/topic,105571.msg994968.html#msg994968)
https://forum.fhem.de/index.php/topic,104167.0/all.html (https://forum.fhem.de/index.php/topic,104167.0/all.html)
https://forum.fhem.de/index.php/topic,104272.0/all.html#lastPost (https://forum.fhem.de/index.php/topic,104272.0/all.html#lastPost)
Dort fand ich meine Probleme wieder, jedoch keine Lösung dazu.
Auch in der aktuellen Version
# $Id: 98_WeekdayTimer.pm 24285 2021-04-20 06:02:27Z Beta-User $
existiert das Problem noch.
Nun habe ich testweise den Rat befolgt und in der letzten Woche zusätzliche Schaltpunkte 10 Minuten nach der geplanten Zeit angelegt, jedoch nur für Mo-Fr, den Sa und So habe ich bei nur einem Zeitschaltpunkt abends belassen.
Internals:
COMMAND
CONDITION (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Micha.Status","state", "") eq "Büro" and ReadingsVal("sc.Silke.Status","state", "") eq "Homeoffice")
DEF struct.Heizung.st.Schlafzimmer 12345|14:01:00|day 12345|21:31:00|night 12345|21:41:00|night 60|07:01:00|day 60|21:31:00|night (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Micha.Status","state", "") eq "Büro" and ReadingsVal("sc.Silke.Status","state", "") eq "Homeoffice")
DEVICE struct.Heizung.st.Schlafzimmer
FUUID 60868de4-f33f-c765-0cb9-a9be825d1ffad321
GlobalDaylistSpec
LANGUAGE en
NAME hc.st.Schlafzimmer.SH.MB
NR 1791
Profil 0: Sunday 07:01:00 day, 21:31:00 night,
Profil 1: Monday 14:01:00 day, 21:31:00 night, 21:41:00 night,
Profil 2: Tuesday 14:01:00 day, 21:31:00 night, 21:41:00 night,
Profil 3: Wednesday 14:01:00 day, 21:31:00 night, 21:41:00 night,
Profil 4: Thursday 14:01:00 day, 21:31:00 night, 21:41:00 night,
Profil 5: Friday 14:01:00 day, 21:31:00 night, 21:41:00 night,
Profil 6: Saturday 07:01:00 day, 21:31:00 night,
SETTIMERATMIDNIGHT 1
STATE night
STILLDONETIME 0
TYPE WeekdayTimer
setModifier desired-temp
READINGS:
2021-05-11 07:09:00 currValue night
2021-04-26 11:54:44 disabled 0
2021-05-11 07:09:00 nextUpdate 2021-05-11 14:01:00
2021-05-11 07:09:00 nextValue day
2021-05-11 07:09:00 state night
SWITCHINGTIMES:
12345|14:01:00|day
12345|21:31:00|night
12345|21:41:00|night
06|07:01:00|day
06|21:31:00|night
TIMER:
hc.st.Schlafzimmer.SH.MB_1:
HASH hc.st.Schlafzimmer.SH.MB
MODIFIER 1
NAME hc.st.Schlafzimmer.SH.MB_1
hc.st.Schlafzimmer.SH.MB_2:
HASH hc.st.Schlafzimmer.SH.MB
MODIFIER 2
NAME hc.st.Schlafzimmer.SH.MB_2
hc.st.Schlafzimmer.SH.MB_3:
HASH hc.st.Schlafzimmer.SH.MB
MODIFIER 3
NAME hc.st.Schlafzimmer.SH.MB_3
helper:
daysRegExp (su|mo|tu|we|th|fr|sa|\$we|\!\$we)
daysRegExpMessage (su|mo|tu|we|th|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
07:01:00 day
21:31:00 night
1:
14:01:00 day
21:31:00 night
21:41:00 night
2:
14:01:00 day
21:31:00 night
21:41:00 night
3:
14:01:00 day
21:31:00 night
21:41:00 night
4:
14:01:00 day
21:31:00 night
21:41:00 night
5:
14:01:00 day
21:31:00 night
21:41:00 night
6:
07:01:00 day
21:31:00 night
WEDAYS:
4 1
5 1
profil:
1:
EPOCH 1620734460
PARA day
TIME 14:01:00
WE_Override 0
TAGE:
1
2
3
4
5
2:
EPOCH 1620761460
PARA night
TIME 21:31:00
WE_Override 0
TAGE:
1
2
3
4
5
3:
EPOCH 1620762060
PARA night
TIME 21:41:00
WE_Override 0
TAGE:
1
2
3
4
5
4:
EPOCH 1620709260
PARA day
TIME 07:01:00
WE_Override 0
TAGE:
0
6
5:
EPOCH 1620761460
PARA night
TIME 21:31:00
WE_Override 0
TAGE:
0
6
profile_IDX:
0:
07:01:00 4
21:31:00 5
1:
14:01:00 1
21:31:00 2
21:41:00 3
2:
14:01:00 1
21:31:00 2
21:41:00 3
3:
14:01:00 1
21:31:00 2
21:41:00 3
4:
14:01:00 1
21:31:00 2
21:41:00 3
5:
14:01:00 1
21:31:00 2
21:41:00 3
6:
07:01:00 4
21:31:00 5
Attributes:
WDT_Group former_HC
WDT_delayedExecutionDevices hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts
commandTemplate set $NAME controlMode $EVENT
comment struct.Heizung.st.Schlafzimmer 12345|14:01:00|day 12345|21:31:00|night 60|07:01:00|day 60|21:31:00|night (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Micha.Status","state", "") eq "Büro" and ReadingsVal("sc.Silke.Status","state", "") eq "Homeoffice")
disable 0
room Heizung
switchInThePast 1
Das Ergebnis ist gemischt:
Freitag funktionierte der Schaltpunkt erwartungsgemäß um 21:31 (war ja die vorletzte Zeit), am Samstag wurde jedoch auch um 21:31 geschaltet, obwohl dies der letzte Zeitpunkt am Tag war.
Am Sonntag (ebenfalls nur ein Punkt) funktionierte es wieder nicht, am Montag hingegen erwartungsgemäß schon (war ja der vorletzte Zeitpunkt).
Ich bekomme keine Regelmäßigkeit hin.
FHEM wurde letztmalig am 01.05. neu gestartet. Morgens um 03:55 lasse ich ein
set hc..* enable
ausführen, da gelegentlich eine Statusänderung (Homeoffice/Büro/Urlaub) erst nach 00:00 durchgeführt wird.
Zur Analyse hatte ich den verbose-Level zeitweise auf 5 gesetzt, erhielt aber keine Einträge für die nicht durchgeführten Schaltvorgänge.
Was kann ich zur weiteren Eingrenzung noch versuchen?
Hmm, war eigentlich davon ausgegangen, dass das Problem gelöst gewesen wäre...
Um es einzukreisen:
- kannst du bitte möglichst die Testversion aus hier benutzen: https://forum.fhem.de/index.php/topic,111401.msg1154753.html#msg1154753
Da ist insbesondere die Timerverwaltung für "delayed" geändert, könnte sein, dass das auch einen Einfluss hatte.
- Bitte zum Testen die "doppelten" Schaltpunkte möglichst draußen lassen, das muss am Ende so gehen.
- Welche Timer angelegt wurden, sollte via "fhemdebug timerList" rauszubekommen sein. Für jeden aktiven WDT und jeden noch in der Zukunft liegenden Schaltpunkt müßte ein Timer vorhanden sein.
- Ist zum Schaltpunkt der Zielzustand schon erreicht (egal, warum), führt der WDT den Befehl nicht aus. Vielleicht war auch das der Fall (müßte mal schauen, ob dann was nei höherem verbose im Log stehen sollte und ggf. was einbauen?)?
Ok,
ich werde die Version heute einspielen und auch die doppelten Schaltpunkte entfernen.
Zum Schaltpunkt war der Zielzustand definitiv nicht erreicht, das sehe ich im Log der Thermostate.
Das delayedExecutionDevice (Fensterkontakt) ist zum Schaltzeitpunkt nie aktiv, allerdings zum Zeitpunkt des
set hc..* enable
um 03:55 immer.
Ich werde berichten...
So, hier einmal die ersten Erkenntnisse:
Die Version habe ich am 11.05. nachmittags eingespielt und der Timer um 21:31 hat funktioniert:
2021-05-11_21:23:19 hm.wt.st.Schlafzimmer measured-temp: 19.3
2021-05-11_21:31:00 hm.wt.st.Schlafzimmer commState: CMDs_pending
2021-05-11_21:31:00 hm.wt.st.Schlafzimmer CMDs_pending
2021-05-11_21:31:00 hm.wt.st.Schlafzimmer commState: CMDs_processing...
2021-05-11_21:31:01 hm.wt.st.Schlafzimmer desired-temp: 17.0
2021-05-11_21:31:01 hm.wt.st.Schlafzimmer commState: CMDs_done
2021-05-11_21:31:01 hm.wt.st.Schlafzimmer CMDs_done
Am 12.05. gegen 18:30 wurde der Status geändert (von "Homeoffice" auf "Urlaub"), so dass ein anderer WeekdayTimer hätte greifen sollen, allerdings fand bis zum fraglichen Zeitpunkt absichtlich kein "set enable" statt. Das Ergebnis war, dass nicht geschaltet wurde, der "Homeoffice"-Timer war aktiv, der "Urlaub"-Timer war inaktiv. Zum Schaltzeitpunkt des "Homeoffice"-Timers trafen die Bedingungen nicht mehr zu, daher war diese Reaktion zu erwarten.
Nun sollten ja um 00:00 durch das Modul die Timer neu gesetzt werden, was im State der WeekdayTimer auch funktionierte. "Homeoffice" ist inaktiv, "Urlaub" ist aktiv. Der fragliche Timer sieht folgenderweise aus:
Internals:
COMMAND
CONDITION (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Silke.Status", "state", "") eq "Urlaub" and ReadingsVal("sc.Micha.Status", "state", "") eq "Urlaub")
DEF struct.Heizung.st.Schlafzimmer 1234560|07:01:00|day 1234560|21:31:00|night (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Silke.Status", "state", "") eq "Urlaub" and ReadingsVal("sc.Micha.Status", "state", "") eq "Urlaub")
DEVICE struct.Heizung.st.Schlafzimmer
FUUID 5de97613-f33f-c765-6749-85e684e94177744a
GlobalDaylistSpec
LANGUAGE en
NAME hc.st.Schlafzimmer.SU.MU
NR 1634
Profil 0: Sunday 07:01:00 day, 21:31:00 night,
Profil 1: Monday 07:01:00 day, 21:31:00 night,
Profil 2: Tuesday 07:01:00 day, 21:31:00 night,
Profil 3: Wednesday 07:01:00 day, 21:31:00 night,
Profil 4: Thursday 07:01:00 day, 21:31:00 night,
Profil 5: Friday 07:01:00 day, 21:31:00 night,
Profil 6: Saturday 07:01:00 day, 21:31:00 night,
SETTIMERATMIDNIGHT 1
STATE day
STILLDONETIME 0
TYPE WeekdayTimer
setModifier desired-temp
READINGS:
2021-05-13 08:58:00 currValue day
2021-01-13 14:42:26 disabled 0
2021-05-13 08:58:00 nextUpdate 2021-05-13 21:31:00
2021-05-13 08:58:00 nextValue night
2021-05-13 08:58:00 state day
SWITCHINGTIMES:
0123456|07:01:00|day
0123456|21:31:00|night
TIMER:
hc.st.Schlafzimmer.SU.MU_1:
HASH hc.st.Schlafzimmer.SU.MU
MODIFIER 1
NAME hc.st.Schlafzimmer.SU.MU_1
hc.st.Schlafzimmer.SU.MU_delayed:
HASH hc.st.Schlafzimmer.SU.MU
MODIFIER delayed
NAME hc.st.Schlafzimmer.SU.MU_delayed
helper:
daysRegExp (su|mo|tu|we|th|fr|sa|\$we|\!\$we)
daysRegExpMessage (su|mo|tu|we|th|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
07:01:00 day
21:31:00 night
1:
07:01:00 day
21:31:00 night
2:
07:01:00 day
21:31:00 night
3:
07:01:00 day
21:31:00 night
4:
07:01:00 day
21:31:00 night
5:
07:01:00 day
21:31:00 night
6:
07:01:00 day
21:31:00 night
WEDAYS:
2 1
3 1
profil:
1:
EPOCH 1620882060
PARA day
TIME 07:01:00
WE_Override 0
TAGE:
0
1
2
3
4
5
6
2:
EPOCH 1620934260
PARA night
TIME 21:31:00
WE_Override 0
TAGE:
0
1
2
3
4
5
6
profile_IDX:
0:
07:01:00 1
21:31:00 2
1:
07:01:00 1
21:31:00 2
2:
07:01:00 1
21:31:00 2
3:
07:01:00 1
21:31:00 2
4:
07:01:00 1
21:31:00 2
5:
07:01:00 1
21:31:00 2
6:
07:01:00 1
21:31:00 2
Attributes:
WDT_Group former_HC
WDT_delayedExecutionDevices hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts
commandTemplate set $NAME controlMode $EVENT
disable 0
room Heizung
switchInThePast 1
Der Zeitpunkt um 21:31 scheint gesetzt zu sein.
Aber ein "fhemdebug timerList" liefert folgendes Ergebnis:
2021-05-13 21:07:08.00000 RT_Exec
2021-05-13 21:07:08.00000 RT_Exec
2021-05-13 21:07:08.00000 RT_Exec
2021-05-13 21:24:40.00000 DOIF_TimerTrigger
2021-05-13 21:24:40.00000 WeekdayTimer_Update
2021-05-13 21:24:40.00000 WeekdayTimer_Update
2021-05-13 21:39:40.00000 DOIF_TimerTrigger
2021-05-13 21:39:40.00000 DOIF_TimerTrigger
2021-05-13 21:39:40.00000 WeekdayTimer_Update
2021-05-13 21:39:40.00000 WeekdayTimer_Update
2021-05-13 21:39:40.00000 WeekdayTimer_Update
2021-05-13 21:39:40.00000 WeekdayTimer_Update
2021-05-13 21:50:00.00000 DOIF_TimerTrigger
2021-05-13 21:54:39.98000 Twilight_fireEvent
Der Zeitpunkt 21:31 ist nicht geplant (21:24 und 21:39 sind Timer für Rollladen), und das hätte doch jetzt sein müssen, oder?
Verstehe ich das richtig, dass du davon ausgehst, dass "CONDITION" zu jedem Ausführungszeitpunkt geprüft wird?
Ich meine, das wäre nicht der Fall: CONDITION wird - soweit ich das im Kopf habe - schon immer nur beim "Tageswechsel" geprüft. Trifft sie nicht zu, ist der WDT für diesen Tag "außer Kraft". Müßte mir das auch nochmal intensiver ansehen, und die Doku dazu ist vermutlich auch nicht wirklich glücklich bzw. aussagekräftig genug.
Wenn du das "on th fly" haben willst, müsstest du die Auswertung in Perl notieren und dann am Ende selbst den set-Befehl zusammenbasteln, oder eben den "update"-Command hinter dem Wechsel des Modus herschicken, dass sich alle WDT umstellen.
(OT-Anmerkung: Vermutlich wäre das ganze mit der weekprofile-Variante einfacher zu machen; da wird bei jedem "Topic"-Wechsel dann einfach der (eine) WDT passend neu initialisiert; day + night müsstest du dann ggf. entweder im WDT mappen, oder (neuerdings) in weekprofile.)
EDIT: Aber trotzdem ist das nicht wirklich sinnvoll, einen Schaltzeitpunkt anzuzeigen und dann nichts zu tun bzw. den Timer nicht anzulegen; das muss ich mir wirklich nochmal intensiver zu Gemüte ziehen...
Das mit der Condition-Überprüfung würde zumindest ins Bild passen:
Der Homeoffice-Timer war für das Modul noch gesetzt, es wurde aber nichts geschaltet.
Eine Version mit set-Befehl und if-Abfrage hatte ich im April getestet, diese funktionierte aber nach zwei Wochen plötzlich nicht mehr zuverlässig (s. Screenshot).
Daraufhin, und weil ich die State-Übersicht wieder aktuell haben wollte, habe ich wieder zurück-geswitcht.
WeekProfile habe ich mir vor einiger Zeit nur flüchtig angeschaut, kann man denn darin auch variable Zeiten, abhängig von Readings eines Wecker-Dummies hinterlegen?
Ich habe das Verhalten der Condition-Überprüfung weiter beobachtet.
Dazu habe ich gestern nachmittag den Status der Bewohner auf "Büro" geändert ("SB" und "MB".
Danach habe ich ein:
set hc..* WDT_Params all
abgesetzt.
Der Timer für 21:31 wurde korrekt gesetzt:
2021-05-15 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SB.MB_4
Danach habe ich den Status zurück auf "Homeoffice" bzw. "Büro" ("SH" und "MB") gesetzt, aber kein WDT_Params angestoßen.
Der ursprünglich geplante Timer "SB.MB" blieb in der Liste stehen.
Um 21:31 wurde nichts geschaltet. Für mich ein Indiz, dass die Condition zum Schaltzeitpunkt überprüft wird.
Um 00:00 hätte turnusgemäß der neue Timer durch das Modul gesetzt werden müssen, das passierte jedoch nicht (vollständig):
2021-05-16 21:29:59.00000 DOIF_TimerTrigger
2021-05-16 21:29:59.00000 WeekdayTimer_Update wdt.duo.eg.Arbeitszimmer.Arbeit_1
2021-05-16 21:29:59.00000 WeekdayTimer_Update wdt.duo.eg.Arbeitszimmer.Urlaub.zuhause_1
2021-05-16 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-16 21:44:59.00000 DOIF_TimerTrigger
Der Timer "hc.eg.Kueche.SH.MB" (den hatte ich im WeekdayTimer mal testweise für diese Statuskombination auf 21:30:30 gesetzt) taucht auf, der erwartete "hc.st.Schlafzimmer.SH.MB" jedoch nicht. Der Fensterkontakt als "WDT_delayedExecutionDevice" wurde erst um 00:22 geöffnet.
Um 03:55 wurde ein geplantes "set hc..* enable" abgesetzt.
Habe eben ein update ins svn geschoben, von dem ich aber nicht ganz sicher bin, ob es dieses Problem auch behebt.
Da war auf alle Fälle in der Testversion noch eine "komische" Zeile betreffend "zurückgehaltene Timer" drin gewesen.
Ansonsten hast du vermutlich recht, die CONDITION wirkt sich hier anders aus als im RandomTimer.
Meine Bitte wäre daher, die InternalTimer nach dem update auch die kommenden Tage immer mal wieder gegenzuchecken, ob alle erwarteten auch gesetzt sind.
Werde ich heute abend einspielen und berichten.
Kleiner Nachtrag von gestern/heute:
Am 17.05. waren beide Timer 21:30:30 und 21:31:00 gesetzt und wurden ausgeführt, ohne eine Änderung fehlt in der heutigen TimerList allerdings der Schaltpunkt für das Schlafzimmer:
2021-05-18 21:14:30.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-18 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-18 21:33:26.00000 DOIF_TimerTrigger
2021-05-18 21:33:26.00000 WeekdayTimer_Update wdt.duo.eg.Arbeitszimmer.Arbeit_1
Wie geschrieben: In der Testversion aus dem anderen Thread war noch was drin, das v.a. bei verzögerten Timern nicht passen konnte, und das Problem scheint nur aufgetreten zu sein, wenn man den WDT "in Ruhe" über Mitternacht hinaus laufen läßt (und es ein "switch in the past"-Gerät ist, wenn ich das richtig deute).
Bei meinem letzten Test hatte das funktioniert, allerdings ist meine Umgebung vermutlich deutlich einfacher, so dass eventuelle wechselseitigen Abhängigkeiten hier nicht so sehr reinspielen können. Bin dann mal auf deine Berichte ab morgen (mit der svn-Version) gespannt.
Hier die vorläufigen Erkenntnisse:
gestern Nachmittag habe ich die aktuelle Version eingespielt:
98_WeekdayTimer.pm 24466 2021-05-18 05:26:03Z
Nach einem Neustart wurden die Timer auch ordnungsgemäß angelegt:
2021-05-18 21:14:30.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-18 21:17:45.00000 netatmo_refreshTokenTimer netatmo
2021-05-18 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-18 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SH.MB_2
2021-05-18 21:33:26.00000 DOIF_TimerTrigger
2021-05-18 21:33:26.00000 WeekdayTimer_Update wdt.duo.eg.Arbeitszimmer.Urlaub.zuhause
und problemlos ausgeführt.
Das sieht leider heute anders aus, es wurde keinerlei Änderung bzgl. der Parameter vorgenommen, aber es fehlt wieder der Timer für das Schlafzimmer:
2021-05-19 21:15:56.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Micha
2021-05-19 21:15:56.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-19 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-19 21:35:08.00000 DOIF_TimerTrigger
2021-05-19 21:35:08.00000 WeekdayTimer_Update wdt.duo.eg.Arbeitszimmer.Arbeit_1
2021-05-19 21:35:08.00000 WeekdayTimer_Update
Hab' noch einen Ansatzpunkt gefunden, werde aber erst mal über Nacht einen Test in meinem Hauptsystem laufen lassen, bevor ich das auf jemanden anderen loslasse...
OK, sah' soweit gut aus (wie vorher auch schon...), von daher würde ich dich nochmal um einen "overnight"-Test mit der Version aus dem heutigen update (ab 8:00 Uhr) bitten.
Schade, sah erst gut aus:
20.05. 17:50 nach Update und Reboot:
2021-05-20 21:17:20.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-20 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-20 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SH.MB_2
2021-05-20 21:36:49.00000 DOIF_TimerTrigger
21.05. 00:00 nach automatischem Timer-Setzen:
2021-05-21 21:18:42.97000 Twilight_fireEvent_MyTwilight_ss
2021-05-21 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-21 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SH.MB_2
2021-05-21 21:36:49.00000 DOIF_TimerTrigger
Aber dann:
21.05. 06:08 (nach set hc..* enable um 03:55):
2021-05-21 21:18:43.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-21 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-21 21:38:29.00000 DOIF_TimerTrigger
Der Fensterkontakt im Schlafzimmer wurde um 23:47 geöffnet, damit scheint das "set hc..* enable" ein Problem zu haben...
Aha, also liegt das Problem nicht (mehr nur) in der "Initialisierung" um Mitternacht (da hatte ich es bisher verortet, und es kann auch sein, dass es da auch war), sondern "beschränkt" sich auf den Fall, dass es zu einer _vollständigen_ ("rückwärtsgewandten") Neuinitialisierung kommt, während "delay" angesagt ist.
So habe ich wenigstens Testbedingungen, mit denen ich das untersuchen kann und auch eine Idee, wieso das passiert. Muss nur überlegen, wie das am besten einzufangen ist...
Jetzt habe ich das soweit eingegrenzt, dass die ursprüngliche Annahme wieder stimmen würde, dass (CONDITION) dazu führt, dass der WDT den ganzen Tag über deaktiv ist, wenn die als falsch ausgewertet wird (und bei einer Aktualisierung dann auch alle Timer wieder abgeräumt werden sollten).
"Eigentlich" glaube ich, dass das das historische Verhalten war und von daher auch so wiederhergestellt werden sollte. Falls es massive Gegenstimmen gibt, würde ich mir das nochmal überlegen, aber das würde ggf. bedeuten, dass eigentlich ein intensiverer Umbau an ein paar Stellen erfolgen müßte (=> eher ungern).
Bitte um alsbaldige Meinungsäußerungen!
(Code füge ich keinen bei, denn das ist in Richtung "lib" umgebaut und daher nicht so einfach außerhalb der FHEM-update-Routinen zu machen wie sonst üblich).
Zitat von: Beta-User am 21 Mai 2021, 14:42:18
Bitte um alsbaldige Meinungsäußerungen!
Ich habe keine Einwaende.
Gruss Helmut
Zitat von: helmut am 21 Mai 2021, 20:28:28
Ich habe keine Einwaende.
Gruss Helmut
Fasse das mal als Rückmeldung eines sehr erfahrenen WeekdayTimer/Heating_Control-Nutzers und Bestätigung der These auf, dass das Verhalten "historisch" so war, dass CONDITION bei Tagesbeginn gecheckt werden sollte und sich auf diesen Tag auswirkt (und bei späteren Änderungen der Rahmenbedingungen der User für ein neuerliches "Anschubsen" des WDT zuständig sein soll) => ab ins svn...
Wäre nett, wenn ihr die korrekte Funktionsweise nach einem update nachher nochmal checken könntet. Ist jetzt nämlich direkt auch die "lib"-Version...
Hat leider nicht funktioniert:
22.05. 18:20 nach Update und Reboot:
2021-05-22 21:20:05.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-22 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-22 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SH.MB_4
2021-05-22 21:40:07.00000 DOIF_TimerTrigger
23.05. 00:00 nach automatischem Timer-Setzen:
2021-05-23 21:20:05.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-23 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-23 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SH.MB_4
2021-05-23 21:40:07.00000 DOIF_TimerTrigger
Dann habe ich den Status auf "SU" und "MU" gesetzt, bei denen nur das Schlafzimmer um 21:31 schalten soll (Küche entfällt):
23.05. 08:49 (nach set hc..* enable um 03:55):
2021-05-23 21:21:25.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Micha
2021-05-23 21:21:25.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-23 21:41:44.00000 DOIF_TimerTrigger
2021-05-23 21:41:44.00000 WeekdayTimer_Update wdt.duo.eg.Arbeitszimmer.Arbeit_1
Der Fensterkontakt im Schlafzimmer wurde um 02:06 geöffnet.
Zitat von: netwalk am 23 Mai 2021, 08:59:48
Der Fensterkontakt im Schlafzimmer wurde um 02:06 geöffnet.
Kann es sein, dass der Kontakt noch offen ist?
Wenn ja: Schau bitte nochmal, nachdem er geschlossen wurde.
Nachtrag: Falls er geschlossen wurde, müßte eine "skipped"-Meldung (verbose 3) im Log stehen. Wäre nett, wenn du das kurz verifizieren könntest. (Dann wäre das vermutlich kein wirklich neues Thema, sondern eher "schon immer" so (fehlerhaft) gewesen.)
Hmhh, der Fensterkontakt wurde auch um 08:49 geschlossen:
2021-05-23_08:49:12 hm.fk.st.Schlafzimmer.links contact: closed (to hm.wt.st.Schlafzimmer)
2021-05-23_08:49:12 hm.fk.st.Schlafzimmer.links closed
2021-05-23_08:49:12 hm.fk.st.Schlafzimmer.links SwitchTime: 08.49
2021-05-23_08:49:12 hm.fk.st.Schlafzimmer.links onoff: 0
2021-05-23_08:49:13 hm.fk.st.Schlafzimmer.links contact: closed (to hm.hr.st.Schlafzimmer)
2021-05-23_08:49:13 hm.fk.st.Schlafzimmer.links contact: closed (to VCCU)
Ob er zum Zeitpunkt des "fhemdebug timerList" (auch 08:49) noch geöffnet war, kann ich nicht genau sagen.
Jetzt ist er jedenfalls geschlossen, es hat sich aber nichts geändert:
2021-05-23 21:21:25.00000 RT_Exec rnd.li.eg.Garderobe
2021-05-23 21:21:25.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Micha
2021-05-23 21:21:25.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-23 21:41:44.00000 DOIF_TimerTrigger
2021-05-23 21:41:44.00000 WeekdayTimer_Update wdt.duo.eg.Arbeitszimmer.Arbeit_1
Im Log finde ich folgenden Eintrag (um 07:01 war der Kontakt offen):
2021.05.23 07:00:50 3: CUL_HM set hm.wt.st.Arbeitszimmer_Climate controlMode day
2021.05.23 07:01:00 3: [hc.st.Schlafzimmer.SU.MU] timer at 21:31:00 skipped by new timer at 07:01:00 while window contact returned open state
2021.05.23 07:02:30 3: CUL_HM set stat.eg.Arbeitszimmer_Dis displayEP A\_930\_977,noicon:W\_872,noicon:S\_1455\_07.02,noicon off 3 0 off
Thx, jetzt ist wenigstens klar, wann der Timer verloren geht: mit dem "skipped".
Wird etwas dauern, bis ich das fixen kann, als workaround kannst du den nach dem ersten Schaltzeitpunkt nochmal initialisieren.
Ok, dann werde ich die Intialisierung vorerst mehrmals am Tag durchführen lassen.
Vielen Dank.
Seit vorhin ist eine Version im svn, von der ich hoffe, dass das "skipped"-Problem damit dann auch gelöst ist...
War aber etwas zu spät für den regulären update-Lauf, ggf. dann eben aus dem svn direkt holen, falls du direkt testen willst...
Hallo,
ich nutze UZSU in Smartvisu um mehrere Weekdaytimer zu setzen. Wenn ich Sunset oder Sunrise nutze und eine Zeit bei spätesten UND frühestens einsetze, klappt es problemlos.
Wenn ich allerdings nur eine Uhrzeit bei spätestens einsetzte, wird diese Zeit nicht berücksichtigt und es wird zur Sunset-Zeit geschaltet.
define wdt_uzsu_EnO_00000017_0 WeekdayTimer EnO_00000017 en MO,TU,WE,TH,FR,SA,SU|{sunset_abs("REAL",5400,,"22:00")}|100
Anscheinend kommt der Weekdaytimer nicht mit einer leeren Stelle in der Funktion klar.
Gruß, Sascha
Das Update habe ich am 24.05. um 10:40 eingespielt:
98_WeekdayTimer.pm 24498 2021-05-24 06:12:31Z Beta-User
Zu diesem Zeitpunkt war der Status "SU/MU".
Der Schlafzimmer-Timer wurde, wie nach dem Reboot gewohnt, korrekt auf 21:31 gesetzt (Küche soll in diesem Status nicht um 21:30 schalten und war auch nicht gelistet).
Um 00:00 war auch noch alles ok.
Dann habe ich um 00:30 den Status auf "SH/MB" gesetzt, bei dem die Küche und das Schlafzimmer um 21:30/21:31 schalten sollen.
Um 03:55 wurde ein "set hc..* enable" ausgeführt. Das Schlafzimmerfenster war zu diesem Zeitpunkt geöffnet.
Das Ergebnis heute um 06:30:
2021-05-25 21:24:02.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-25 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-25 21:44:53.00000 DOIF_TimerTrigger
Küchen-Timer wurde korrekt hinzugefügt, Schlafzimmer-Timer wurde leider nicht gesetzt.
Im Log taucht kein "skipped"-Ereignis auf.
Zitat von: Cybers am 24 Mai 2021, 16:44:42
Anscheinend kommt der Weekdaytimer nicht mit einer leeren Stelle in der Funktion klar.
Das ist m.E. kein originäres WDT-Thema: gib das ({sunset_abs("REAL",5400,,"22:00")}) einfach mal in die Kommandozeile ein, da kommt dann auch eine spätere Zeit raus...
Der WDT-Code erkennt nur, _dass_ es Perl ist (also nicht, welche Funktion und welche Parameter ggf. erforderlich sind), "läßt" dann auswerten, und checkt im Ergebnis nochmal, ob es eine Uhrzeit ist, was zurückkommt. Das ist der Fall => aus WDT-Sicht ist alles bestens...
Zitat von: netwalk am 25 Mai 2021, 08:07:50
Das Ergebnis heute um 06:30:
[...]
Küchen-Timer wurde korrekt hinzugefügt, Schlafzimmer-Timer wurde leider nicht gesetzt.
Im Log taucht kein "skipped"-Ereignis auf.
Kein "skipped" paßt zur Info, dass der späteste Timer _noch_ nicht angelegt war. Der betreffende Timer (zu erkennen an der internen Nummer) sollte zu der fraglichen Zeit (noch) als "delayed" (vom Vortag, Schaltung auszuführen bei "Fenster-zu"-Erkennung) vorhanden gewesen sein und taucht dann in der timerList erst auf, wenn er entweder "skipped" wird oder das Fenster zugemacht wurde (und die nächste diesbezügliche Prüfung drübergelaufen ist).
Kannst du das mal gegenchecken?
Im Log sind als letzte "delayed"-Einträge bzgl. des Schlafzimmers folgende vorhanden:
2021.05.25 03:55:00 3: [hc.st.Schlafzimmer.SB.MB] set hc.st.Schlafzimmer.SB.MB enable
2021.05.25 03:55:00 3: [hc.st.Schlafzimmer.SB.MB] switch of struct.Heizung.st.Schlafzimmer delayed - sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
2021.05.25 03:55:00 3: [hc.st.Schlafzimmer.SH.MB] set hc.st.Schlafzimmer.SH.MB enable
2021.05.25 03:55:00 3: [hc.st.Schlafzimmer.SH.MB] switch of struct.Heizung.st.Schlafzimmer delayed - sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
2021.05.25 03:55:00 3: [hc.st.Schlafzimmer.SU.MB] set hc.st.Schlafzimmer.SU.MB enable
2021.05.25 03:55:00 3: [hc.st.Schlafzimmer.SU.MB] switch of struct.Heizung.st.Schlafzimmer delayed - sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
2021.05.25 03:55:00 3: [hc.st.Schlafzimmer.SU.MU] set hc.st.Schlafzimmer.SU.MU enable
2021.05.25 03:55:00 3: [hc.st.Schlafzimmer.SU.MU] switch of struct.Heizung.st.Schlafzimmer delayed - sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
Das Fenster im Schlafzimmer wurde um 08:04 geschlossen.
Die letzten "delay-stopped"-Einträge:
2021.05.25 08:05:00 3: [hc.st.Schlafzimmer.SB.MB] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2021.05.25 08:05:00 3: [hc.st.Schlafzimmer.SH.MB] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2021.05.25 08:05:00 3: CUL_HM set hm.hr.st.Schlafzimmer_Clima controlMode night
2021.05.25 08:05:00 3: CUL_HM set hm.wt.st.Schlafzimmer_Climate controlMode night
2021.05.25 08:05:00 3: [hc.st.Schlafzimmer.SU.MB] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2021.05.25 08:05:00 3: [hc.st.Schlafzimmer.SU.MU] delay of switching struct.Heizung.st.Schlafzimmer stopped.
Kannst du nochmal in die timerList schauen, ob er jetzt da ist?
Du hattest um den Dreh' des Schließens rum den Post heute morgen erstellt, und wenn der "alte Timer" aus der "Fenster ist jetzt geschlossen"-Funktion raus erneuert wird, taucht das (schon immer) nur ab verbose 4 im Log auf.
Nein, ist leider nicht angelegt worden:
2021-05-25 21:24:02.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-25 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-25 21:44:53.00000 DOIF_TimerTrigger
Danke für's nachschauen.
Ich glaube, jetzt auch die diesbezügliche Stelle vollends gefunden zu haben. Da war aber auch noch eine eventuelle "Baustelle" (eigentlich eher: eine (logische) Optimierung) in der Register.pm, von daher würde ich das gerne erst wieder einem "Übernacht"-Test im eigenen System unterziehen, bevor es ggf. dann morgen per update kommt...
Über Nacht keine Probleme => ist im svn mit der Bitte, das Ergebnis nochmals zu testen ::) ...
So, hier die Ergebnisse des ersten Tests:
26.05. 18:30 Update und Reboot
$Id: 98_WeekdayTimer.pm 24513 2021-05-26 03:53:53Z Beta-User
Status: SH/MB (erwartet: Küche 21:30/Schlafzimmer 21:31)
2021-05-26 21:25:18.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-26 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-26 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SH.MB_2
2021-05-26 21:40:37.71822 GetUpdate
26.05. 23:30
Statusänderung auf: SU/MU (erwartet: Schlafzimmer 21:31)
Fenster Schlafzimmer: geschlossen
27.05. 00:00
2021-05-27 21:26:31.00000 Twilight_fireEvent_MyTwilight_ss
2021-05-27 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SU.MU_2
2021-05-27 21:46:25.00000 DOIF_TimerTrigger
27.05. 00:07
Fenster Schlafzimmer: offen
27.05. 00:20
Statusänderung auf: SH/MB (erwartet: Küche 21:30/Schlafzimmer 21:31)
27.05. 03:55
set hc..* enable
27.05. 06:06
2021-05-27 21:26:32.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-27 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-27 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-27 21:47:55.00000 DOIF_TimerTrigger
(doppelter Eintrag Küche, Schlafzimmer fehlt)
27.05. 07:51
Fenster Schlafzimmer: geschlossen
2021.05.27 07:53:00 3: [hc.st.Schlafzimmer.SB.MB] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2021.05.27 07:53:00 3: [hc.st.Schlafzimmer.SH.MB] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2021.05.27 07:53:00 3: CUL_HM set hm.hr.st.Schlafzimmer_Clima controlMode night
2021.05.27 07:53:00 3: CUL_HM set hm.wt.st.Schlafzimmer_Climate controlMode night
2021.05.27 07:53:00 3: [hc.st.Schlafzimmer.SU.MB] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2021.05.27 07:53:00 3: [hc.st.Schlafzimmer.SU.MU] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2021.05.27 07:54:29 3: CUL_HM set li.eg.Flur.Handlauf_Dim_V_01 pct 15 60 0
27.05. 08:10
2021-05-27 21:26:32.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-27 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-27 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-27 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SH.MB_2
2021-05-27 21:47:55.00000 DOIF_TimerTrigger
Das sieht doch schon sehr vielversprechend aus. :)
Stört nur noch der doppelte Eintrag für die Küche...
Zitat von: netwalk am 27 Mai 2021, 08:49:06
Stört nur noch [...]
"Nur noch" ist relativ, man muss da immer aufpassen, dass man mit dem Hinterteil nicht einreißt, was man mit den Händen (usw...).
Ich glaube, die zwei diesbezüglichen Stellen gefunden zu haben, ohne massive Probleme an anderer Stelle zu verursachen, wäre aber für einen Test dankbar.
Da die Funktionsnamen jetzt teils gekürzt sind, bitte FHEM nach dem Einspielen dieser Fassung neu starten!
Hier die aktuellen Test-Ergebnisse:
27.05. 17:34 Update und Reboot
$Id: 98_WeekdayTimer.pm 24513 2021-05-26 03:53:53Z Beta-User
(Datei aus dem Thread, Dateigröße 69517 B)
Status: SH/MB (erwartet: Küche 21:30/Schlafzimmer 21:31)
Fenster Schlafzimmer: geschlossen
2021-05-27 21:26:32.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-27 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-27 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SH.MB_2
2021-05-27 21:40:37.71822 GetUpdate
27.05. 23:15
Statusänderung auf: SU/MU (erwartet: Schlafzimmer 21:31)
28.05. 00:00
2021-05-28 21:27:44.97000 Twilight_fireEvent_MyTwilight_ss
2021-05-28 21:31:00.00000 WeekdayTimer_Update hc.st.Schlafzimmer.SU.MU_2
2021-05-28 21:47:55.00000 DOIF_TimerTrigger
28.05. 01:08
Statusänderung auf: SH/MB (erwartet: Küche 21:30/Schlafzimmer 21:31)
28.05. 01:19
Fenster Schlafzimmer: offen
28.05. 03:55
set hc..* enable
2021.05.28 03:55:00 3: [hc.st.Schlafzimmer.SB.MB] set hc.st.Schlafzimmer.SB.MB enable
2021.05.28 03:55:00 3: [hc.st.Schlafzimmer.SB.MB] switch of struct.Heizung.st.Schlafzimmer delayed - sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
2021.05.28 03:55:00 3: [hc.st.Schlafzimmer.SH.MB] set hc.st.Schlafzimmer.SH.MB enable
2021.05.28 03:55:00 3: [hc.st.Schlafzimmer.SH.MB] switch of struct.Heizung.st.Schlafzimmer delayed - sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
2021.05.28 03:55:00 3: [hc.st.Schlafzimmer.SU.MB] set hc.st.Schlafzimmer.SU.MB enable
2021.05.28 03:55:00 3: [hc.st.Schlafzimmer.SU.MB] switch of struct.Heizung.st.Schlafzimmer delayed - sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
2021.05.28 03:55:00 3: [hc.st.Schlafzimmer.SU.MU] set hc.st.Schlafzimmer.SU.MU enable
2021.05.28 03:55:00 3: [hc.st.Schlafzimmer.SU.MU] switch of struct.Heizung.st.Schlafzimmer delayed - sensor 'hm.fk.st.Schlafzimmer.links' Reading/Attribute 'state' is 'open'
28.05. 06:06
2021-05-28 21:27:45.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-28 21:30:30.00000 WeekdayTimer_Update hc.eg.Kueche.SH.MB_6
2021-05-28 21:49:23.00000 DOIF_TimerTrigger
(Schlafzimmer fehlt wg. offenem Fenster)
28.05. 07:11
Fenster Schlafzimmer: geschlossen
2021.05.28 07:12:00 3: CUL_HM set li.eg.Flur.Handlauf_Dim_V_01 pct 15 60 0
2021.05.28 07:13:00 3: [hc.st.Schlafzimmer.SB.MB] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2021.05.28 07:13:00 3: [hc.st.Schlafzimmer.SH.MB] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2021.05.28 07:13:00 3: CUL_HM set hm.hr.st.Schlafzimmer_Clima controlMode night
2021.05.28 07:13:00 3: CUL_HM set hm.wt.st.Schlafzimmer_Climate controlMode night
2021.05.28 07:13:00 3: [hc.st.Schlafzimmer.SU.MB] delay of switching struct.Heizung.st.Schlafzimmer stopped.
2021.05.28 07:13:00 3: [hc.st.Schlafzimmer.SU.MU] delay of switching struct.Heizung.st.Schlafzimmer stopped.
28.05. 07:20
2021-05-28 21:27:45.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2021-05-28 21:30:30.00000 WDT_Update hc.eg.Kueche.SH.MB_6
2021-05-28 21:31:00.00000 WDT_Update hc.st.Schlafzimmer.SH.MB_2
2021-05-28 21:49:23.00000 DOIF_TimerTrigger
Ich sag mal: works as intended! :)
Ich werde jetzt die anderen Profile überarbeiten und weiterhin testen.
Vielen Dank für Dein Engagement!
Hatte diesen Stand auch eingecheckt. Da bisher keine kritischen Rückmeldungen mehr erfolgt sind, gehe ich mal davon aus, dass jetzt alles soweit passt...?
Die bestehende Programme scheinen zu funktionieren, sind aber aufgrund der warmen Temperaturen z.Zt. außer Betrieb.
Ich teste noch neue Timer für meine Rollladensteuerung.
Hallo zusammen,
ich habe eventuell einen Fehler im weekdaytimer-Modul gefunden. Wenn man z.B. für den kommenden Montag im Feiertagskalender einen "Feiertag" definiert hat, dann wird dies im WT nur dann berücksichtigt, Wenn neben der "Tageseinstellung 8" auch etwas anderes definiert ist (s. Bild 1). Wenn am an diesem Tag gar nicht schalten möchte, funktioniert es nicht (s. Bild 2)
Viele Grüße
Jürgen
Hallo juemuc,
scheint in der Tat ein Bug zu sein, komisch, dass das noch keinem aufgefallen ist. Vermutlich verwenden viele den WDT eher "statisch"...
Danke jedenfalls für's melden!
Anbei eine Testversion, die das beseitigen sollte, hab's allerdings bisher nur kurz angetestet, schaut plausibel aus (und räumt mehr interne Sachen zwischendurch weg, was man aber nur sieht, wenn man die Detailseite neu lädt).
Falls kein negatives feedback kommt und mir selbst beim Testen auch nichts mehr auffällt, checke ich das bei Gelegenheit ein.
Hallo Beta-User,
es funktioniert leider nicht (s. Anhang).
defmod dummy WeekdayTimer dummy1 de 8|22:15|on 8|23:00|off
In der Holiday-Datei ist für Morgen ein Feiertag eingetragen.
Viele Grüße
Jürgen
Hast du nach dem Einspielen des Moduls ein reload gemacht?
version WeekdayTimer sollte liefern:
# $Id: 98_WeekdayTimer.pm 25632 2023-01-25 fix !we profile generation Beta-User $
Bei mir wirft FHEM dann auch den kompletten Tag (getestet mit heute und morgen) raus, der per holiday2we zum Feiertag gemacht wurde. Ob der WDT den Tag korrekt erkannt hat, sieht man im list unter helper->WEDAYS (0 ist heute, 1 entspricht morgen usw.)
Asche auf mein Haupt. Ich hatte die falsche Holiday-Datei gepflegt ::)
Es passt alles. Vielen Dank
Jürgen
:) kein Problem, Danke für die Rückmeldung!
Hey Beta-User,
Mir ist gerade was aufgefallen was mich einwenig verwirrt hat...
Wenn 8 oder !we definiert ist wird mir Profil 8 mit Werktage angezeigt aber nur mo bis fr gesetzt. Werktage sind eigentlich mo bis sa...
Könntest du das korrigieren oder siehst du das anders?
Besser wäre da Wochentage oder Wochentags als Profilanzeige oder?
Soll nur ein Hinweis und keine Krümelkackerei sein.
Danke und LG mr_petz
Zitat von: mr_petz am 30 Januar 2023, 22:33:23
Hey Beta-User,
Mir ist gerade was aufgefallen was mich einwenig verwirrt hat...
Wenn 8 oder !we definiert ist wird mir Profil 8 mit Werktage angezeigt aber nur mo bis fr gesetzt. Werktage sind eigentlich mo bis sa...
Könntest du das korrigieren oder siehst du das anders?
Na ja, ich habe das v.a. im Wesentlichen halt so übernommen, wie es "immer" war...
Das mit $we und !$we ist ja noch etwas komplexer, wenn man die noWeekend-Option in holiday2we kennt...
Zitat
Besser wäre da Wochentage oder Wochentags als Profilanzeige oder?
Soll nur ein Hinweis und keine Krümelkackerei sein.
Finde das keine Krümelkackerei, letztlich geht es darum, eine "verständliche" Benutzerführung zu haben. "Wochentags" wäre vielleicht ein Kompromiss, vielleicht auch "Arbeitstage" (um wegen des etwas ungewohnten Wordings einen gewissen Nachdenk-Schubs da stehen zu haben).
Allerdings habe ich irgendwann mal eine Änderung an den Internals gemacht, die uns bei FUIP auf die Füße gefallen ist (war kein großes Ding). Von daher sollte man eventuelle Änderungen dann so machen bzw. abstimmen, dass sowohl FTUI (das du betreust?) wie auch FUIP (das das ggf. aus dem FTUI-Code übernimmt?) keine Probleme damit haben.
(Und sich ggf. dann auch noch die anderen im Code vorkommenden Sprachen mal ansehen).
Ja ok Arbeitstage wäre natürlich richtig. Würde es sinn machen auch die Werktage einzuführen? Wäre dann z.Bsp. 9 und wkt oderso...
LG
Hallo zusammen,
aus meiner Sicht wäre es vielleicht am sinnvollsten die Komplexität zu reduzieren. Wenn jemand immer die gleichen Tage hat, kann er dies ja über die Auswahl der Tage einfach definieren. Zusätzlich liefert noch die Variable $we true, wenn es sich um Sa, So oder um einen "Feiertag" laut holiday-Datei handelt. Reicht das nicht aus?
Ich versuche nun einmal die mir in den Sinn kommenden Konstellationen abzubilden:
- gleichbleibende Tage für die Aktionen -> Auswahl der Tage Mo-So
- Wochenende + Feiertag in der Woche -> Auswahl über "we" und Nutzung der globalen Variable holiday2we
- Mo-Sa + Feiertag in der Woche -> Auswahl über "we" + Auswahl Sa und Nutzung der globalen Variable holiday2we
- Nur "Feiertage aus holiday2we -> Auswahl über "we" + Auswahl aller Tageund Nutzung der globalen Variable holiday2we
Gibt es noch weitere Ausnahmen?
Viele Grüße
Jürgen
@juemuc
mo-fr wäre !we
+ sa + Feiertage
= Werktage
LG
@mr_petz,
was ist, wenn z.B. mi ein Feiertag ist und !we ausgewählt wurde? Wird dann der mi berücksichtigt? Ich würde !we nicht mehr definieren. Die Tage mo-fr auszuwählen sollte jedem möglich sein.
mo-fr + sa + Feiertage <> Werktage, da Feiertage keine Werktage sind.
So mein Verständnis.
Viele Grüße
Jürgen
Eine Einfache Formel wäre doch, dass alle definierten Tage verwendet werden, es sei denn, dass für diesen Tag die Variable $we=true ist. Das wäre eine einfache und verständliche Definition.
Viele Grüße
Jürgen
@juemuc
Das ist mir schon klar. Du weist warum ich hier Frage...
Ich muss es halt für mein FTUI3 Modul wissen...
LG
Ich weiß 8)
Deshalb bin ich auch der Meinung, dass es "Fhem-einheitlich" definiert werden sollte. Warten wir mal auf die Info von Beta-User.
Ich habe allerdings auch schon gemerkt, dass meine "Definition" nicht passt, da bei sa die Variable $we auch true liefert. Es ist wohl doch nicht so einfach, wie ich es mir gedacht hatte :(
Ich überlege weiter. Vieleicht hat ja noch jemand eine zündende Idee für eine "einfache" Definition.
Viele Grüße
Jürgen
Kann mir jemand diese Info aus der Fhem-Referenz für "holiday2we" erklären? Vieleicht hilft das ja bei unsere Definition.
Falls sich einer der Elemente dieser Liste weekEnd nennt, dann wird nicht auf Samstag/Sonntag geprüft. Falls einer der Elemente noWeekEnd ist, und nicht "none" zurückliefert, dann ist $we 0.
Viele Grüße
Jürgen
So, ich habe heute Nachmittag ein wenig getestet. Wenn man in global bei "holiday2we" neben der Feiertagsdatei auch noch "weekEnd" mit Komma getrennt hinterlegt (z.B. "by,weekEnd"), wird bei "$we" das Wochenende nicht berücksichtigt. Dies aber als Voraussetzung für den Weekdaytimer zu verwenden, halte ich für Problematisch. So langsam gehen mir die Ideen aus.
Viele Grüße
Jürgen
Sorry, hatte nur Gelegenheit, das kurz zu überfliegen, und den Eindruck, dass wir vorab mal klarstellen sollten, dass eine Konstruktion wie "Sonntags, aber nicht am Wochenende" durchaus sinnvoll sein können...
Der WeekdayTimer kann das jedenfalls iVm. h2we abbilden, und ich habe definitiv keine Pläne, daran was zu ändern :) .
Zitat von: juemuc am 31 Januar 2023, 20:46:19
So, ich habe heute Nachmittag ein wenig getestet. Wenn man in global bei "holiday2we" neben der Feiertagsdatei auch noch "weekEnd" mit Komma getrennt hinterlegt (z.B. "by,weekEnd"), wird bei "$we" das Wochenende nicht berücksichtigt. Dies aber als Voraussetzung für den Weekdaytimer zu verwenden, halte ich für Problematisch.
Wieso ist das problematisch? Das ist so gewollt, weil:
- es Kulturkreise und Communities gibt, bei denen z.B. der "Sonntag" am Freitag ist;
- manche User eher nach Schichtplänen wohnen und leben denn nach der starren Wochentagsbenennung
- ...
Dass es schwierig ist, das ggf. in einem Widget abzubilden, ist soweit klar, aber bevor diese grundlegende Funktionalität nicht klar ist, macht es keinen großen Sinn, über "Etiketten" zu sprechen.
Die "9" ist übrigens bei DOIF schon irgendwie vorbelegt, und wenn, dann sollte man zuerst schauen, ob diese Vorbelegung ggf. auch für den WDT sinnvoll übernommen werden könnte.
Hi Beta-User,
danke für Deine Antwort. Ich glaube, aufgrund Deiner Aussage noch einen Fehler in weekdaytimer erkannt zu haben.
Wenn ich bei einem dummy den Samstag (6) und !we (8) auswähle, sollte aufgrunde der Variable $we doch keine Aktion erfolgen, wenn (wie in meinem Fall) in der globalen Variablen holiday2we nur der Feiertagskalender "by" eingetragen ist. In meinem Testbeispiel wird in dem Beispiel die Aktion trotzdem durchgeführt.
Habe ich hier etwas falsch verstanden?
Viele Grüße
Jürgen
Kannst du vollständige RAW-lists liefern, damit ich das nachvollziehen kann?
Wenn du einen "6-er Schaltzeitpunkt" definierst, wird der (fast, s.u.) immer ausgeführt, ganz egal, ob $we wahr ist oder nicht. Und nur "by-holiday" machen aus Samstagen noch keine !$we-Tage, dazu müßtest du auf ein Device namens "weekEnd" definiert haben (oder per noWeekEnd die Samstage rausnehmen).
Noch "lustiger" ist, dass WDT auch eine Option für "an diesem numerischen Tag, aber nicht, wenn $we ist" kennt ;) .
Hi Beta-User,
anbei mein Testszenario:
1. Bettlicht-WT ohne Samstag/Sonntag:
defmod Bettlicht_WT WeekdayTimer Bettlicht_WT_Dummy de 8|21:45|on 8|23:00|off
Es werden nur die Wochentage Mo-Fr berücksichtigt (wie erwartet). Wenn ich in der globalen Variable "holiday2we" zusätzlich "weekEnd" eintrage, dann wird auch Samstag/Sonntag berücksichtigt (wie erwartet).
2. Bettlicht-WT mit "!we" und "6" für Samstag. In der globalen Variable "holiday2we" ist nur by eingetragen.
defmod Bettlicht_WT WeekdayTimer Bettlicht_WT_Dummy de 68|21:45|on 8|23:00|off
Hier wird der Samstag berücksichtigt. Das hätte ich so nicht erwartet.
Ich hoffe, es ist so klar geworden.
Viele Grüße
Jürgen
Zitat von: Beta-User am 01 Februar 2023, 14:29:06
Kannst du vollständige RAW-lists liefern, damit ich das nachvollziehen kann?
Wenn du einen "6-er Schaltzeitpunkt" definierst, wird der (fast, s.u.) immer ausgeführt, ganz egal, ob $we wahr ist oder nicht. Und nur "by-holiday" machen aus Samstagen noch keine !$we-Tage, dazu müßtest du auf ein Device namens "weekEnd" definiert haben (oder per noWeekEnd die Samstage rausnehmen).
Noch "lustiger" ist, dass WDT auch eine Option für "an diesem numerischen Tag, aber nicht, wenn $we ist" kennt ;) .
Das bedeutet, dass WDT hier eine eigene Logik verwendet, oder ::) (auch wenn Du sie nur übernommen hast ;D)
ZitatNoch "lustiger" ist, dass WDT auch eine Option für "an diesem numerischen Tag, aber nicht, wenn $we ist" kennt
Du meinst hier |w ? Jetzt verstehe ich auch den Sinn ::)
Wenn dem so ist, dann arbeitet natürlich WDT "as designed" ;D
Viele Grüße
Jürgen
Zitat von: juemuc am 01 Februar 2023, 15:03:06
Das bedeutet, dass WDT hier eine eigene Logik verwendet, oder ::) (auch wenn Du sie nur übernommen hast ;D )
Jein...
Zitat
Du meinst hier |w ? Jetzt verstehe ich auch den Sinn ::)
Korrekt... Das "w" stammt (soweit ich mich entsinne) von mir, denn ich fand es auch nicht "logisch zwingend", dass die "6" trotzdem berücksichtigt wird, obwohl (typischerweise) $we ist.
Zitat
Wenn dem so ist, dann arbeitet natürlich WDT "as designed" ;D
Qed.
Habe jetzt deine RAW nicht getestet, aber nach dem, was du schreibst besteht hinsichtlich der Funktionalität mAn. im Moment kein handlungsbedarf. Man kann "alles" umsetzen...
Vielleicht ist jetzt aber klarer, warum ich mich mit dem "wording" etwas schwer tue? Ich selbst denke da nur in den Kategorieren $we oder eben "nicht $we" (und habe dabei die vielfältigen Optionen zur "Erzeugung und Deutung" der Variable im Hinterkopf) ;) . Ist natürlich nicht so einfach, das in ein Widget zu packen....
Zitat von: mr_petz am 01 Februar 2023, 17:43:05
Ok. Ich werde es so umsetzen:
Bei $we( 7 ) und bei !$we( 8 ) lese ich die Profile aus, ansonsten das DEF.
Dadurch kann ich die Darstellung der Button der aktiven Tage unterscheiden. Einmal mit Rahmen und einmal voll ausgefüllt.
LG mr_petz
Bitte beachten: die in den Internals sichtbaren Profile sind Momentaufnahmen, die jeden Tag neu gebaut werden! Es können sich also Änderungen ergeben, wenn die zugrundeliegenden Infos zu IsWe() sich ändern...
(Es klang so, als wäre das ggf. noch klärungsbedürftig).
Ansonsten bin ich weiter für Änderungen des wordings offen (falls das nicht klar genug rüberkam). Es muss halt so sein, dass grade auch zu den Usern keine Brüche entstehen, die noch FUIP/FTUI2 im Einsatz haben.
Danke für den Hinweis.
Werden durch die Änderung der Profile (welcher Grund auch immer) Ereignisse erzeugt?
Viele Grüße
Jürgen
Danke für den Hinweis.
Es werden, sobald sich was ändert, die Daten neu geholt. Ich Trigger da drauf.
Ich konnte nur nicht richtig Folgen was nun wie gesetzt oder nicht gesetzt wird...
LG
@Beta-User
Hi,
nochmal eine Frage zwecks Event´s.
Ich muss extra noch auf disabled im FTUI3-Modul gehen(im case) um ein "refresh"/eine Aktualisierung zubekommen wenn in fhem disabled wird.
Jetzt die Frage.
Könntest du wenn disabled wird (in Fhem) noch ein Event auf´s wdt setzen wie beim enablen?
Standardmäßig gehe ich auf currValue um das FTUI3-Modul zu aktualisieren.
Im FTUI2-widget ist das selbe Szenario. Erst nach neu laden wird disabled angezeigt.
Ich hoffe du verstehst mein Anliegen und könntest da was pimpen ;).
LG mr_petz
Edit: der state bleibt bei disabled 1 auch auf aktiv?! Das sollte man auch ändern?
Edit2: Hat sich erledigt Danke. Es geht wenn ich nur auf das Device gehe.... LG mr_petz
Hi mr_petz,
aus meiner Sicht werden schon Ereignisse generiert. Hier mein Testergebnis:
2023-02-02 15:43:25 WeekdayTimer Bettlicht_WT disabled: 0
2023-02-02 15:43:25 WeekdayTimer Bettlicht_WT inactive
2023-02-02 15:43:25 WeekdayTimer Bettlicht_WT active
2023-02-02 15:43:25 WeekdayTimer Bettlicht_WT active
2023-02-02 15:43:25 WeekdayTimer Bettlicht_WT nextUpdate: 2023-02-02 21:45:00
2023-02-02 15:43:25 WeekdayTimer Bettlicht_WT nextValue: on
2023-02-02 15:43:25 WeekdayTimer Bettlicht_WT currValue: off
2023-02-02 15:43:25 Global global ATTR Bettlicht_WT disable 0
2023-02-02 15:43:30 dummy Bettlicht_WT_Dummy off
2023-02-02 15:43:30 WeekdayTimer Bettlicht_WT nextUpdate: 2023-02-02 21:45:00
2023-02-02 15:43:30 WeekdayTimer Bettlicht_WT nextValue: on
2023-02-02 15:43:30 WeekdayTimer Bettlicht_WT currValue: off
2023-02-02 15:43:30 WeekdayTimer Bettlicht_WT off
Viele Grüße
Jürgen
Setze mal bitte auf disabled 1
LG
Bitteschön:
2023-02-02 15:56:23 WeekdayTimer Bettlicht_WT disabled: 1
2023-02-02 15:56:23 Global global ATTR Bettlicht_WT disable 1
Viele Grüße
Jürgen
Das habe ich ja geschrieben. Es geht nur ein Event auf disabled. ich bräuchte das auf currentValue oder auf ein anderes reading .
Ich muss doch auf irgendwas triggern. Wenn ich nur auf disabled gehe, dann passiert bei einer Änderung der Timer nichts...
beim setzen disabled 0 oder enablen werden alle Events ausgelöst...
LG
Kannst Du nicht global triggern? Immer wenn ein Event des WDT-Devices erscheint, wird neu gelesen.
Ich will aber Beta-User nicht vorgreifen.
Viele Grüße
Jürgen
Ähm, ihr habt mich etwas verloren...
Also prinzipiell möchte ich ja "unnötige" Trigger eher vermeiden, aber wenn das hilft, kann man schon was einbauen. Da ist neben "disable" übrigens noch ein anderer Punkt: Die Profile werden jeden Tag kurz nach Mitternacht neu generiert, jeweils für eine Woche im Voraus. Wenn das erfolgt, triggert da vermutlich gar nichts, aber es kann durchaus sein, dass einzelne Tage komplett anders aussehen, weil sich eben irgendwas im $we-Umfeld geändert hat oder überhaupt erst auslesbar wird (für den aktuellen und die kommenden Tage)...
Wäre sowas wie "trigger WDT profiles updated" (bzw "deactivated") hilfreich?
(Und wie war das jetzt mit der Benennung von "Werktage"?)
Das mit dem Event hat sich erledigt. Wenn ich nur auf das Device ohne Reading gehe bekomme ich alle Events von wdt, aber wie du sagst vermutlich nicht die Profile.
Werktage wollten wir in Arbeitstage umbnennen.
Jetzt noch zu $we. Hier wird bei mir auch der Fr definiert wenn Freitag ein Feirtag ist.
Ist das so richtig?
LG
Hallo,
ZitatDie Profile werden jeden Tag kurz nach Mitternacht neu generiert,
Bei der Zeitumstellung von und zu Sommerzeit ist die Umstellung nicht um Mitternacht!
Neue Berechnungen zum kommenden Tag müssten aus meiner Sicht erst jeweils nach der Zeitumstellung, also so nach 03.00 Uhr geschehen.
Ich nutze WDT um abhängig vom Sonnenstand meine Hühner morgens aus dem Stall zu lassen bzw. abends wieder vom Fuchs zu separieren. Funktioniert gut, ausser jeweils am Tag der Zeitumstellung.
Gruß Bracew
Zitat von: mr_petz am 03 Februar 2023, 10:19:47
Das mit dem Event hat sich erledigt. Wenn ich nur auf das Device ohne Reading gehe bekomme ich alle Events von wdt, aber wie du sagst vermutlich nicht die Profile.
OK. Mußt halt melden, wenn es ein Problem geben sollte.
Zitat
Werktage wollten wir in Arbeitstage umbnennen.
Mach ich bei Gelegenheit - auch in der Annahme, dass es bei FUIP keine Probleme geben wird. Meldung kommt dann, so dass du deinen Code auch zeitnah entsprechend anpassen kannst.
Zitat
Jetzt noch zu $we. Hier wird bei mir auch der Fr definiert wenn Freitag ein Feirtag ist.
Ist das so richtig?
Ja. (Jedenfalls, wenn kein "w" hinter dem Profil steht und der Freitag per "5" festgelegt war; siehe auch die letzten paar Beiträge hier).
Zitat von: Bracew am 03 Februar 2023, 10:30:08
Neue Berechnungen zum kommenden Tag müssten aus meiner Sicht erst jeweils nach der Zeitumstellung, also so nach 03.00 Uhr geschehen.
Nein und ja!
Der WDT ist universell einsetzbar, und der Tag beginnt nun mal um 0:00 Uhr. Das mit "kurz nach" Mitternacht muss halt so sein, damit die Umstellung in holiday-Devices vorher durchgelaufen ist.
Der WDT weiß aber, wenn Zeitumstellung ist und initialisiert sich (nur!) an diesen Tagen um kurz nach 3:00 Uhr neu.
(Sorry für die etwas verkürzende Darstellung in dem anderen Beitrag).
Zitat von: Beta-User am 03 Februar 2023, 10:36:45
Ja. (Jedenfalls, wenn kein "w" hinter dem Profil steht und der Freitag per "5" festgelegt war; siehe auch die letzten paar Beiträge hier).
Bei mir wenn auch noch !$we ( 8 ) und kein w definiert ist und in der holiday 1 als Feiertag steht.
Hier mein Test:
wdt:
defmod wd WeekdayTimer dummy de 8|{sunrise_abs_dat($date)}|off 7|{sunset_abs_dat($date)}|on
holiday:
1 02-03 Test
LG
Hast du die aktuellste Version?
# $Id: 98_WeekdayTimer.pm 27118 2023-01-25 19:32:47Z Beta-User $
und
# $Id: 95_holiday.pm 25187 2021-11-06 09:54:35Z rudolfkoenig $
Hmmm, Ergebnis hier:
Profil 0: Sonntag 17:48:03 on,
Profil 1: Montag 07:27:53 off,
Profil 2: Dienstag 07:26:38 off,
Profil 3: Mittwoch 07:25:21 off,
Profil 4: Donnerstag 07:24:02 off,
Profil 5: Freitag 17:56:00 on,
Profil 6: Samstag 17:57:36 on,
Profil 7: Wochenende 17:57:36 on,
Profil 8: Werktags 07:22:41 off,
{IsWe()} liefert die "1"
Entspricht das nicht dem erwarteten Ergebnis?
(EDIT: abgesehen von der etwas komischen Zeit für kommenden So).
Das war ja die Ergänzung zu deiner Antwort.
Zitat
und der Freitag per "5" festgelegt war
Also auch bei 1 wenn Feiertag (im test halt der Freitag (heute ;D))
Tut mir leid, aber ich benutze den wdt jetzt erst seit neuesten...sorry.... :D
LG
Zitat von: mr_petz am 03 Februar 2023, 12:15:39
Tut mir leid, aber ich benutze den wdt jetzt erst seit neuesten...sorry.... :D
Kein Problem. Vermutlich haben viele langjährigen User grade beim Mitlesen auch ihre "aha"-Erlebnisse. Schließlich ist das von juemuc aufgedeckte Fehlverhalten bisher noch keinem aufgefallen gewesen...
Zitat von: mr_petz am 03 Februar 2023, 12:15:39
Das war ja die Ergänzung zu deiner Antwort.Also auch bei 1 wenn Feiertag (im test halt der Freitag (heute ;D ))
Habe dein Beispiel modifiziert:
defmod wd2 WeekdayTimer lampe. 58|{sunrise_abs_dat($date)}|off 7|{sunset_abs_dat($date)}|onJetzt ist am heutigen "Feiertags-"Freitag auch der Schaltpunkt am morgen drin. Ist m.E. erwartungsgemäß.
Andere Vorstellungen bei jemand von euch?
(Nochmal: Genau deswegen gibt es die "w"-Option bzw. das "true" in der weekprofile-Variante!).
Zitat von: mr_petz am 03 Februar 2023, 10:19:47
Werktage wollten wir in Arbeitstage umbnennen.
Das halte ich für falsch. Werktage sind eindeutig (Mo-Sa) definiert. Arbeitstage aus meiner Sicht nicht. Für Manche ist auch der Sonntag ein Arbeitstag 8)
Viele Grüße
Jürgen
Hier sieht man deutlich das nur mo-fr definiert wird:
https://forum.fhem.de/index.php/topic,114168.msg1260045.html#msg1260045
LG
Dann sollte man das ändern und für "We" = Werktag Mo-Sa definieren ::)
Als Werktage gelten alle Kalendertage, die nicht Sonn- oder gesetzliche Feiertage sind. " (Urteil vom 27.4.2005, Az.: VIII ZR 206/04).
Viele Grüße
Jürgen
Sorry, aber irgendwie habe ich an der Stelle den Eindruck, dass wir uns im Kreis drehen.
Es kann nur darum gehen, eine "halbwegs passende Etikette" zu finden für alles, was nicht $we ist. Und $we ist nun mal "flexibel" und paßt eben nicht immer zu den sprachlich "üblichen" Kategorien "Wochenende" bzw. "unter der Woche". Da beißt die Maus keinen Faden ab, und ich habe wirklich nicht vor, über die Frage zu diskutieren, wie der Samstag jetzt in FHEM allgemein gehandhabt werden sollte...
Demnach haben wir kein wirklich allgemein akzeptiertes Etikett, und solange das so ist, bleibt eben alles so wie es ist. Mich stört das nicht, ich weiß ja, wie der WDT tickt...
Ja entweder oder???
Wenn mo-fr -> Werktage ändern in Arbeitstage,
wenn mo-sa -> bleibt Werktage und muss der sa dazu kommen....
Was jetzt besser oder schlechter ist müssen die User sagen. Deswegen wollte ich ja mo-sa zusätzlich.
Wenn User jetzt den sa (durch das Update) noch dazu bekommen und ein device dadurch schaltet (oder was auch immer) und es so garnicht gewollt ist.....????
Ob das gut ist? Es müssten dann alle die !$we definiert haben und bewusst dadurch nur mo-fr bekommen, alles umstellen.
LG
Edit: mich hatte das als Neueinsteiger irritiert...
Da gebe ich Dir vollkommen Recht. Nur würde ich Mo-Fr nicht "Arbeitstage" sondern dann "Mo-Fr" benennen, auch wenn es etwas länger ist. So steht es z.B. auch auf Verkehrsschildern 8)
Beta-User wird schon das Richtige Wording finden ::)
Viele Grüße
Jürgen
Zitat von: juemuc am 03 Februar 2023, 16:06:04
Da gebe ich Dir vollkommen Recht. Nur würde ich Mo-Fr nicht "Arbeitstage" sondern dann "Mo-Fr" benennen, auch wenn es etwas länger ist. So steht es z.B. auch auf Verkehrsschildern 8)
Beta-User wird schon das Richtige Wording finden ::)
Viele Grüße
Jürgen
Ich war für "Arbeitstage"...
Nochmal: Wann $we ist, bestimmt letztlich der User. Er kann einfach die "üblichen Konventionen" übernehmen, dann gibt es kaum Friktionen zur allgemein üblichen Sprechweise, er kann es aber auch komplett frei gestalten, und dann entspricht !$we und $we (vermutlich) in den meisten Fällen der Frage, wann (regulär) gearbeitet wird bzw. wann man eben tendenziell zu Hause ist...
Und wenn er "frei" definiert, ist Mo.-Fr. (oder Mo.-Sa.) sowieso keine valide Kategorie mehr.
Ob der Sa. $we ist, kann der User auch frei festlegen, dazu braucht es keine Sonderregelung im WDT (mAn.).
@Beta-User: Aus meiner Sicht ok.
Ich habe jetzt bei meinen Tests noch eine Konstellation erstellt, die ich zumindest merkwürdig finde.
defmod Bettlicht_WT WeekdayTimer Bettlicht_WT_Dummy de
attr Bettlicht_WT alias Bettlicht (An/Aus)
attr Bettlicht_WT commandTemplate set $NAME $EVENT
attr Bettlicht_WT devStateStyle style="text-align:right"
attr Bettlicht_WT disable 0
attr Bettlicht_WT stateFormat {my $val;;\
if (ReadingsVal($name, "disabled","") eq "1") {$val = "AUS"}\
else {$val = ReadingsVal($name, "currValue","")};;\
$val}
attr Bettlicht_WT switchInThePast 1
setstate Bettlicht_WT on
setstate Bettlicht_WT 2023-02-03 16:16:22 currValue on
setstate Bettlicht_WT 2023-02-03 16:16:11 disabled 0
setstate Bettlicht_WT 2023-02-03 16:16:22 nextUpdate 2023-02-05 00:00:00
setstate Bettlicht_WT 2023-02-03 16:16:22 nextValue on
setstate Bettlicht_WT 2023-02-03 16:16:22 state on
Ich habe hier alle Wochentage mit den Zeitangaben entfernt. Trotzdem ist das Reading "nextUpdate" noch mit einem Wert gefüllt. Findet da jetzt eine Aktion? Wenn ja, wäre das aus meiner Sicht falsch.
Ich weiß, dass ist konstruiert, aber möglich.
Viele Grüße
Jürgen
Hmmm, vermutlich läuft da im Hintergrund kein Timer, das dürfte ein reines Anzeige-Thema sein, und rauszufischen, ob da jetzt ein optionales Argument übergeben wurde, um den Syntaxfehler zu kaschieren ist zwar möglich, mir aber zumindest für den Moment zu aufwändig....
ok, kann ich verstehen. Das Problem ist ja auch eher theoretischer Natur. Vielleicht kann ich es bei meinen Tests weiter verifizieren.
Viele Grüße
Jürgen
Hi Beta-User,
ich befürchte, ich habe einen weiteren Fehler gefunden.
Bei der Definition "08" wird der Sonntag ignoriert. Bei "068" ist der Sonntag dabei. Siehe Anhänge. Warum fehlt bei der ersten Definition der Sonntag?
Viele Grüße
Jürgen
Hmmm, sieht in der Tat komisch aus. Ich hoffe, in der nächsten Woche mal dazu zu kommen, das mal intensiv anzusehen. Sonst bitte in 3 Wochen nochmal nachhaken!
Zitat von: Beta-User am 01 Februar 2023, 09:41:08
Die "9" ist übrigens bei DOIF schon irgendwie vorbelegt, und wenn, dann sollte man zuerst schauen, ob diese Vorbelegung ggf. auch für den WDT sinnvoll übernommen werden könnte.
9 ist da der Tag vor Wochenende/Feiertag, würde ich im WDT auch nützlich finden.
Hallo,
ich muss mich hier auch noch einmal einklinken.
Der Timer funktioniert leider reproduzierbar am WE nicht korrekt.
Ich habe einige WeekdayTimer in Abhängigkeit vom Status der Bewohner zur Heizungssteuerung angelegt. Die einzelnen WeekdayTimer werden auch zuverlässig aktiviert und schalten unter der Woche einwandfrei.
Hier das Listing:
Internals:
COMMAND
CONDITION (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Silke.Status","state", "") eq "Büro" and ReadingsVal("sc.Micha.Status","state", "") eq "Büro")
DEF struct.Heizung.st.Schlafzimmer 1234|15:31:00|dm.Heizung.st.Schlafzimmer.temp.high 5|15:31:00|dm.Heizung.st.Schlafzimmer.temp.high 60|07:01:00|dm.Heizung.st.Schlafzimmer.temp.high 21:01:00|dm.Heizung.st.Schlafzimmer.temp.low (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Silke.Status","state", "") eq "Büro" and ReadingsVal("sc.Micha.Status","state", "") eq "Büro")
DEVICE struct.Heizung.st.Schlafzimmer
FUUID 5de97613-f33f-c765-a44b-4703036352c33dc6
GlobalDaylistSpec
LANGUAGE en
NAME hc.st.Schlafzimmer.SB.MB
NR 1655
Profil 0: Sunday 07:01:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
Profil 1: Monday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
Profil 2: Tuesday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
Profil 3: Wednesday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
Profil 4: Thursday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
Profil 5: Friday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
Profil 6: Saturday 07:01:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
STATE open window
STILLDONETIME 0
TYPE WeekdayTimer
eventCount 886
setModifier desired-temp
READINGS:
2023-02-14 08:03:00 currValue dm.Heizung.st.Schlafzimmer.temp.low
2021-01-13 14:42:26 disabled 0
2023-02-14 08:03:00 nextUpdate 2023-02-14 15:31:00
2023-02-14 08:03:00 nextValue dm.Heizung.st.Schlafzimmer.temp.high
2023-02-14 08:01:00 state open window
SWITCHINGTIMES:
1234|15:31:00|dm.Heizung.st.Schlafzimmer.temp.high
5|15:31:00|dm.Heizung.st.Schlafzimmer.temp.high
06|07:01:00|dm.Heizung.st.Schlafzimmer.temp.high
21:01:00|dm.Heizung.st.Schlafzimmer.temp.low
TIMER:
hc.st.Schlafzimmer.SB.MB_1:
HASH hc.st.Schlafzimmer.SB.MB
MODIFIER 1
NAME hc.st.Schlafzimmer.SB.MB_1
hc.st.Schlafzimmer.SB.MB_midnight:
HASH hc.st.Schlafzimmer.SB.MB
MODIFIER midnight
NAME hc.st.Schlafzimmer.SB.MB_midnight
SETTIMERATMIDNIGHT 1
helper:
daysRegExp (su|mo|tu|we|th|fr|sa|\$we|\!\$we)
daysRegExpMessage (su|mo|tu|we|th|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
07:01:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
1:
15:31:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
2:
15:31:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
3:
15:31:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
4:
15:31:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
5:
15:31:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
6:
07:01:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
WEDAYS:
4 1
5 1
profil:
1:
EPOCH 1676385060
PARA dm.Heizung.st.Schlafzimmer.temp.high
TIME 15:31:00
WE_Override 0
DAYS:
1
2
3
4
2:
EPOCH 1676385060
PARA dm.Heizung.st.Schlafzimmer.temp.high
TIME 15:31:00
WE_Override 0
DAYS:
5
3:
EPOCH 1676354460
PARA dm.Heizung.st.Schlafzimmer.temp.high
TIME 07:01:00
WE_Override 0
DAYS:
0
6
4:
EPOCH 1676404860
PARA dm.Heizung.st.Schlafzimmer.temp.low
TIME 21:01:00
WE_Override 0
DAYS:
0
1
2
3
4
5
6
profile_IDX:
0:
07:01:00 3
21:01:00 4
1:
15:31:00 1
21:01:00 4
2:
15:31:00 1
21:01:00 4
3:
15:31:00 1
21:01:00 4
4:
15:31:00 1
21:01:00 4
5:
15:31:00 2
21:01:00 4
6:
07:01:00 3
21:01:00 4
Attributes:
WDT_Group former_HC
WDT_delayedExecutionDevices hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts
commandTemplate set $NAME desired-temp [$EVENT:state]
disable 0
room Heizung
switchInThePast 1
Man sieht im Log des Heizungsreglers, dass unter der Woche alles funktioniert, am SA und SO jedoch nicht, der kritische Schaltzeitpunkt ist 21:01 Uhr:
[...]
Donnerstag:
2023-02-09_15:30:37 hm.hr.st.Schlafzimmer desired-temp: 17.0
2023-02-09_15:31:01 hm.hr.st.Schlafzimmer desired-temp: 19.0
[...]
2023-02-09_20:52:50 hm.hr.st.Schlafzimmer desired-temp: 19.0
2023-02-09_20:52:50 hm.hr.st.Schlafzimmer measured-temp: 18.5
2023-02-09_21:01:01 hm.hr.st.Schlafzimmer desired-temp: 17.0
2023-02-09_21:02:59 hm.hr.st.Schlafzimmer actuator: 0
2023-02-09_21:02:59 hm.hr.st.Schlafzimmer measured-temp: 18.5
2023-02-09_21:13:32 hm.hr.st.Schlafzimmer actuator: 0
2023-02-09_21:13:32 hm.hr.st.Schlafzimmer desired-temp: 17.0
[...]
Freitag:
2023-02-10_15:22:04 hm.hr.st.Schlafzimmer desired-temp: 17.0
2023-02-10_15:22:04 hm.hr.st.Schlafzimmer measured-temp: 17.5
2023-02-10_15:26:43 hm.hr.st.Schlafzimmer actuator: 2
2023-02-10_15:26:43 hm.hr.st.Schlafzimmer measured-temp: 17.6
2023-02-10_15:31:01 hm.hr.st.Schlafzimmer desired-temp: 19.0
[...]
2023-02-10_20:55:19 hm.hr.st.Schlafzimmer desired-temp: 19.0
2023-02-10_21:01:01 hm.hr.st.Schlafzimmer desired-temp: 17.0
2023-02-10_21:02:50 hm.hr.st.Schlafzimmer actuator: 0
2023-02-10_21:02:50 hm.hr.st.Schlafzimmer measured-temp: 18.8
2023-02-10_21:12:21 hm.hr.st.Schlafzimmer desired-temp: 17.0
[...]
Samstag:
2023-02-11_09:42:05 hm.hr.st.Schlafzimmer desired-temp: 5.5
2023-02-11_09:44:26 hm.hr.st.Schlafzimmer battery: ok
2023-02-11_09:44:26 hm.hr.st.Schlafzimmer batteryLevel: 2.5
2023-02-11_09:44:26 hm.hr.st.Schlafzimmer motorErr: ok
2023-02-11_09:46:32 hm.hr.st.Schlafzimmer measured-temp: 16.9
2023-02-11_09:49:03 hm.hr.st.Schlafzimmer desired-temp: 19.0
[...]
2023-02-11_20:50:32 hm.hr.st.Schlafzimmer desired-temp: 19.0
2023-02-11_20:52:51 hm.hr.st.Schlafzimmer measured-temp: 18.9
2023-02-11_21:02:55 hm.hr.st.Schlafzimmer actuator: 26
2023-02-11_21:02:55 hm.hr.st.Schlafzimmer desired-temp: 19.0
2023-02-11_21:02:55 hm.hr.st.Schlafzimmer measured-temp: 18.9
2023-02-11_21:13:23 hm.hr.st.Schlafzimmer actuator: 26
2023-02-11_21:13:23 hm.hr.st.Schlafzimmer desired-temp: 19.0
[...]
Sonntag:
2023-02-12_10:10:45 hm.hr.st.Schlafzimmer desired-temp: 5.5
2023-02-12_10:10:45 hm.hr.st.Schlafzimmer measured-temp: 17.1
2023-02-12_10:14:01 hm.hr.st.Schlafzimmer desired-temp: 19.0
[...]
2023-02-12_20:58:21 hm.hr.st.Schlafzimmer desired-temp: 19.0
2023-02-12_21:03:59 hm.hr.st.Schlafzimmer measured-temp: 19.2
2023-02-12_21:08:38 hm.hr.st.Schlafzimmer actuator: 14
2023-02-12_21:08:38 hm.hr.st.Schlafzimmer battery: ok
2023-02-12_21:08:38 hm.hr.st.Schlafzimmer batteryLevel: 2.5
2023-02-12_21:08:38 hm.hr.st.Schlafzimmer desired-temp: 19.0
[...]
Montag:
2023-02-13_15:22:28 hm.hr.st.Schlafzimmer desired-temp: 17.0
2023-02-13_15:29:51 hm.hr.st.Schlafzimmer measured-temp: 17.8
2023-02-13_15:31:01 hm.hr.st.Schlafzimmer desired-temp: 19.0
[...]
2023-02-13_20:49:16 hm.hr.st.Schlafzimmer desired-temp: 19.0
2023-02-13_20:54:34 hm.hr.st.Schlafzimmer measured-temp: 18.9
2023-02-13_20:56:51 hm.hr.st.Schlafzimmer measured-temp: 19.0
2023-02-13_21:01:01 hm.hr.st.Schlafzimmer desired-temp: 17.0
2023-02-13_21:01:46 hm.hr.st.Schlafzimmer actuator: 27
2023-02-13_21:04:24 hm.hr.st.Schlafzimmer actuator: 0
2023-02-13_21:08:57 hm.hr.st.Schlafzimmer measured-temp: 19.0
2023-02-13_21:11:56 hm.hr.st.Schlafzimmer desired-temp: 17.0
Der erste Schaltzeitpunkt am WE auf 19° C wird korrekt geschaltet, ggf. erst nachdem das Fenster morgens geschlossen wurde. Der zweite Schaltpunkt abends auf 17°C wird jedoch nicht ausgelöst, lediglich unter der Woche.
Was läuft (oder mache ich) hier falsch?
Zitat von: sinus61 am 04 Februar 2023, 18:37:22
9 ist da der Tag vor Wochenende/Feiertag, würde ich im WDT auch nützlich finden.
Und wenn die Ziffern ausgehen, dann muss man mit Buchstaben weiter machen, besser aber mit aussagefähigen Begriffen.
siehe: https://forum.fhem.de/index.php/topic,132143.msg1263376.html#msg1263376
Zitat von: Beta-User am 03 Februar 2023, 21:23:59
Hmmm, sieht in der Tat komisch aus. Ich hoffe, in der nächsten Woche mal dazu zu kommen, das mal intensiv anzusehen. Sonst bitte in 3 Wochen nochmal nachhaken!
Hallo Beta-User,
ich vermute, Du hattest noch keine Zeit. Kein Problem, ich habe dafür noch eine Ungereimtheit gefunden:
Das Reading "nextUpdate" wird nicht korrigiert, wenn Nachts sich die Zeiten in den Profilen ändern (s. Anhang). Der Wert wird erst beim Schaltvorgang wieder angepasst und hat dann den "alten Wert".
Viele Grüße
Jürgen
Auch an diesem Wochenende schaltet der Timer leider nicht korrekt.
Im Listing sieht man, dass der Zeitschaltpunkt angeblich korrekt geplant ist, er wird jedoch nicht ausgelöst:
Internals:
COMMAND
CONDITION (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Silke.Status","state", "") eq "Büro" and ReadingsVal("sc.Micha.Status","state", "") eq "Büro")
DEF struct.Heizung.st.Schlafzimmer 1234|15:31:00|dm.Heizung.st.Schlafzimmer.temp.high 5|15:31:00|dm.Heizung.st.Schlafzimmer.temp.high 60|07:01:00|dm.Heizung.st.Schlafzimmer.temp.high 1234560|21:01:00|dm.Heizung.st.Schlafzimmer.temp.low (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Silke.Status","state", "") eq "Büro" and ReadingsVal("sc.Micha.Status","state", "") eq "Büro")
DEVICE struct.Heizung.st.Schlafzimmer
FUUID 5de97613-f33f-c765-a44b-4703036352c33dc6
GlobalDaylistSpec
LANGUAGE en
NAME hc.st.Schlafzimmer.SB.MB
NR 1655
Profil 0: Sunday 07:01:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
Profil 1: Monday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
Profil 2: Tuesday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
Profil 3: Wednesday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
Profil 4: Thursday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
Profil 5: Friday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
Profil 6: Saturday 07:01:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
STATE dm.Heizung.st.Schlafzimmer.temp.high
STILLDONETIME 0
TYPE WeekdayTimer
eventCount 3170
setModifier desired-temp
READINGS:
2023-02-26 10:53:00 currValue dm.Heizung.st.Schlafzimmer.temp.high
2021-01-13 14:42:26 disabled 0
2023-02-26 10:53:00 nextUpdate 2023-02-26 21:01:00
2023-02-26 10:53:00 nextValue dm.Heizung.st.Schlafzimmer.temp.low
2023-02-26 10:53:00 state dm.Heizung.st.Schlafzimmer.temp.high
SWITCHINGTIMES:
1234|15:31:00|dm.Heizung.st.Schlafzimmer.temp.high
5|15:31:00|dm.Heizung.st.Schlafzimmer.temp.high
06|07:01:00|dm.Heizung.st.Schlafzimmer.temp.high
0123456|21:01:00|dm.Heizung.st.Schlafzimmer.temp.low
TIMER:
hc.st.Schlafzimmer.SB.MB_midnight:
HASH hc.st.Schlafzimmer.SB.MB
MODIFIER midnight
NAME hc.st.Schlafzimmer.SB.MB_midnight
SETTIMERATMIDNIGHT 1
helper:
daysRegExp (su|mo|tu|we|th|fr|sa|\$we|\!\$we)
daysRegExpMessage (su|mo|tu|we|th|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
07:01:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
1:
15:31:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
2:
15:31:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
3:
15:31:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
4:
15:31:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
5:
15:31:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
6:
07:01:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
WEDAYS:
0 1
6 1
profil:
1:
EPOCH 1677421860
PARA dm.Heizung.st.Schlafzimmer.temp.high
TIME 15:31:00
WE_Override 0
DAYS:
1
2
3
4
2:
EPOCH 1677421860
PARA dm.Heizung.st.Schlafzimmer.temp.high
TIME 15:31:00
WE_Override 0
DAYS:
5
3:
EPOCH 1677391260
PARA dm.Heizung.st.Schlafzimmer.temp.high
TIME 07:01:00
WE_Override 0
DAYS:
0
6
4:
EPOCH 1677441660
PARA dm.Heizung.st.Schlafzimmer.temp.low
TIME 21:01:00
WE_Override 0
DAYS:
0
1
2
3
4
5
6
profile_IDX:
0:
07:01:00 3
21:01:00 4
1:
15:31:00 1
21:01:00 4
2:
15:31:00 1
21:01:00 4
3:
15:31:00 1
21:01:00 4
4:
15:31:00 1
21:01:00 4
5:
15:31:00 2
21:01:00 4
6:
07:01:00 3
21:01:00 4
Attributes:
WDT_Group former_HC
WDT_delayedExecutionDevices hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts
commandTemplate set $NAME desired-temp [$EVENT:state]
disable 0
room Heizung
switchInThePast 1
Ein manuell ausgelöstes
set hc.st.Schlafzimmer.SB.MB WDT_Params single
schaltet ohne weitere Verzögerung korrekt auf die Nachtabsenkung.
Hallo Beta-User,
du hast dich ja schon mal an der Diskussion UZSU und CommandTemplate beteiligt.
Inzwischen hat Wolfram das Problem mit der Datenübernahme aus der UZSU gelöst, die Daten kommen an und werden in der Variable "conditionOrCommand" eingetragen.
Allerdings wird das Attribut "commandTemplate" nicht gesetzt. Ich habe das hier (und eine "Lösung" für meine Testumgebung) beschrieben:
Zitathttps://forum.fhem.de/index.php/topic,127432.msg1264026.html#msg1264026
Was wäre dein Vorschlag?
Es gibt da ein paar eindeutige Readings:
R-change_over_delay
R-reference_run_counter
R-reference_running_time_bottom_top
R-reference_running_time_top_bottom
Damit könnte man ja die HMW-Devices eindeutig identifizieren. So wird das ja auch in der Abfrage "checkIfDeviceIsHeatingType" gemacht.
Oder doch immer dann wenn im "conditionOrCommand" etwas drin steht?
LG
Michael
Hmm, irgendwie bin ich im Moment immer an ein paar anderen Dingen dran, WDT kommt dann schon auch bald mal an die Reihe.
in commandTemplate was anderes zu legen als gedacht, kommt mir zumindest auf die Schnelle gar nicht passend vor (v.a., weil es auch "condition" sein könnte); dass da überhaupt im laufenden Betrieb immer wieder was gesetzt wird, ist eigentlich schon nicht mehr ein Vorgehen, dass ich heute so vercoden würde (das war aber immer schon so).
Eigentlich müßte auch ein einmal gesetztes Attribut erhalten bleiben. Löst das nicht schon dein Problem, das zu setzen? (Oder löscht der Code das Device, um es from scratch neu anzulegen? Dann ggf. umstellen auf defmod?)
Das mit den "eindeutigen Readings" verstehe ich nicht. isHeating fragt setter ab, wenn ich das richtig im Kopf habe.
Hi,
jeep, in der Funktion "UZSU_execute" (siehe 99_fronthemUtils) wird zuerst der komplette WDT Eintrag, z.B.: "wdt_uzsu_EG_EsseckeRechtsBlind_0" gelöscht und neu generiert. Das zusammenbasteln der wdt_uzsu_' wird mit defmod gemacht.
Ich kann in meinem Testsystem die Zeile "fhem('delete wdt_uzsu_'.$device.'.*');" entfernen und sehen was dann passiert... 8) Ich denke aber nicht, das es so einfach ist :-\
Da ich mehrere Schaltzeiten nutze, ist es ziemlich öde jedesmal das "set level" in der UZSU einzutragen :-\ . Insofern wäre es wirklich besser, dieses Attribut zu sichern und im neuem wdt_... einzusetzen. 8)
In der Funktion "checkIfDeviceIsHeatingType" werden doch die Readings des aktuellen Devices auf "desired-temp etc. geprüft? Oder habe ich die Zeilen falsch verstanden?
my @tempSet = qw(desired-temp desiredTemperature desired thermostatSetpointSet);
my $allSets = getAllSets($dName);
for my $ts (@tempSet) {
if ($allSets =~ m{$ts}xms) {
Log3( $hash, 4, "[$name] device type heating recognized, setModifier:$ts" );
$hash->{setModifier} = $ts;
return $ts
}
Ich freunde mich erst langsam mit Perl an und bin da nicht sehr sicher.
Nix mit readings:
getAllSets($dName)
Gefragt werden alle setter, und es gibt TYPEs, die nicht zwangsläufig auch so ein Reading kennen (ZWave, z.B.).
Ich kapiere nicht, warum man löschen sollte. defmod ist genau dazu da, dass man sich darüber nicht den Kopf zerbrechen muss? Das gibt es allerdings uU. noch nicht so lange wie den UZSU-Code...
Hi,
ich muss mich korrigieren.
Wenn ich (mit der aktuellen 99_fronthem aus dem develop Zweig) in der UZSU Zeiten hinzufüge, muss ich in der "Expert" Ansicht set level übergeben (siehe Bild)
Der wdt_uzsu_WohnZimmerTestBlind_0 sieht dann so aus:
Internals:
CFGFN
COMMAND set $NAME level $EVENT
CONDITION
DEF WohnZimmerTestBlind en TH|20:30|17 set $NAME level $EVENT
DEVICE WohnZimmerTestBlind
FUUID 640a33f7-f33f-8046-01f8-8efcc3401bb2826a
GlobalDaylistSpec
LANGUAGE en
NAME wdt_uzsu_WohnZimmerTestBlind_0
NR 242
Profil 4: Thursday 20:30:00 17,
STATE active
STILLDONETIME 0
TYPE WeekdayTimer
eventCount 8
setModifier
READINGS:
2023-03-09 20:31:03 currValue 17
2023-03-09 20:31:03 disabled 0
2023-03-09 20:31:03 nextUpdate 2023-03-16 20:30:00
2023-03-09 20:31:03 nextValue 17
2023-03-09 20:31:03 state active
2023-03-09 20:31:03 weekdays TH|20:30|17
SWITCHINGTIMES:
4|20:30|17
TIMER:
wdt_uzsu_WohnZimmerTestBlind_0_midnight:
HASH wdt_uzsu_WohnZimmerTestBlind_0
MODIFIER midnight
NAME wdt_uzsu_WohnZimmerTestBlind_0_midnight
SETTIMERATMIDNIGHT 1
helper:
daysRegExp (su|mo|tu|we|th|fr|sa|\$we|\!\$we)
daysRegExpMessage (su|mo|tu|we|th|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
1:
2:
3:
4:
20:30:00 17
5:
6:
WEDAYS:
2 1
3 1
profil:
1:
EPOCH 1678390200
PARA 17
TIME 20:30
WE_Override 0
DAYS:
4
profile_IDX:
4:
20:30:00 1
Attributes:
commandTemplate set $NAME $EVENT
disable 0
group WohnZimmerTestBlind
room UZSU
Das commando wird richtig erzeugt ->
COMMAND set $NAME level $EVENT
Damit wird das Attribut
ZitatcommandTemplate set $NAME $EVENT
scheinbar hinfällig.
Da ich mit der "alten" 99_fronthem immer das "commandTemplate" ändern musste, habe ich dafür unnötigerweise eine Lösung gesucht.
Verwirrend war für mich auch, das bei den HM-xyz Devices immer ein CommandTemplate angelegt wird. Command bleibt dann leer.
Wenn ich nun Zeiten oder Werte in der UZSU ändere, bleibt das
COMMAND set $NAME level $EVENT erhalten.
Der einzige Wermuttropfen ist, das man bei neuen Schaltzeiten in der UZSU in die Expert Einstellungen rein muss.... Damit kann ich leben.
LG Michael
Zitat von: juemuc am 24 Februar 2023, 18:01:43Zitat von: Beta-User am 03 Februar 2023, 21:23:59Hmmm, sieht in der Tat komisch aus. Ich hoffe, in der nächsten Woche mal dazu zu kommen, das mal intensiv anzusehen. Sonst bitte in 3 Wochen nochmal nachhaken!
Hallo Beta-User,
ich vermute, Du hattest noch keine Zeit. Kein Problem, ich habe dafür noch eine Ungereimtheit gefunden:
Das Reading "nextUpdate" wird nicht korrigiert, wenn Nachts sich die Zeiten in den Profilen ändern (s. Anhang). Der Wert wird erst beim Schaltvorgang wieder angepasst und hat dann den "alten Wert".
Viele Grüße
Jürgen
Hallo Beta-User,
ich weiß, Deine Zeit ist zur Zeit begrenzt. Trotzdem noch einmal die Nachfrage zu diesem Fehler. Kannst Du das Problem zumindest reproduzieren? Benötigst Du noch Infos? Ich Falle immer wieder auf die falsche Zeit rein, wenn ich die Schaltzeiten prüfe.
Bild (https://forum.fhem.de/index.php?action=dlattach;attach=169425;image)
Viele Grüße
Jürgen
...ich habe auch schon ein schlechtes Gewissen...
Ich hoffe, nächste Woche mal die Ruhe dazu zu haben.
Tja, was soll ich sagen...
Wie unterschwellig befürchtet, war das Problem nicht nur ziemlich versteckt (08 == 8, aber 068 != 8...), sondern es braucht noch ein paar mehr Klimmzüge mehr, um - zumindest auf den ersten Blick - Ergebnisse zu erzielen, die dem entsprechen, was die jeweilige DEF eigentlich so hergeben kann ::) .
Hoffe, das jetzt zutreffend gelöst zu haben, aber weil es uU. komische Nebenwirkungen haben könnte, erst mal hier zum testen.
Hi Beta-User,
bei mir sieht es gut aus. Danke für die Korrektur.
Viele Grüße
Jürgen
Danke für die Rückmeldung.
Bitte aber auch mal allgemein deine WDT's durchsehen.
Das Problem ist Folgendes: Um den von dir gezeigten komischen Effekt zu fixen, mußte ich relativ tief in die internen Logiken eingreifen, was uns ggf. in anderen Konstellationen vor die Füße fallen kann. Ich habe zwar ein paar Fälle durchgespielt, und das sah auch ok aus, aber die Wirklichkeit ist erfahrungsgemäß bunter als meine Phantasie...
Deswegen bin ich noch etwas skeptisch, ob das schon der finale Fix ist ::) .
Alle 17 WTs sind korrekt. 8)
Viele Grüße
Jürgen
Zitat von: juemuc am 04 April 2023, 16:21:37Alle 17 WTs sind korrekt. 8)
Viele Grüße
Jürgen
Thx. Dann schaue ich bei Gelegenheit meine noch durch, und wenn sich bis dahin niemand wehrt, wird der fix eingecheckt...
Hmhh,
mit der aktuellen Version
$Id: 98_WeekdayTimer.pm 27423 2023-04-10 18:47:49Z Beta-User $
klappt irgendwie gar nichts mehr bei mir. Es verhalten sich nun noch mehr Timer äußerst seltsam.
Mit der alten Version gab es nur Probleme mit einem Timer, nun schalten plötzlich mehrere Timer das Programm von Samstag und Sonntag (07:00 Heizung an) statt das vom heutigen Freitag. Jedoch wurde bei einigen Timern das Programm nach dem Schließen von Fenstern wieder korrekt fortgeführt.
Uhrzeit fk.st.AZ.links fk.st.AZ.rechts fk.st.SZ.links fk.st.SZ.rechts hr.st.SZ hr.st.Flur
closed closed open closed 5,5° 17°
07:00 19°
...
07:36 open
07:38 open open
...
07:58 closed closed
08:00 closed closed 19°
...
08:14 17°
17°
Im obigen Beispiel hängt der Heizungsregler hr.st.Flur von den linken drei Fensterkontakten, der hr.st.SZ von den rechten beiden ab.
Die beiden Heizungsregler hr.st.Flur und hr.st.SZ sollten eigentlich nach Schließen der Fenster auf 17° stehen und erst um 15:31 auf 19° schalten.
Um 07:00 Uhr sollen beide lediglich am Samstag und Sonntag schalten.
List von hc.eg.Flur.SH.MB
Internals:
COMMAND
CONDITION (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Micha.Status","state", "") eq "Büro" and ReadingsVal("sc.Silke.Status","state", "") eq "Homeoffice")
DEF struct.Heizung.eg.Flur 1234|15:30:20|dm.Heizung.eg.Flur.temp.high 5|13:30:20|dm.Heizung.eg.Flur.temp.high 60|07:00:20|dm.Heizung.eg.Flur.temp.high 02:30:20|dm.Heizung.eg.Flur.temp.low (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Micha.Status","state", "") eq "Büro" and ReadingsVal("sc.Silke.Status","state", "") eq "Homeoffice")
DEVICE struct.Heizung.eg.Flur
FUUID 60868dae-f33f-c765-0c28-d6596044e6015b60
GlobalDaylistSpec
LANGUAGE en
NAME hc.eg.Flur.SH.MB
NR 1810
Profil 0: Sunday 02:30:20 dm.Heizung.eg.Flur.temp.low, 07:00:20 dm.Heizung.eg.Flur.temp.high,
Profil 1: Monday 02:30:20 dm.Heizung.eg.Flur.temp.low, 15:30:20 dm.Heizung.eg.Flur.temp.high,
Profil 2: Tuesday 02:30:20 dm.Heizung.eg.Flur.temp.low, 15:30:20 dm.Heizung.eg.Flur.temp.high,
Profil 3: Wednesday 02:30:20 dm.Heizung.eg.Flur.temp.low, 15:30:20 dm.Heizung.eg.Flur.temp.high,
Profil 4: Thursday 02:30:20 dm.Heizung.eg.Flur.temp.low, 15:30:20 dm.Heizung.eg.Flur.temp.high,
Profil 5: Friday 02:30:20 dm.Heizung.eg.Flur.temp.low, 13:30:20 dm.Heizung.eg.Flur.temp.high,
Profil 6: Saturday 02:30:20 dm.Heizung.eg.Flur.temp.low, 07:00:20 dm.Heizung.eg.Flur.temp.high,
STATE dm.Heizung.eg.Flur.temp.high
STILLDONETIME 0
TYPE WeekdayTimer
eventCount 58
setModifier desired-temp
READINGS:
2023-04-14 15:30:20 currValue dm.Heizung.eg.Flur.temp.high
2021-04-26 11:53:51 disabled 0
2023-04-14 15:30:20 nextUpdate 2023-04-15 02:30:20
2023-04-14 15:30:20 nextValue dm.Heizung.eg.Flur.temp.low
2023-04-14 15:30:20 state dm.Heizung.eg.Flur.temp.high
SWITCHINGTIMES:
1234|15:30:20|dm.Heizung.eg.Flur.temp.high
5|13:30:20|dm.Heizung.eg.Flur.temp.high
06|07:00:20|dm.Heizung.eg.Flur.temp.high
02:30:20|dm.Heizung.eg.Flur.temp.low
TIMER:
hc.eg.Flur.SH.MB_midnight:
HASH hc.eg.Flur.SH.MB
MODIFIER midnight
NAME hc.eg.Flur.SH.MB_midnight
SETTIMERATMIDNIGHT 1
helper:
daysRegExp (su|mo|tu|we|th|fr|sa|\$we|\!\$we)
daysRegExpMessage (su|mo|tu|we|th|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
02:30:20 dm.Heizung.eg.Flur.temp.low
07:00:20 dm.Heizung.eg.Flur.temp.high
1:
02:30:20 dm.Heizung.eg.Flur.temp.low
15:30:20 dm.Heizung.eg.Flur.temp.high
2:
02:30:20 dm.Heizung.eg.Flur.temp.low
15:30:20 dm.Heizung.eg.Flur.temp.high
3:
02:30:20 dm.Heizung.eg.Flur.temp.low
15:30:20 dm.Heizung.eg.Flur.temp.high
4:
02:30:20 dm.Heizung.eg.Flur.temp.low
15:30:20 dm.Heizung.eg.Flur.temp.high
5:
02:30:20 dm.Heizung.eg.Flur.temp.low
13:30:20 dm.Heizung.eg.Flur.temp.high
6:
02:30:20 dm.Heizung.eg.Flur.temp.low
07:00:20 dm.Heizung.eg.Flur.temp.high
WEDAYS:
1 1
2 1
profil:
1:
EPOCH 1681479020
PARA dm.Heizung.eg.Flur.temp.high
TIME 15:30:20
WE_Override
DAYS:
1
2
3
4
2:
EPOCH 1681471820
PARA dm.Heizung.eg.Flur.temp.high
TIME 13:30:20
WE_Override
DAYS:
5
3:
EPOCH 1681448420
PARA dm.Heizung.eg.Flur.temp.high
TIME 07:00:20
WE_Override
DAYS:
0
6
4:
EPOCH 1681432220
PARA dm.Heizung.eg.Flur.temp.low
TIME 02:30:20
WE_Override
DAYS:
0
1
2
3
4
5
6
profile_IDX:
0:
02:30:20 4
07:00:20 3
1:
02:30:20 4
15:30:20 1
2:
02:30:20 4
15:30:20 1
3:
02:30:20 4
15:30:20 1
4:
02:30:20 4
15:30:20 1
5:
02:30:20 4
13:30:20 2
6:
02:30:20 4
07:00:20 3
Attributes:
WDT_Group former_HC
WDT_delayedExecutionDevices hm.fk.st.Arbeitszimmer.links hm.fk.st.Arbeitszimmer.rechts hm.fk.st.Schlafzimmer.rechts
commandTemplate set $NAME desired-temp [$EVENT:state]
disable 0
room Heizung
switchInThePast 1
List von hc.st.Schlafzimmer.SH.MB
Internals:
COMMAND
CONDITION (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Micha.Status","state", "") eq "Büro" and ReadingsVal("sc.Silke.Status","state", "") eq "Homeoffice")
DEF struct.Heizung.st.Schlafzimmer 1234|15:31:00|dm.Heizung.st.Schlafzimmer.temp.high 5|15:01:00|dm.Heizung.st.Schlafzimmer.temp.high 60|07:01:00|dm.Heizung.st.Schlafzimmer.temp.high 1234560|21:01:00|dm.Heizung.st.Schlafzimmer.temp.low (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Micha.Status","state", "") eq "Büro" and ReadingsVal("sc.Silke.Status","state", "") eq "Homeoffice")
DEVICE struct.Heizung.st.Schlafzimmer
FUUID 60868de4-f33f-c765-0cb9-a9be825d1ffad321
GlobalDaylistSpec
LANGUAGE en
NAME hc.st.Schlafzimmer.SH.MB
NR 1811
Profil 0: Sunday 07:01:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
Profil 1: Monday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
Profil 2: Tuesday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
Profil 3: Wednesday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
Profil 4: Thursday 15:31:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
Profil 5: Friday 15:01:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
Profil 6: Saturday 07:01:00 dm.Heizung.st.Schlafzimmer.temp.high, 21:01:00 dm.Heizung.st.Schlafzimmer.temp.low,
STATE dm.Heizung.st.Schlafzimmer.temp.high
STILLDONETIME 0
TYPE WeekdayTimer
eventCount 401
setModifier desired-temp
READINGS:
2023-04-14 15:31:00 currValue dm.Heizung.st.Schlafzimmer.temp.high
2021-04-26 11:54:44 disabled 0
2023-04-14 15:31:00 nextUpdate 2023-04-14 21:01:00
2023-04-14 15:31:00 nextValue dm.Heizung.st.Schlafzimmer.temp.low
2023-04-14 15:31:00 state dm.Heizung.st.Schlafzimmer.temp.high
SWITCHINGTIMES:
1234|15:31:00|dm.Heizung.st.Schlafzimmer.temp.high
5|15:01:00|dm.Heizung.st.Schlafzimmer.temp.high
06|07:01:00|dm.Heizung.st.Schlafzimmer.temp.high
0123456|21:01:00|dm.Heizung.st.Schlafzimmer.temp.low
TIMER:
hc.st.Schlafzimmer.SH.MB_midnight:
HASH hc.st.Schlafzimmer.SH.MB
MODIFIER midnight
NAME hc.st.Schlafzimmer.SH.MB_midnight
SETTIMERATMIDNIGHT 1
helper:
daysRegExp (su|mo|tu|we|th|fr|sa|\$we|\!\$we)
daysRegExpMessage (su|mo|tu|we|th|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
07:01:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
1:
15:31:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
2:
15:31:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
3:
15:31:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
4:
15:31:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
5:
15:01:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
6:
07:01:00 dm.Heizung.st.Schlafzimmer.temp.high
21:01:00 dm.Heizung.st.Schlafzimmer.temp.low
WEDAYS:
1 1
2 1
profil:
1:
EPOCH 1681479060
PARA dm.Heizung.st.Schlafzimmer.temp.high
TIME 15:31:00
WE_Override
DAYS:
1
2
3
4
2:
EPOCH 1681477260
PARA dm.Heizung.st.Schlafzimmer.temp.high
TIME 15:01:00
WE_Override
DAYS:
5
3:
EPOCH 1681448460
PARA dm.Heizung.st.Schlafzimmer.temp.high
TIME 07:01:00
WE_Override
DAYS:
0
6
4:
EPOCH 1681498860
PARA dm.Heizung.st.Schlafzimmer.temp.low
TIME 21:01:00
WE_Override
DAYS:
0
1
2
3
4
5
6
profile_IDX:
0:
07:01:00 3
21:01:00 4
1:
15:31:00 1
21:01:00 4
2:
15:31:00 1
21:01:00 4
3:
15:31:00 1
21:01:00 4
4:
15:31:00 1
21:01:00 4
5:
15:01:00 2
21:01:00 4
6:
07:01:00 3
21:01:00 4
Attributes:
WDT_Group former_HC
WDT_delayedExecutionDevices hm.fk.st.Schlafzimmer.links hm.fk.st.Schlafzimmer.rechts
commandTemplate set $NAME desired-temp [$EVENT:state]
comment struct.Heizung.st.Schlafzimmer 12345|14:01:00|day 12345|21:31:00|night 60|07:01:00|day 60|21:31:00|night (ReadingsVal("sc.Heizung.Sommer", "state", "") eq "off" and ReadingsVal("sc.Urlaub.auswaerts", "state", "") eq "off" and ReadingsVal("sc.Micha.Status","state", "") eq "Büro" and ReadingsVal("sc.Silke.Status","state", "") eq "Homeoffice")
disable 0
room Heizung
switchInThePast 1
Was hat sich geändert?
Hmm, die aktuelle Version behandelt "06"-Tagesangaben "korrekt". Von daher sollten deine WDT sonntags in der Tat anders schalten als bisher. Aber eben nur sonntags...
Soweit die list das hergeben, wird das jeweilige Tagesprofil korrekt erkannt und umgesetzt. Kannst du mal prüfen, ob die vom Modul gesetzten Internen Timer passen?
"fhemdebug timerList" sollte die zeigen (das klappte aber grade bei mir nicht; wenn das bei dir auch der Fall ist, mach' bitte einen neuen Thread auf, damit Rudi sich das näher anschaut).
GuMo,
meine WeekdayTimer wurden nicht ausgeführt? Heizung bleibt kalt.
Exemplarisch das Büro
define HC_Buro WeekdayTimer Buro_Hzg_set 7|06:30|[Hzg_Tagestemperatur\:state] 8|08:30|[Hzg_Nachttemperatur\:state] 78|21:00|[Hzg_Nachttemperatur\:state] {fhem("set $NAME $EVENT") if(Value("HzgAuto") eq "on")}
attr HC_Buro WDT_Group former_HC
attr HC_Buro commandTemplate set $NAME $EVENT
attr HC_Buro disable 0
attr HC_Buro room FHT,Keller
# COMMAND {fhem("set $NAME $EVENT") if(Value("HzgAuto") eq "on")}
# CONDITION
# DEF Buro_Hzg_set 7|06:30|[Hzg_Tagestemperatur\:state] 8|08:30|[Hzg_Nachttemperatur\:state] 78|21:00|[Hzg_Nachttemperatur\:state] {fhem("set $NAME $EVENT") if(Value("HzgAuto") eq "on")}
# DEVICE Buro_Hzg_set
# FUUID 602b96d1-f33f-a0b3-a36f-1bd6e0befafb25aa
# GlobalDaylistSpec
# LANGUAGE en
# NAME HC_Buro
# NR 867
# Profil 0: Sunday 06:30:00 [Hzg_Tagestemperatur\:state], 21:00:00 [Hzg_Nachttemperatur\:state],
# Profil 1: Monday 08:30:00 [Hzg_Nachttemperatur\:state], 21:00:00 [Hzg_Nachttemperatur\:state],
# Profil 2: Tuesday 08:30:00 [Hzg_Nachttemperatur\:state], 21:00:00 [Hzg_Nachttemperatur\:state],
# Profil 3: Wednesday 08:30:00 [Hzg_Nachttemperatur\:state], 21:00:00 [Hzg_Nachttemperatur\:state],
# Profil 4: Thursday 08:30:00 [Hzg_Nachttemperatur\:state], 21:00:00 [Hzg_Nachttemperatur\:state],
# Profil 5: Friday 08:30:00 [Hzg_Nachttemperatur\:state], 21:00:00 [Hzg_Nachttemperatur\:state],
# Profil 6: Saturday 06:30:00 [Hzg_Tagestemperatur\:state], 21:00:00 [Hzg_Nachttemperatur\:state],
# Profil 7: weekend 06:30:00 [Hzg_Tagestemperatur\:state],
# Profil 8: weekdays 08:30:00 [Hzg_Nachttemperatur\:state],
# STATE [Hzg_Nachttemperatur\:state]
# STILLDONETIME 0
# TYPE WeekdayTimer
# eventCount 4
# READINGS:
# 2023-04-15 21:00:05 currValue [Hzg_Nachttemperatur\:state]
# 2021-02-16 10:56:33 disabled 0
# 2023-04-15 21:00:05 nextUpdate 2023-04-16 06:30:00
# 2023-04-15 21:00:05 nextValue [Hzg_Tagestemperatur\:state]
# 2023-04-15 21:00:05 state [Hzg_Nachttemperatur\:state]
# SWITCHINGTIMES:
# 7|06:30|[Hzg_Tagestemperatur\:state]
# 8|08:30|[Hzg_Nachttemperatur\:state]
# 0123456|21:00|[Hzg_Nachttemperatur\:state]
# TIMER:
# HC_Buro_3:
# HASH HC_Buro
# MODIFIER 3
# NAME HC_Buro_3
# HC_Buro_midnight:
# HASH HC_Buro
# MODIFIER midnight
# NAME HC_Buro_midnight
# SETTIMERATMIDNIGHT 1
# helper:
# daysRegExp (su|mo|tu|we|th|fr|sa|\$we|\!\$we)
# daysRegExpMessage (su|mo|tu|we|th|fr|sa|$we|!$we)
# SWITCHINGTIME:
# 0:
# 06:30:00 [Hzg_Tagestemperatur\:state]
# 21:00:00 [Hzg_Nachttemperatur\:state]
# 1:
# 08:30:00 [Hzg_Nachttemperatur\:state]
# 21:00:00 [Hzg_Nachttemperatur\:state]
# 2:
# 08:30:00 [Hzg_Nachttemperatur\:state]
# 21:00:00 [Hzg_Nachttemperatur\:state]
# 3:
# 08:30:00 [Hzg_Nachttemperatur\:state]
# 21:00:00 [Hzg_Nachttemperatur\:state]
# 4:
# 08:30:00 [Hzg_Nachttemperatur\:state]
# 21:00:00 [Hzg_Nachttemperatur\:state]
# 5:
# 08:30:00 [Hzg_Nachttemperatur\:state]
# 21:00:00 [Hzg_Nachttemperatur\:state]
# 6:
# 06:30:00 [Hzg_Tagestemperatur\:state]
# 21:00:00 [Hzg_Nachttemperatur\:state]
# 7:
# 06:30:00 [Hzg_Tagestemperatur\:state]
# 8:
# 08:30:00 [Hzg_Nachttemperatur\:state]
# WEDAYS:
# 0 1
# 6 1
# profil:
# 1:
# EPOCH 1681619400
# PARA [Hzg_Tagestemperatur\:state]
# TIME 06:30
# WE_Override
# DAYS:
# 7
# 2:
# EPOCH 1681626600
# PARA [Hzg_Nachttemperatur\:state]
# TIME 08:30
# WE_Override
# DAYS:
# 8
# 3:
# EPOCH 1681671600
# PARA [Hzg_Nachttemperatur\:state]
# TIME 21:00
# WE_Override
# DAYS:
# 0
# 1
# 2
# 3
# 4
# 5
# 6
# profile_IDX:
# 0:
# 06:30:00 1
# 21:00:00 3
# 1:
# 08:30:00 2
# 21:00:00 3
# 2:
# 08:30:00 2
# 21:00:00 3
# 3:
# 08:30:00 2
# 21:00:00 3
# 4:
# 08:30:00 2
# 21:00:00 3
# 5:
# 08:30:00 2
# 21:00:00 3
# 6:
# 06:30:00 1
# 21:00:00 3
# 7:
# 06:30:00 1
# 8:
# 08:30:00 2
#
setstate HC_Buro [Hzg_Nachttemperatur\:state]
setstate HC_Buro 2023-04-15 21:00:05 currValue [Hzg_Nachttemperatur\:state]
setstate HC_Buro 2021-02-16 10:56:33 disabled 0
setstate HC_Buro 2023-04-15 21:00:05 nextUpdate 2023-04-16 06:30:00
setstate HC_Buro 2023-04-15 21:00:05 nextValue [Hzg_Tagestemperatur\:state]
setstate HC_Buro 2023-04-15 21:00:05 state [Hzg_Nachttemperatur\:state]
Guten Morgen,
ich muss das Verhalten leider bestätigen. Das Schalten am Wochenende funktioniert nicht.
VG
Torsten
My WeekdayTimers are also completely broken since changeset 27423. Not sure what is happening... The module worked fine for years.
defmod WDT_OTGW_0 WeekdayTimer OTGW_0 tu,th|08:00|18 !$we|17:00|12
This timer started heating today (monday) at 8h. :o
Guten Morgen zusammen.
Bir mir erscheinen seit meinem letzten Update folgende Fehlermeldungen im Log:
2023.04.17 09:24:19 0: Featurelevel: 6.2
2023.04.17 09:24:19 0: Server started with 233 defined entities (fhem.pl:27410/2023-04-07 perl:5.024001 os:linux user:fhem pid:21914)
2023.04.17 09:24:19 1: PERL WARNING: Use of uninitialized value $condition in concatenation (.) or string at ./FHEM/98_WeekdayTimer.pm line 1289.
2023.04.17 09:24:19 1: stacktrace:
2023.04.17 09:24:19 1: main::__ANON__ called by ./FHEM/98_WeekdayTimer.pm (1289)
2023.04.17 09:24:19 1: FHEM::WeekdayTimer::checkDaysCondition called by ./FHEM/98_WeekdayTimer.pm (814)
2023.04.17 09:24:19 1: FHEM::WeekdayTimer::_SetTimer called by ./FHEM/98_WeekdayTimer.pm (780)
2023.04.17 09:24:19 1: FHEM::WeekdayTimer::WDT_SetTimerOfDay called by ./FHEM/98_WeekdayTimer.pm (218)
2023.04.17 09:24:19 1: FHEM::WeekdayTimer::WDT_Start called by fhem.pl (3503)
2023.04.17 09:24:19 1: main::HandleTimeout called by fhem.pl (705)
2023.04.17 09:24:19 1: PERL WARNING: Use of uninitialized value $condition in concatenation (.) or string at ./FHEM/98_WeekdayTimer.pm line 1289.
2023.04.17 09:24:19 1: stacktrace:
2023.04.17 09:24:19 1: main::__ANON__ called by ./FHEM/98_WeekdayTimer.pm (1289)
2023.04.17 09:24:19 1: FHEM::WeekdayTimer::checkDaysCondition called by ./FHEM/98_WeekdayTimer.pm (814)
2023.04.17 09:24:19 1: FHEM::WeekdayTimer::_SetTimer called by ./FHEM/98_WeekdayTimer.pm (780)
2023.04.17 09:24:19 1: FHEM::WeekdayTimer::WDT_SetTimerOfDay called by ./FHEM/98_WeekdayTimer.pm (218)
2023.04.17 09:24:19 1: FHEM::WeekdayTimer::WDT_Start called by fhem.pl (3503)
2023.04.17 09:24:19 1: main::HandleTimeout called by fhem.pl (705)
2023.04.17 09:24:20 3: RemoteHmUART device opened
2023.04.17 09:24:23 3: ESPEasy ESPEasy_Sonoff_S20_2_WZ_Lampe: set ESPEasy_Sonoff_S20_2_WZ_Lampe gpio 12 off
2023.04.17 09:25:25 3: CUL_HM start Queues
Der Weekdaytimer scheint zu funktionieren, aber trotzdem kommen ab und an diese Fehlereinträge.
Hier meine Definition:
defmod Molly_Strom_an WeekdayTimer ESPEasy_Sonoff_S20_5_Molly de 1356|12:00|on 0123456|19:30|off
attr Molly_Strom_an commandTemplate set $NAME $EVENT
attr Molly_Strom_an disable 0
attr Molly_Strom_an room Molly
Ich sehe da nichts Falsches.
Hat jemand eine Idee woran das liegen könnte?
Vielen Dank
Janot
I have the same warning at startup. It means the dev forgot to initialize a variable but I rolled back to rev. 27118 since the module is broken since the last update.
2023.04.16 12:30:48 1: PERL WARNING: Use of uninitialized value $condition in concatenation (.) or string at ./FHEM/98_WeekdayTimer.pm line 1289.
Hallo zusammen,
(@Nestor: afaik, you are able to read in German, right?)
Vorab mal sorry für die Unannehmlichkeiten. Und Danke für den Hinweis auf das, was im Log steht!
Bin zwar nicht sicher, ob ich damit abschließend die tiefere Ursache für das gefunden habe, das da bei manchen (?) schiefgeht, aber es würde mir helfen, wenn die Betroffenen mal bitte die Zeile 1311 (aktuelle svn-Version) so ändern könnten:
my $overrulewday = shift // 0; #return;
Danach einen einen FHEM-Neustart, damit auch die Timer neu angelegt werden.
Welche Timer das Modul anlegt, ist dann über
fhemdebug timerListersichtlich.
Habe im Moment noch Zweifel, ob das "nur" das Verhalten unter der Woche repariert, oder auch schon ausreichend ist, damit das am WE korrekt funktioniert.
Hallo Beta-User,
ich habe die Änderung durchgeführt und erhalte jetzt beim Neustart keine Fehlermeldung mehr.
Vielen Dank für die schnelle Reaktion!
Danke für diese erste Rückmeldung.
Wie gesagt: ob das "nur" den Log-Eintrag verhindert, oder ob es auch den viel wichtigeren Effekt hat, dass alle InternalTimer korrekt angelegt werden, sieht mal leider nicht an einem list oder so, sondern nur mit dem angegebenen fhemdebug-Befehl. Erfahrungsgemäß muss es auch nur bedingt was heißen, wenn es heute paßt, weil wir auch schon den Fall hatten, dass es sich erst nach dem "Tageswechsel" gezeigt hat, ob alles korrekt funktioniert.
Wenn man sich die lists von Mark und netwalk anschaut, kann man gut erkennen, dass das Modul am Vortag noch wußte, dass morgen ein $we-Tag ist (nextUpdate), am $we-Tag selbst hat das Modul diesen dann nicht mehr als solchen erkannt (und wohl gar keine Timer gesetzt? - wissen wir leider nicht).
Zumindest auf meinem Testsystem sah es mit diesem kleinen Fix plausibel aus, das Problem scheint mit dem "erweiterten Informationsgehalt" des "WE_Override"-Werts in jedem profile zusammenzuhängen. Der war früher ausschließlich 0 oder 1.
Ich habe nach längerer Zeit meine FHEM-Installation aktualisiert.
Wieso wurde heute (Dienstag) das Event auch um 6:00 ausgelöst? Es hätte doch nur um 05:00 der Weckermodus1 ausgelöst werden sollen.
Muss ich bei der Definition etwas nachziehen?
defmod Weckerplan WeekdayTimer wecker_ctrl de 124|05:00|Weckermodus1 35|06:00|Weckermodus2 { fhem("set $NAME $EVENT");; }
attr Weckerplan commandTemplate set $NAME $EVENT
attr Weckerplan disable 0
attr Weckerplan group Beleuchtung,BeleuchtungCtrl,Multimedia,Personen,Wecker
attr Weckerplan room Wohnung
attr Weckerplan verbose 5
setstate Weckerplan Weckermodus2
setstate Weckerplan 2023-04-18 06:00:00 currValue Weckermodus1
setstate Weckerplan 2023-04-10 14:36:48 disabled 0
setstate Weckerplan 2023-04-18 06:00:00 nextUpdate 2023-04-19 06:00:00
setstate Weckerplan 2023-04-18 06:00:00 nextValue Weckermodus2
setstate Weckerplan 2023-04-18 06:00:00 state Weckermodus2
2023.04.18 00:00:05 4: [Weckerplan] 05:00:00 Weckermodus1, (Profil 1: Montag)
2023.04.18 00:00:05 4: [Weckerplan] 05:00:00 Weckermodus1, (Profil 2: Dienstag)
2023.04.18 00:00:05 4: [Weckerplan] 06:00:00 Weckermodus2, (Profil 3: Mittwoch)
2023.04.18 00:00:05 4: [Weckerplan] 05:00:00 Weckermodus1, (Profil 4: Donnerstag)
2023.04.18 00:00:05 4: [Weckerplan] 06:00:00 Weckermodus2, (Profil 5: Freitag)
2023.04.18 00:00:05 4: [Weckerplan] check days:1,2,4
2023.04.18 00:00:05 5: [Weckerplan] check days: my $days = {} ; map{ $days->{$_} = 1 }(1,2,4) ;
2023.04.18 00:00:05 5: [Weckerplan] result of check days: 3
2023.04.18 00:00:05 4: [Weckerplan] setTimer - timer seems to be active today: 124|05:00|Weckermodus1
2023.04.18 00:00:05 5: [Weckerplan] setting Timer: Weckerplan_1 2023-04-18 05:00:00
2023.04.18 00:00:05 4: [Weckerplan] check days:3,5
2023.04.18 00:00:05 5: [Weckerplan] check days: my $days = {} ; map{ $days->{$_} = 1 }(3,5) ;
2023.04.18 00:00:05 5: [Weckerplan] result of check days: 2
2023.04.18 00:00:05 4: [Weckerplan] setTimer - timer seems to be active today: 35|06:00|Weckermodus2
2023.04.18 00:00:05 5: [Weckerplan] setting Timer: Weckerplan_2 2023-04-18 06:00:00
2023.04.18 00:00:05 5: [Weckerplan] removing Timer: Weckerplan_midnight
2023.04.18 00:00:05 5: [Weckerplan] setting Timer: Weckerplan_midnight 2023-04-19 00:00:05
2023.04.18 05:00:00 4: [Weckerplan] time=05:00/1681786800 delay=0, nextDelay=60, nextRetry=1681786860
2023.04.18 05:00:00 4: [Weckerplan] list of window sensors found: 'Weckerplan'
2023.04.18 05:00:00 4: [Weckerplan] Update - timer seems to be active today: 124|05:00|Weckermodus1
2023.04.18 05:00:00 5: [Weckerplan] removing Timer: Weckerplan_1
2023.04.18 05:00:00 4: [Weckerplan] aktParam: newParam:Weckermodus1 - is not disabled
2023.04.18 05:00:00 4: dummy set wecker_ctrl Weckermodus1
2023.04.18 05:00:00 4: [Weckerplan] command: '{ fhem("set $NAME $EVENT");; }' executed with %EVENT=>Weckermodus1,%NAME=>wecker_ctrl
2023.04.18 06:00:00 4: [Weckerplan] time=06:00/1681790400 delay=0, nextDelay=60, nextRetry=1681790460
2023.04.18 06:00:00 4: [Weckerplan] list of window sensors found: 'Weckerplan'
2023.04.18 06:00:00 4: [Weckerplan] Update - timer seems to be active today: 35|06:00|Weckermodus2
2023.04.18 06:00:00 5: [Weckerplan] removing Timer: Weckerplan_2
2023.04.18 06:00:00 4: [Weckerplan] aktParam: newParam:Weckermodus2 - is not disabled
2023.04.18 06:00:00 4: dummy set wecker_ctrl Weckermodus2
2023.04.18 06:00:00 4: [Weckerplan] command: '{ fhem("set $NAME $EVENT");; }' executed with %NAME=>wecker_ctrl,%EVENT=>Weckermodus2
Hmm, da sich zwar die Beschwerden häufen, aber immer noch nur eine (positive) Rückmeldung zu dem fix vorliegt, habe ich das eben eingecheckt in der Hoffnung, dass es (in allen Fällen) hilft.
Bitte bei eventuellen künftigen Beschwerden prüfen, ob und welche Timer (neben dem Mitternachtstimer) angelegt wurden (das "fhemdebug timerList" gibt Auskunft).
Hallo Beta,
hat sich am Mitternachtstimer etwas geändert? Der wird bei mir mit 5 Sekunden nach Mitternacht angezeigt und vielleicht sind zu diesem Zeitpunkt noch nicht alle anderen Werte wie z.b. die Feiertage oder sonstige Kalenderdaten ermittelt.
VG
Torsten
Hallo Beta,
vielen Dank für Deine unermüdliche Arbeit! Ich nutze den WeekDayTimer, um regelmäßig meine RGB Lampen auf die "Farbe des Tages" einzustellen. Dazu lass ich den WDT regelmäßig per "at" auf "enable" setzen. Durch "SwitchInThePast" setzt das "enable" jewiels den aktuell gültigen Befehl ab. Bis vor Kurzem hat dies einwandfrei funktioniert, jetzt aber habe ich das Problem, dass bei "enable" der aktuell gültige Befehl nur bei den "weekdays" 7 und 8 erneut abgesetzt wird. Bei "weekdays" 0-6 oder So-Mo wird der aktuell gültige Befehl nicht ausgeführt.
Beim regulären Erreichen des Timers wird der neue Befehl ordnungsgemäß auch für die einzelnen Tage ausgeführt.
Beispiel 1: weekday 8
defmod WDT_LichtFarbe_debug_2 WeekdayTimer ML_Geraete de 8|00:00|hue:100
attr WDT_LichtFarbe_debug_2 commandTemplate set $NAME $EVENT
attr WDT_LichtFarbe_debug_2 disable 0
attr WDT_LichtFarbe_debug_2 room Kontrollraum,MQTT2_DEVICE
attr WDT_LichtFarbe_debug_2 switchInThePast 1
attr WDT_LichtFarbe_debug_2 verbose 5
setstate WDT_LichtFarbe_debug_2 hue:100
setstate WDT_LichtFarbe_debug_2 2023-04-18 20:54:42 currValue hue:100
setstate WDT_LichtFarbe_debug_2 2023-04-17 20:43:11 disabled 0
setstate WDT_LichtFarbe_debug_2 2023-04-18 20:54:42 nextUpdate 2023-04-19 00:00:00
setstate WDT_LichtFarbe_debug_2 2023-04-18 20:54:42 nextValue hue:100
setstate WDT_LichtFarbe_debug_2 2023-04-18 20:54:42 state hue:100
Im fhem log:
2023.04.18 20:57:37 3: [WDT_LichtFarbe_debug_2] set WDT_LichtFarbe_debug_2 enable
2023.04.18 20:57:37 4: [WDT_LichtFarbe_debug_2] 00:00:00 hue:100, (Profil 1: Montag)
2023.04.18 20:57:37 4: [WDT_LichtFarbe_debug_2] 00:00:00 hue:100, (Profil 2: Dienstag)
2023.04.18 20:57:37 4: [WDT_LichtFarbe_debug_2] 00:00:00 hue:100, (Profil 3: Mittwoch)
2023.04.18 20:57:37 4: [WDT_LichtFarbe_debug_2] 00:00:00 hue:100, (Profil 4: Donnerstag)
2023.04.18 20:57:37 4: [WDT_LichtFarbe_debug_2] 00:00:00 hue:100, (Profil 5: Freitag)
2023.04.18 20:57:37 4: [WDT_LichtFarbe_debug_2] 00:00:00 hue:100, (Profil 8: Werktags)
2023.04.18 20:57:37 4: [WDT_LichtFarbe_debug_2] check days:8
2023.04.18 20:57:37 5: [WDT_LichtFarbe_debug_2] check days: my $days = {} ; map{ $days->{$_} = 1 }() ; defined $days->{$wday} || !$we
2023.04.18 20:57:37 5: [WDT_LichtFarbe_debug_2] result of check days: 1
2023.04.18 20:57:37 4: [WDT_LichtFarbe_debug_2] time=00:00/1681768800 delay=75457, nextDelay=75540, nextRetry=1681844340
2023.04.18 20:57:37 4: [WDT_LichtFarbe_debug_2] list of window sensors found: 'WDT_LichtFarbe_debug_2'
2023.04.18 20:57:37 4: [WDT_LichtFarbe_debug_2] past timer on ML_Geraete at 2023-04-18 00:00:00 with hue:100 activated
2023.04.18 20:57:37 5: [WDT_LichtFarbe_debug_2] setting Timer: WDT_LichtFarbe_debug_2_delayed 2023-04-18 20:57:42
2023.04.18 20:57:37 5: [WDT_LichtFarbe_debug_2] removing Timer: WDT_LichtFarbe_debug_2_midnight
2023.04.18 20:57:37 5: [WDT_LichtFarbe_debug_2] setting Timer: WDT_LichtFarbe_debug_2_midnight 2023-04-19 00:00:05
2023.04.18 20:57:42 4: [WDT_LichtFarbe_debug_2] ML_Geraete 2023-04-18 00:00:00 75462s
2023.04.18 20:57:42 5: [WDT_LichtFarbe_debug_2] setting Timer: WDT_LichtFarbe_debug_2_1 2023-04-18 00:00:00
2023.04.18 20:57:42 5: [WDT_LichtFarbe_debug_2] removing Timer: WDT_LichtFarbe_debug_2_delayed
2023.04.18 20:57:42 4: [WDT_LichtFarbe_debug_2] time=00:00/1681768800 delay=75462, nextDelay=75540, nextRetry=1681844340
2023.04.18 20:57:42 4: [WDT_LichtFarbe_debug_2] list of window sensors found: 'WDT_LichtFarbe_debug_2'
2023.04.18 20:57:42 4: [WDT_LichtFarbe_debug_2] check days:8
2023.04.18 20:57:42 5: [WDT_LichtFarbe_debug_2] check days: my $days = {} ; map{ $days->{$_} = 1 }() ; defined $days->{$wday} || !$we
2023.04.18 20:57:42 5: [WDT_LichtFarbe_debug_2] result of check days: 1
2023.04.18 20:57:42 4: [WDT_LichtFarbe_debug_2] Update - past timer activated
2023.04.18 20:57:42 5: [WDT_LichtFarbe_debug_2] removing Timer: WDT_LichtFarbe_debug_2_1
2023.04.18 20:57:42 4: [WDT_LichtFarbe_debug_2] aktParam: newParam:hue:100 - is not disabled
2023.04.18 20:57:42 4: dummy set ML_Geraete hue 100
2023.04.18 20:57:42 4: [WDT_LichtFarbe_debug_2] command: 'set $NAME $EVENT' executed with %EVENT=>hue 100,%NAME=>ML_Geraete
Der Befehl "set ML_Geraete hue 100" wird ausgeführt.
Beispiel 2: weekday 2
defmod WDT_LichtFarbe_debug_1 WeekdayTimer ML_Geraete de 1|20:00|hue:10 2|21:10|hue:275
attr WDT_LichtFarbe_debug_1 commandTemplate set $NAME $EVENT
attr WDT_LichtFarbe_debug_1 disable 0
attr WDT_LichtFarbe_debug_1 room Kontrollraum,MQTT2_DEVICE
attr WDT_LichtFarbe_debug_1 switchInThePast 1
attr WDT_LichtFarbe_debug_1 verbose 5
setstate WDT_LichtFarbe_debug_1 hue:10
setstate WDT_LichtFarbe_debug_1 2023-04-18 21:00:43 currValue hue:10
setstate WDT_LichtFarbe_debug_1 2023-04-18 19:31:22 disabled 0
setstate WDT_LichtFarbe_debug_1 2023-04-18 21:00:43 nextUpdate 2023-04-18 21:10:00
setstate WDT_LichtFarbe_debug_1 2023-04-18 21:00:43 nextValue hue:275
setstate WDT_LichtFarbe_debug_1 2023-04-18 21:00:43 state hue:10
fhem log bei "enable":
2023.04.18 21:02:05 3: [WDT_LichtFarbe_debug_1] set WDT_LichtFarbe_debug_1 enable
2023.04.18 21:02:05 5: [WDT_LichtFarbe_debug_1] removing Timer: WDT_LichtFarbe_debug_1_2
2023.04.18 21:02:05 4: [WDT_LichtFarbe_debug_1] 20:00:00 hue:10, (Profil 1: Montag)
2023.04.18 21:02:05 4: [WDT_LichtFarbe_debug_1] 21:10:00 hue:275, (Profil 2: Dienstag)
2023.04.18 21:02:05 4: [WDT_LichtFarbe_debug_1] check days:1
2023.04.18 21:02:05 5: [WDT_LichtFarbe_debug_1] check days: my $days = {} ; map{ $days->{$_} = 1 }(1) ;
2023.04.18 21:02:05 5: [WDT_LichtFarbe_debug_1] result of check days: 1
2023.04.18 21:02:05 4: [WDT_LichtFarbe_debug_1] check days:2
2023.04.18 21:02:05 5: [WDT_LichtFarbe_debug_1] check days: my $days = {} ; map{ $days->{$_} = 1 }(2) ;
2023.04.18 21:02:05 5: [WDT_LichtFarbe_debug_1] result of check days: 1
2023.04.18 21:02:05 4: [WDT_LichtFarbe_debug_1] setTimer - timer seems to be active today: 2|21:10|hue:275
2023.04.18 21:02:05 5: [WDT_LichtFarbe_debug_1] setting Timer: WDT_LichtFarbe_debug_1_2 2023-04-18 21:10:00
2023.04.18 21:02:05 4: [WDT_LichtFarbe_debug_1] time=20:00/1681840800 delay=3725, nextDelay=3780, nextRetry=1681844580
2023.04.18 21:02:05 4: [WDT_LichtFarbe_debug_1] list of window sensors found: 'WDT_LichtFarbe_debug_1'
2023.04.18 21:02:05 4: [WDT_LichtFarbe_debug_1] past timer on ML_Geraete at 2023-04-17 20:00:00 with hue:10 activated
2023.04.18 21:02:05 5: [WDT_LichtFarbe_debug_1] setting Timer: WDT_LichtFarbe_debug_1_delayed 2023-04-18 21:02:10
2023.04.18 21:02:05 5: [WDT_LichtFarbe_debug_1] removing Timer: WDT_LichtFarbe_debug_1_midnight
2023.04.18 21:02:05 5: [WDT_LichtFarbe_debug_1] setting Timer: WDT_LichtFarbe_debug_1_midnight 2023-04-19 00:00:05
2023.04.18 21:02:10 4: [WDT_LichtFarbe_debug_1] ML_Geraete 2023-04-17 20:00:00 90130s
2023.04.18 21:02:10 5: [WDT_LichtFarbe_debug_1] setting Timer: WDT_LichtFarbe_debug_1_1 2023-04-17 20:00:00
2023.04.18 21:02:10 5: [WDT_LichtFarbe_debug_1] removing Timer: WDT_LichtFarbe_debug_1_delayed
2023.04.18 21:02:10 4: [WDT_LichtFarbe_debug_1] time=20:00/1681840800 delay=3730, nextDelay=3780, nextRetry=1681844580
2023.04.18 21:02:10 4: [WDT_LichtFarbe_debug_1] list of window sensors found: 'WDT_LichtFarbe_debug_1'
2023.04.18 21:02:10 4: [WDT_LichtFarbe_debug_1] check days:8
2023.04.18 21:02:10 5: [WDT_LichtFarbe_debug_1] check days: my $days = {} ; map{ $days->{$_} = 1 }() ;
2023.04.18 21:02:10 5: [WDT_LichtFarbe_debug_1] result of check days: 0
2023.04.18 21:02:10 4: [WDT_LichtFarbe_debug_1] Update - past timer activated
2023.04.18 21:02:10 5: [WDT_LichtFarbe_debug_1] removing Timer: WDT_LichtFarbe_debug_1_1
Hier fehlt die Zeile mit "aktParam: newParam:hue:100 - is not disabled", es wird kein set-Befehl abgesetzt.
...und fhem log beim Erreichen des Timer:
2023.04.18 21:10:00 4: [WDT_LichtFarbe_debug_1] time=21:10/1681845000 delay=0, nextDelay=60, nextRetry=1681845060
2023.04.18 21:10:00 4: [WDT_LichtFarbe_debug_1] list of window sensors found: 'WDT_LichtFarbe_debug_1'
2023.04.18 21:10:00 4: [WDT_LichtFarbe_debug_1] Update - timer seems to be active today: 2|21:10|hue:275
2023.04.18 21:10:00 5: [WDT_LichtFarbe_debug_1] removing Timer: WDT_LichtFarbe_debug_1_2
2023.04.18 21:10:00 4: [WDT_LichtFarbe_debug_1] aktParam: newParam:hue:275 - is not disabled
2023.04.18 21:10:00 4: dummy set ML_Geraete hue 275
2023.04.18 21:10:00 4: [WDT_LichtFarbe_debug_1] command: 'set $NAME $EVENT' executed with %EVENT=>hue 275,%NAME=>ML_Geraete
Der set-Befehl wird ordnungsgemäß ausgeführt.
Gib bitte Bescheid, wenn ich noch mit weiteren Informationen helfen kann, um das Problem zu lösen
Danke!
Matthias.
Der letzte Fix hat mein Problem gelöst.
Vielen Dank
Guten Morgen,
Feedback zu 98_WeekdayTimer.pm 27423 2023-04-10 18:47:49Z Beta-User
Mit dieser Version werden die Timer in der Woche mit "fhemdebug timerList" korrekt angezeigt und geschaltet.
Ich gehe davon aus, dass das am Wochenende auch funktionieren wird. Wenn nicht melde ich mich noch einmal.
Auch von mir natürlich ein grosses Dankeschön an Deine Arbeit.
Viele Grüße
Mark
2023-04-20 21:00:00.00000 WDT_Update HC_Buro_3
2023-04-20 21:00:00.00000 WDT_Update HC_Flur_4
2023-04-20 21:00:00.00000 WDT_Update HC_Kueche_3
2023-04-20 21:00:00.00000 WDT_Update HC_WZ_1
2023-04-20 23:00:00.00000 WDT_Update HC_WZ_2
2023-04-20 23:59:00.00000 WDT_Update HC_Flur_5
2023-04-21 00:00:05.00000 WDT_SetTimerOfDay HC_Bad_midnight
2023-04-21 00:00:05.00000 WDT_SetTimerOfDay HC_Buro_midnight
2023-04-21 00:00:05.00000 WDT_SetTimerOfDay HC_Flur_midnight
2023-04-21 00:00:05.00000 WDT_SetTimerOfDay HC_Kueche_midnight
2023-04-21 00:00:05.00000 WDT_SetTimerOfDay HC_WZ_midnight
2023-04-21 00:00:05.00000 WDT_SetTimerOfDay HC_Warmwasser_midnight
Guten Morgen zusammen,
Danke für die positiven Rückmeldungen zum letzten Fix.
Wäre nett, wenn die anderen User, die zwar Probleme gemeldet haben, aber den Fix nicht vorab getestet, dann auch nochmal rückmelden könnten, ob das auch ihr Problem gelöst hat.
Vielleicht noch eine persönliche Anmerkung:
Grade, wenn man was umstellt, besteht leider immer die Gefahr einer Regression, und ich habe lange gezögert, ob ich jetzt einfach erst mal wieder auf den alten Stand zurückdrehen soll oder eben den weiteren Schritt nach vorne gehen. Entsprechende zeitnahe Rückmeldungen zu den vorab gezeigten Patches wäre da (besonders) wünschenswert gewesen.
So bin ich etwas verhalten, was die Weiterentwicklung in Richtung "Tag vor WE" etc. angeht (werde ich aber trotzdem auf dem Zettel behalten für demnächst mal irgendwann!).
Grüße, Beta-User
Hi Beta-User,
bei mir weiterhin alles ok.
Danke für Deine Unterstützung und Deine Arbeit.
Viele Grüße
Jürgen
Hallo Beta,
danke für Deine tolle Arbeit. Im Moment sieht alles gut aus. Falls es am WE wieder nicht klappt, melde ich mich.
VG
Torsten
Hi Beta,
ich habe heute morgen ein "update" durchgeführt und jetzt verhält sich mein WeekDayTimer wie vorher, bei "set enable" werden die commands auch ausgeführt.
Danke für Deine Hilfe!
Matthias.
Hallo Beta-User,
mit dem letzten Update wurde der alte Zustand wiederhergestellt. D.h. der Timer funktioniert unter der Woche korrekt, am Samstag und Sonntag jedoch nicht, kann aber durch ein "set enable" wieder aktiviert werden.
Am nächsten WE werde ich mir vorher mit fhemdebug die Timer ansehen und berichten.
Hallo Beta,
bei mir wird heute der Feiertag vom weekdaytimer nicht erkannt. Meine Heizungen schalten wie an einem Wochentag.
define E2_ez_THKV_Heizkoerper_Fenster_hC_01 WeekdayTimer E2_ez_THKV_Heizkoerper_Fenster de !$we|05:45|comfort !$we|08:00|eco:1 !$we|14:30|comfort !$we|22:30|eco:0 $we|07:45|comfort $we|23:00|eco:0 { myHeatingControl_Single($NAME,$EVENT) }
attr E2_ez_THKV_Heizkoerper_Fenster_hC_01 WDT_Group HC
attr E2_ez_THKV_Heizkoerper_Fenster_hC_01 WDT_sendDelay 120
attr E2_ez_THKV_Heizkoerper_Fenster_hC_01 alias Esszimmer
attr E2_ez_THKV_Heizkoerper_Fenster_hC_01 commandTemplate set $NAME desired-temp $EVENT
attr E2_ez_THKV_Heizkoerper_Fenster_hC_01 disable 0
attr E2_ez_THKV_Heizkoerper_Fenster_hC_01 event-on-change-reading .*
attr E2_ez_THKV_Heizkoerper_Fenster_hC_01 group Zeitsteuerung Heizung
attr E2_ez_THKV_Heizkoerper_Fenster_hC_01 mqttDefaults floorID={substr $device,0,2} roomID={substr $device,3,2} devName={substr $device,6}
attr E2_ez_THKV_Heizkoerper_Fenster_hC_01 mqttPublish disabled|currValue|nextUpdate|nextValue:topic={"$base/$floorID/$roomID/$devName/$reading"}\
WDT_Group|WDT_sendDelay:atopic={"$base/$floorID/$roomID/$devName/$reading"}
attr E2_ez_THKV_Heizkoerper_Fenster_hC_01 mqttSubscribe disable:atopic={"$base/$floorID/$roomID/$devName/disable"}
attr E2_ez_THKV_Heizkoerper_Fenster_hC_01 room Esszimmer,Heizungsraum
attr E2_ez_THKV_Heizkoerper_Fenster_hC_01 sortby 1
attr E2_ez_THKV_Heizkoerper_Fenster_hC_01 stateFormat {if (ReadingsVal("E2_ez_THKV_Heizkoerper_Fenster_hC_01","disabled","1") == 1) {\
return "disabled"\
} else {\
my $cValue = ReadingsVal("E2_ez_THKV_Heizkoerper_Fenster_hC_01","currValue","");;\
my $idx = index($cValue,":");;\
if ($idx != -1) {\
$cValue = substr($cValue,0,$idx);;\
}\
my $nValue = ReadingsVal("E2_ez_THKV_Heizkoerper_Fenster_hC_01","nextValue","");;\
$idx = index($nValue,":");;\
if ($idx != -1) {\
$nValue = substr($nValue,0,$idx);;\
}\
return "nächste Schaltung: ".ReadingsVal("E2_ez_THKV_Heizkoerper_Fenster_hC_01","nextUpdate","")." ".$cValue." ==> ".$nValue\
}\
}
attr E2_ez_THKV_Heizkoerper_Fenster_hC_01 widgetOverride WDT_sendDelay:textField
# COMMAND { myHeatingControl_Single($NAME,$EVENT) }
# CONDITION
# DEF E2_ez_THKV_Heizkoerper_Fenster de !$we|05:45|comfort !$we|08:00|eco:1 !$we|14:30|comfort !$we|22:30|eco:0 $we|07:45|comfort $we|23:00|eco:0 { myHeatingControl_Single($NAME,$EVENT) }
# DEVICE E2_ez_THKV_Heizkoerper_Fenster
# FUUID 5cd810d1-f33f-2e5f-6954-86a735ac575ac0b8
# FVERSION 98_WeekdayTimer.pm:0.274600/2023-04-18
# GlobalDaylistSpec
# LANGUAGE de
# NAME E2_ez_THKV_Heizkoerper_Fenster_hC_01
# NR 209
# Profil 0: Sonntag 07:45:00 comfort, 23:00:00 eco:0,
# Profil 1: Montag 05:45:00 comfort, 08:00:00 eco:1, 14:30:00 comfort, 22:30:00 eco:0,
# Profil 2: Dienstag 05:45:00 comfort, 08:00:00 eco:1, 14:30:00 comfort, 22:30:00 eco:0,
# Profil 3: Mittwoch 05:45:00 comfort, 08:00:00 eco:1, 14:30:00 comfort, 22:30:00 eco:0,
# Profil 4: Donnerstag 05:45:00 comfort, 08:00:00 eco:1, 14:30:00 comfort, 22:30:00 eco:0,
# Profil 5: Freitag 05:45:00 comfort, 08:00:00 eco:1, 14:30:00 comfort, 22:30:00 eco:0,
# Profil 6: Samstag 07:45:00 comfort, 23:00:00 eco:0,
# Profil 7: Wochenende 07:45:00 comfort, 23:00:00 eco:0,
# Profil 8: Werktags 05:45:00 comfort, 08:00:00 eco:1, 14:30:00 comfort, 22:30:00 eco:0,
# STATE nächste Schaltung: 2023-05-01 14:30:00 eco ==> comfort
# STILLDONETIME 0
# TYPE WeekdayTimer
# eventCount 16
# setModifier desired-temp
# READINGS:
# 2023-05-01 08:02:00 currValue eco:1
# 2023-04-27 11:26:44 disabled 0
# 2023-05-01 08:02:00 nextUpdate 2023-05-01 14:30:00
# 2023-05-01 08:02:00 nextValue comfort
# 2023-05-01 08:02:00 state eco:1
# SWITCHINGTIMES:
# 8|05:45|comfort
# 8|08:00|eco:1
# 8|14:30|comfort
# 8|22:30|eco:0
# 7|07:45|comfort
# 7|23:00|eco:0
# TIMER:
# E2_ez_THKV_Heizkoerper_Fenster_hC_01_3:
# HASH E2_ez_THKV_Heizkoerper_Fenster_hC_01
# MODIFIER 3
# NAME E2_ez_THKV_Heizkoerper_Fenster_hC_01_3
# E2_ez_THKV_Heizkoerper_Fenster_hC_01_4:
# HASH E2_ez_THKV_Heizkoerper_Fenster_hC_01
# MODIFIER 4
# NAME E2_ez_THKV_Heizkoerper_Fenster_hC_01_4
# E2_ez_THKV_Heizkoerper_Fenster_hC_01_midnight:
# HASH E2_ez_THKV_Heizkoerper_Fenster_hC_01
# MODIFIER midnight
# NAME E2_ez_THKV_Heizkoerper_Fenster_hC_01_midnight
# SETTIMERATMIDNIGHT 1
# helper:
# daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
# daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
# SWITCHINGTIME:
# 0:
# 07:45:00 comfort
# 23:00:00 eco:0
# 1:
# 05:45:00 comfort
# 08:00:00 eco:1
# 14:30:00 comfort
# 22:30:00 eco:0
# 2:
# 05:45:00 comfort
# 08:00:00 eco:1
# 14:30:00 comfort
# 22:30:00 eco:0
# 3:
# 05:45:00 comfort
# 08:00:00 eco:1
# 14:30:00 comfort
# 22:30:00 eco:0
# 4:
# 05:45:00 comfort
# 08:00:00 eco:1
# 14:30:00 comfort
# 22:30:00 eco:0
# 5:
# 05:45:00 comfort
# 08:00:00 eco:1
# 14:30:00 comfort
# 22:30:00 eco:0
# 6:
# 07:45:00 comfort
# 23:00:00 eco:0
# 7:
# 07:45:00 comfort
# 23:00:00 eco:0
# 8:
# 05:45:00 comfort
# 08:00:00 eco:1
# 14:30:00 comfort
# 22:30:00 eco:0
# WEDAYS:
# 5 1
# 6 1
# profil:
# 1:
# EPOCH 1682912700
# PARA comfort
# TIME 05:45
# WE_Override
# DAYS:
# 8
# 2:
# EPOCH 1682920800
# PARA eco:1
# TIME 08:00
# WE_Override
# DAYS:
# 8
# 3:
# EPOCH 1682944200
# PARA comfort
# TIME 14:30
# WE_Override
# DAYS:
# 8
# 4:
# EPOCH 1682973000
# PARA eco:0
# TIME 22:30
# WE_Override
# DAYS:
# 8
# 5:
# EPOCH 1682919900
# PARA comfort
# TIME 07:45
# WE_Override
# DAYS:
# 7
# 6:
# EPOCH 1682974800
# PARA eco:0
# TIME 23:00
# WE_Override
# DAYS:
# 7
# profile_IDX:
# 0:
# 07:45:00 5
# 23:00:00 6
# 1:
# 05:45:00 1
# 08:00:00 2
# 14:30:00 3
# 22:30:00 4
# 2:
# 05:45:00 1
# 08:00:00 2
# 14:30:00 3
# 22:30:00 4
# 3:
# 05:45:00 1
# 08:00:00 2
# 14:30:00 3
# 22:30:00 4
# 4:
# 05:45:00 1
# 08:00:00 2
# 14:30:00 3
# 22:30:00 4
# 5:
# 05:45:00 1
# 08:00:00 2
# 14:30:00 3
# 22:30:00 4
# 6:
# 07:45:00 5
# 23:00:00 6
# 7:
# 07:45:00 5
# 23:00:00 6
# 8:
# 05:45:00 1
# 08:00:00 2
# 14:30:00 3
# 22:30:00 4
#
setstate E2_ez_THKV_Heizkoerper_Fenster_hC_01 nächste Schaltung: 2023-05-01 14:30:00 eco ==> comfort
setstate E2_ez_THKV_Heizkoerper_Fenster_hC_01 2023-05-01 08:02:00 currValue eco:1
setstate E2_ez_THKV_Heizkoerper_Fenster_hC_01 2023-04-27 11:26:44 disabled 0
setstate E2_ez_THKV_Heizkoerper_Fenster_hC_01 2023-05-01 08:02:00 nextUpdate 2023-05-01 14:30:00
setstate E2_ez_THKV_Heizkoerper_Fenster_hC_01 2023-05-01 08:02:00 nextValue comfort
setstate E2_ez_THKV_Heizkoerper_Fenster_hC_01 2023-05-01 08:02:00 state eco:1
VG
Torsten
Hi,
und in der "holiday-Datei" ist der 1. Mai als Feiertag eingetragen?
Viele Grüße
Jürgen
Ich mache das über einen Feiertagskalender, der mit dem Holiday device kombiniert ist. Feiertag wurde auch angezeigt und es hat sehr lange gut funktioniert.
Heute dann ganz exotisch, kein Feiertag mehr, aber Heizungen werden wie am Feiertag geschaltet :o
VG
Torsten
Hallo Beta-User,
am langen WE habe ich folgende Beobachtungen gemacht:
Der Status wurde geändert (auf Urlaub):
01.05. 00:10 SU.MU eingestellt
Die allnächtliche Reanimierung der Timer:
01.05. 03:50 set wdt.* enable
Die resultierenden Timer:
01.05. 16:39 fhemdebug timerList
2023-05-01 20:47:25.97000 Twilight_fireEvent MyTwilight_ss
2023-05-01 20:47:26.00000 RT_Exec rnd.li.eg.Wohnzimmer.Ecke.links
2023-05-01 20:47:26.00000 RT_Exec rnd.li.eg.Wohnzimmer.Ecke.rechts
2023-05-01 20:47:26.00000 RT_Exec rnd.li.eg.Badezimmer
2023-05-01 20:47:26.00000 RT_Exec rnd.li.eg.Flur
2023-05-01 20:47:26.00000 RT_Exec rnd.li.eg.Garderobe
2023-05-01 20:47:26.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Micha
2023-05-01 20:47:26.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2023-05-01 21:01:46.00000 DOIF_TimerTrigger
2023-05-01 21:01:46.00000 WDT_Update wdt.duo.eg.Arbeitszimmer.Arbeit_1
2023-05-01 21:01:46.00000 WDT_Update wdt.duo.eg.Arbeitszimmer.Urlaub.zuhause_1
2023-05-01 21:16:46.00000 DOIF_TimerTrigger
2023-05-01 21:16:46.00000 DOIF_TimerTrigger
2023-05-01 21:16:46.00000 WDT_Update wdt.duo.st.Arbeitszimmer.Arbeit_1
2023-05-01 21:16:46.00000 WDT_Update wdt.duo.st.Arbeitszimmer.Urlaub.zuhause_1
2023-05-01 21:16:46.00000 WDT_Update wdt.duo.st.Schlafzimmer.Arbeit_1
2023-05-01 21:16:46.00000 WDT_Update wdt.duo.st.Schlafzimmer.Urlaub.zuhause_1
2023-05-01 21:29:54.00000 DOIF_TimerTrigger
2023-05-01 21:29:54.00000 DOIF_TimerTrigger
2023-05-01 21:29:54.00000 DOIF_TimerTrigger
2023-05-01 21:30:30.00000 WDT_Update hc.eg.Kueche.SH.MB_6
2023-05-01 21:30:30.00000 WDT_Update hc.eg.Kueche.SH.MH_6
2023-05-01 21:31:00.00000 DOIF_TimerTrigger
2023-05-01 21:31:45.98000 Twilight_fireEvent MyTwilight_ss_civil
2023-05-01 21:31:46.00000 DOIF_TimerTrigger
2023-05-01 21:31:46.00000 DOIF_TimerTrigger
2023-05-01 21:31:46.00000 DOIF_TimerTrigger
2023-05-01 21:31:46.00000 DOIF_TimerTrigger
2023-05-01 21:31:46.00000 DOIF_TimerTrigger
2023-05-01 21:31:46.00000 WDT_Update wdt.duo.eg.Wohnzimmer.Seite.Arbeit_1
2023-05-01 21:31:46.00000 WDT_Update wdt.duo.eg.Wohnzimmer.Seite.Urlaub.zuhause_1
2023-05-01 21:50:00.00000 DOIF_TimerTrigger
um 21:01:00 hätte der Timer hc.st.Schlafzimmer.SU.MU schalten sollen, wird aber gar nicht gelistet.
Um den Fehler abzufangen, lasse ich jeden Abend um 21:31 erneut ein
set wdt.* enableausführen.
Dies funktioniert:
2023-05-01_20:49:37 hm.hr.st.Schlafzimmer desired-temp: 19.0
2023-05-01_20:59:27 hm.hr.st.Schlafzimmer measured-temp: 19.2
2023-05-01_21:01:34 hm.hr.st.Schlafzimmer actuator: 27
2023-05-01_21:01:34 hm.hr.st.Schlafzimmer desired-temp: 19.0
2023-05-01_21:09:42 hm.hr.st.Schlafzimmer measured-temp: 19.2
2023-05-01_21:11:56 hm.hr.st.Schlafzimmer actuator: 27
2023-05-01_21:11:56 hm.hr.st.Schlafzimmer desired-temp: 19.0
2023-05-01_21:20:22 hm.hr.st.Schlafzimmer measured-temp: 19.2
2023-05-01_21:24:48 hm.hr.st.Schlafzimmer actuator: 27
2023-05-01_21:24:48 hm.hr.st.Schlafzimmer desired-temp: 19.0
2023-05-01_21:30:24 hm.hr.st.Schlafzimmer measured-temp: 19.2
2023-05-01_21:31:10 hm.hr.st.Schlafzimmer desired-temp: 17.0
2023-05-01_21:32:50 hm.hr.st.Schlafzimmer actuator: 0
2023-05-01_21:35:02 hm.hr.st.Schlafzimmer measured-temp: 19.3
2023-05-01_21:38:03 hm.hr.st.Schlafzimmer measured-temp: 19.2
2023-05-01_21:43:23 hm.hr.st.Schlafzimmer actuator: 0
2023-05-01_21:43:23 hm.hr.st.Schlafzimmer desired-temp: 17.0
2023-05-01_21:50:38 hm.hr.st.Schlafzimmer measured-temp: 19.2
Der Status wurde erneut geändert, diesmal vor 00:00 Uhr:
01.05. 23:23 SH.MB eingestellt
Die allnächtliche Reanimierung der Timer:
02.05. 03:50 set wdt.* enable
Die resultierenden Timer:
2023-05-02 20:49:03.00000 RT_Exec rnd.li.eg.Wohnzimmer.Ecke.links
2023-05-02 20:49:03.00000 RT_Exec rnd.li.eg.Wohnzimmer.Ecke.rechts
2023-05-02 20:49:03.00000 RT_Exec rnd.li.eg.Badezimmer
2023-05-02 20:49:03.00000 RT_Exec rnd.li.eg.Flur
2023-05-02 20:49:03.00000 RT_Exec rnd.li.eg.Garderobe
2023-05-02 20:49:03.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Micha
2023-05-02 20:49:03.00000 RT_Exec rnd.li.st.Schlafzimmer.Bett.Silke
2023-05-02 21:01:00.00000 WDT_Update hc.st.Schlafzimmer.SH.MB_4
2023-05-02 21:03:37.00000 DOIF_TimerTrigger
2023-05-02 21:03:37.00000 WDT_Update wdt.duo.eg.Arbeitszimmer.Arbeit_1
2023-05-02 21:03:37.00000 WDT_Update wdt.duo.eg.Arbeitszimmer.Urlaub.zuhause_1
2023-05-02 21:11:35.62674 HttpUtils_TimeoutErr
Daraus folgere ich, dass ein
set wdt.* enable nicht ausreicht, um die Timer neu berechnen zu lassen, wenn Bedingungen nach 0:00 Uhr geändert wurden, unabhängig vom Problem der WE-Schaltung.
Puh, schaut so aus, als müßte ich mich da nochmal grundlegend drüber beugen.
Hoffe, ich komme die Tage mal dazu, neige aber im Moment dazu, erst mal wieder die Version mit dem "relativ kleinen" Bug (also rev. 27118 ) einzuchecken und ggf. dann erst mal wieder Testversionen anzubiegen. Meinungen dazu?
Kann ich mit leben. Helfe gerne beim Testen.
Hatte bisher keine Probleme. Kann aber meine Testszenarien gerne erweitern.
Viele Grüße
Jürgen
Hallo zusammen,
bin leider noch nicht dazu gekommen, das ausgiebig auszutesten, aber weil es in https://forum.fhem.de/index.php?topic=133492.0 noch die (m.E. sehr sinnvolle) Anregung gab, im "state" anzuzeigen, dass der WDT im disable-Fall nicht aktiv ist, habe ich eben noch ein update eingecheckt, das sehr vielleicht auch das $we-Problem löst.
Wer auf Nummer sicher gehen will, kann den WDT ja vom update ausnehmen bzw. die (fast) funktionierende Version (also rev. 27118) aus dem svn holen...
(Möglichst positive...) Rückmeldungen wie immer gerne, ich bin jetzt aber ein paar Tage unterwegs, also bitte nicht wundern, wenn es wieder etwas dauert, bis ich mich melde.
Hi Beta-User,
die aktiven WT haben im Reading "state" weiterhin den Wert des Readings "currValue". Ich hätte erwartet, dass hier nur noch active und inactive angezeigt wird.
Für mich ist es aber auch so ok. Ansonsten keine Auffälligkeiten.
Viele Grüße
Jürgen
Hi,
mir ist jetzt gerade aufgefallen, dass WeekdayTimer bei den Optionen "enable/disable" immer zu einer Änderung der Konfig führt und das rote Fragezeichen bei "save" damit provoziert wird.
Ich habe gerade erfahren, dass ein set Befehl diese Änderung eigentlich nicht hervorrufen soll.
Ist dann ein Bug im Modul oder?
Hintergrund, ich steuere über einen Dummy ein Notify, welches dann 4 WeekdayTimer aktiviert oder deaktiviert.
Jedesmal habe ich, wenn ich den Dummy klicke, dass rote Fragezeichen für unsaved changes.
Ich habe jetzt auch mal den kurzen Weg genommen und direkt set XXXXX enable/disable gemacht und siehe da, auch das rote Fragezeichen...
Last unsaved structural changes:
attr GB_Kreis_2_Timer disable 1
Viell. kann da jemand nochmal in Code schauen?!
VG+Danke
René
Ob Bug oder nicht,
die commandref sagt dazu:
https://fhem.de/commandref_DE.html#attr (https://fhem.de/commandref_DE.html#attr)
ZitatMit der silent Option wird der Befehl nicht in die "save -?" Liste eingetragen.
also
attr GB_Kreis_2_Timer -silent disable 1und der Drops ist gelutscht.
Zitat von: fireball am 25 Juli 2023, 13:02:04Ist dann ein Bug im Modul oder?
"Bug" ist ein großes Wort....
Das Verhalten ist historisch so gewachsen, und im Moment finde ich das auch nicht besonders störend, dass das a) (im Ergebnis) via Attribut gelöst ist und b) dann der deutliche Hinweis erfolgt, dass die Änderung auch abgespeichert wird.
Falls es gute Gründe und ausreichend Interessenten gibt, können wir das gerne nochmal diskutieren, ob es tatsächlich als "bug" anzusehen ist... (dann sind auch patches willkommen!).
Zitat von: Beta-User am 25 Juli 2023, 16:15:04Zitat von: fireball am 25 Juli 2023, 13:02:04Ist dann ein Bug im Modul oder?
"Bug" ist ein großes Wort....
Das war auch mehr ironisch gemeint....
Moinsen,
ich kann mit dem Workaround leben, ich bin nur endlich froh, dass ich herausgefunden habe, woher ich immer die Meldung bekommen habe, dass sich was geändert hat und ich es speichern soll.
Das mit dem "Bug" war ne Frage und keine Aufforderung.
ich kann mit dem Workaround sicherlich leben, ich geh aber mal davon aus, dass die silent Option zwar das "Fragezeichen" verhindert, aber das Problem, bei einem Restart trotzdem der letzte Stand nicht gespeichert ist?!
BTW: habs grad getestet... in meinem Notify ist diese Zeile jetzt eingetragen:
Gartenbewaesserung attr -silent (GB_Kreis_._Timer) $EVENT
Wenn Gartenbewaesserung enable/disable gesetzt wird, wird dieses EVENT im Notify genutzt und jetzt is das Attribut disable leer, weder 0 noch 1 drin.
Das funzt also doch nicht...
VG
René
Zitat von: fireball am 26 Juli 2023, 16:10:58Gartenbewaesserung attr -silent (GB_Kreis_._Timer) $EVENT
Wenn Gartenbewaesserung enable/disable gesetzt wird, wird dieses EVENT im Notify genutzt und jetzt is das Attribut disable leer, weder 0 noch 1 drin.
Das funzt also doch nicht...
Wenn in $EVENT enable/diable steht, dann geht das so nicht.
Es muss immer ".... disable 0" oder ".... disable 1" im notify für den attr-Befehl stehen.
Sowas hab ich mir schon gedacht,als ich in die Doku geschaut habe. Dann muss ich mal schauen, ob mein Dummy-Schalter die 0 oder 1 als EVENT mit übertragen kann.
Danke für den Hinweis.
VG René
Zitat von: fireball am 26 Juli 2023, 16:51:38ob mein Dummy-Schalter die 0 oder 1 als EVENT mit übertragen kann.
Das kannst Du doch im notify erledigen, z.B.:
Heizperiode:on|Heizperiode:off {
....
my $Wert2 =0;
....
if ($EVENT eq "off") {
.....
$Wert2 = 1;
.....
}
fhem("attr -silent wdT_.* disable $Wert2");
....
}
Ja klar 💪 danke für die Erleuchtung. Sowas hab ich auch schon an anderer Stelle... Manchmal denke ich einfach zu kompliziert.
VG René
Hallo,
im Code vom weekdaytimer ist ja bereits etwas vorgesehen um die "Delayed_Devices" anders zu schreiben. Da ich jetzt Zigbee Fenstersensoren nutze werden die leider ohne Codeanpassung nicht akzeptiert. Ist das Thema noch aktuell? Also in Zukunft quasi "Fenster_Bad:state:open"?
Besten Dank!
Zitat von: Dave2526 am 02 Oktober 2024, 15:23:19Zigbee Fenstersensoren
Falls das HUEDevice-TYPE-Sensoren sind, müßte es mit der eben eingecheckten Version (=aus svn holen oder morgen nach 8Uhr ein update fahren) funktionieren.
Zitat von: Beta-User am 03 Oktober 2024, 08:27:29Falls das HUEDevice-TYPE-Sensoren sind, müßte es mit der eben eingecheckten Version (=aus svn holen oder morgen nach 8Uhr ein update fahren) funktionieren.
Danke, aber Nein, sind (leider) MQTT2_Devices, das läuft bei mir über Zigbee2MQTT.
Ich fände es trotzdem praktischer, dann könnte man z.B. die Weihnachtsbeleuchtung darüber steuern und als "Freigabe" ein Reading aus dem Astro Device nehmen.
Meine Kenntnisse in Perl halten sich leider sehr in Grenzen, sonst würde ich mir das mal anschauen...
Zitat von: Dave2526 am 15 Oktober 2024, 13:04:57Danke, aber Nein, sind (leider) MQTT2_Devices, das läuft bei mir über Zigbee2MQTT.
Wäre einfacher gewesen, wenn das gleich klar gewesen wäre, aber HUEDevice aufzunehmen, war andererseits auch kein Fehler...
Habe jetzt versucht, was reinzubasteln, das solche Fälle generalisiert mit abfängt, indem erst geschaut wird, ob es ein Reading "contact" (ersatzweise: "state") gibt und das auf "open", "closed" usw. checkt.
Ist ungetestet, feedback willkommen, super wäre, wenn du einen kurzen commandref-Eintrag dazu liefern könntest, falls es funktioniert wie gewünscht.
Edith: It compiles, let's flash it...
Kommt per Update, bitte melden, ob OK.
Besten Dank, leider hab ich momentan keine Zeit zum Probieren, da wir gerade ein paar andere Probleme haben... Melde mich nochmal wenn ich zum Testen komme.