Autor Thema: Der WeekdayTimer-Thread ab 2020  (Gelesen 5766 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #15 am: 19 Mai 2021, 14:55:41 »
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-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #16 am: 20 Mai 2021, 07:25:24 »
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-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #17 am: 21 Mai 2021, 08:14:25 »
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #18 am: 21 Mai 2021, 08:33:10 »
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-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #19 am: 21 Mai 2021, 14:42:18 »
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-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline helmut

  • Developer
  • Full Member
  • ****
  • Beiträge: 306
  • You can have easy, cheap or secure. Pick two.
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #20 am: 21 Mai 2021, 20:28:28 »
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)
Informativ Informativ x 1 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #21 am: 22 Mai 2021, 06:19:57 »

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-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}
Zustimmung Zustimmung x 1 Liste anzeigen

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #22 am: 23 Mai 2021, 08:59:48 »
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #23 am: 23 Mai 2021, 09:14:35 »
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.)
« Letzte Änderung: 23 Mai 2021, 09:45:29 von Beta-User »
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #24 am: 23 Mai 2021, 09:59:24 »
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #25 am: 23 Mai 2021, 10:09:50 »
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-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #26 am: 23 Mai 2021, 10:22:49 »
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15568
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #27 am: 24 Mai 2021, 08:27:36 »
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-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Cybers

  • Full Member
  • ***
  • Beiträge: 440
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #28 am: 24 Mai 2021, 16:44:42 »
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")}|100Anscheinend kommt der Weekdaytimer nicht mit einer leeren Stelle in der Funktion klar.
Gruß, Sascha
FHEM 6.0 auf Raspberry PI 3 / 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

Offline netwalk

  • Full Member
  • ***
  • Beiträge: 136
Antw:Der WeekdayTimer-Thread ab 2020
« Antwort #29 am: 25 Mai 2021, 08:07:50 »
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

 

decade-submarginal