Der WeekdayTimer-Thread ab 2020

Begonnen von Beta-User, 10 September 2020, 16:42:29

Vorheriges Thema - Nächstes Thema

Beta-User

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

netwalk

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...
live long and prosper
netwalk
_______________________________________________
INTEL NUC7CJYH, Homematic mit 3x HMLGW, JEELINK mit 18x TX29-DTH-IT, DUOFERNSTICK, FB7590 mit FBDECT, NETATMO, Philips HUE, RFXtrx433, Ubiquiti G3 PRO/FLEX/DOME/MICRO

Beta-User

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

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).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

helmut

Zitat von: Beta-User am 21 Mai 2021, 14:42:18
Bitte um alsbaldige Meinungsäußerungen!
Ich habe keine Einwaende.

Gruss Helmut
Intelligenz ist die Fähigkeit, Arbeit zu vermeiden, aber dafür zu sorgen, daß die Arbeit gemacht wird.
(Linus Torvalds)

Beta-User

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

netwalk

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.
live long and prosper
netwalk
_______________________________________________
INTEL NUC7CJYH, Homematic mit 3x HMLGW, JEELINK mit 18x TX29-DTH-IT, DUOFERNSTICK, FB7590 mit FBDECT, NETATMO, Philips HUE, RFXtrx433, Ubiquiti G3 PRO/FLEX/DOME/MICRO

Beta-User

#23
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.)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

netwalk

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
live long and prosper
netwalk
_______________________________________________
INTEL NUC7CJYH, Homematic mit 3x HMLGW, JEELINK mit 18x TX29-DTH-IT, DUOFERNSTICK, FB7590 mit FBDECT, NETATMO, Philips HUE, RFXtrx433, Ubiquiti G3 PRO/FLEX/DOME/MICRO

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

netwalk

Ok, dann werde ich die Intialisierung vorerst mehrmals am Tag durchführen lassen.
Vielen Dank.
live long and prosper
netwalk
_______________________________________________
INTEL NUC7CJYH, Homematic mit 3x HMLGW, JEELINK mit 18x TX29-DTH-IT, DUOFERNSTICK, FB7590 mit FBDECT, NETATMO, Philips HUE, RFXtrx433, Ubiquiti G3 PRO/FLEX/DOME/MICRO

Beta-User

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Cybers

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
FHEM 6.2 auf Raspberry PI 4 / Smartvisu
Eltako Serie 14: FAM14, FGW14-USB, FSB14, FSR14-4x, FSR14-2x, FDG14, FTS14-EM in Kombination mit Jung F50 24V Tastern
1-Wire Temperatursensoren
aus alter Zeit:
Gott sei Dank nur noch 3 Homematic Jalousie- & Schaltaktoren! Wer sich mit Funk auskennt, legt Kabel

netwalk

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.



live long and prosper
netwalk
_______________________________________________
INTEL NUC7CJYH, Homematic mit 3x HMLGW, JEELINK mit 18x TX29-DTH-IT, DUOFERNSTICK, FB7590 mit FBDECT, NETATMO, Philips HUE, RFXtrx433, Ubiquiti G3 PRO/FLEX/DOME/MICRO