[Gelöst] Unerwartetes Verhalten vom WeekDayTimer

Begonnen von JamBay, 19 Dezember 2019, 16:57:02

Vorheriges Thema - Nächstes Thema

JamBay

Hallo,
ich habe folgenden WDT definiert:

Internals:
   CFGFN     
   COMMAND   
   CONDITION 
   DEF        TT_KUF de 78|00:00|16 78|07:45|20 78|08:45|18 78|17:45|20 78|18:30|16 78|23:59|16
   DEVICE     TT_KUF
   FUUID      5dfa70a7-f33f-19fe-4676-858815ef1d26c72c
   GlobalDaylistSpec
   LANGUAGE   de
   NAME       wt_TT_KUF_H
   NR         716
   Profil 0: Sonntag 00:00:00 16, 07:45:00 20, 08:45:00 18, 17:45:00 20, 18:30:00 16, 23:59:00 16
   Profil 1: Montag 00:00:00 16, 07:45:00 20, 08:45:00 18, 17:45:00 20, 18:30:00 16, 23:59:00 16
   Profil 2: Dienstag 00:00:00 16, 07:45:00 20, 08:45:00 18, 17:45:00 20, 18:30:00 16, 23:59:00 16
   Profil 3: Mittwoch 00:00:00 16, 07:45:00 20, 08:45:00 18, 17:45:00 20, 18:30:00 16, 23:59:00 16
   Profil 4: Donnerstag 00:00:00 16, 07:45:00 20, 08:45:00 18, 17:45:00 20, 18:30:00 16, 23:59:00 16
   Profil 5: Freitag 00:00:00 16, 07:45:00 20, 08:45:00 18, 17:45:00 20, 18:30:00 16, 23:59:00 16
   Profil 6: Samstag 00:00:00 16, 07:45:00 20, 08:45:00 18, 17:45:00 20, 18:30:00 16, 23:59:00 16
   Profil 7: Wochenende 00:00:00 16, 07:45:00 20, 08:45:00 18, 17:45:00 20, 18:30:00 16, 23:59:00 16
   Profil 8: Werktags 00:00:00 16, 07:45:00 20, 08:45:00 18, 17:45:00 20, 18:30:00 16, 23:59:00 16
   STATE      18
   STILLDONETIME 0
   TYPE       WeekdayTimer
   Helper:
     DBLOG:
       state:
         LogDB:
           TIME       1576741500.05274
           VALUE      18
   READINGS:
     2019-12-19 08:45:00   currValue       16
     2019-12-18 19:42:42   disabled        1
     2019-12-19 08:45:00   nextUpdate      2019-12-20 00:00:00
     2019-12-19 08:45:00   nextValue       16
     2019-12-19 08:45:00   state           18
   SWITCHINGTIMES:
     78|00:00|16
     78|07:45|20
     78|08:45|18
     78|17:45|20
     78|18:30|16
     78|23:59|16
   TIMER:
     wt_TT_KUF_H_1:
       HASH       wt_TT_KUF_H
       MODIFIER   1
       NAME       wt_TT_KUF_H_1
     wt_TT_KUF_H_2:
       HASH       wt_TT_KUF_H
       MODIFIER   2
       NAME       wt_TT_KUF_H_2
     wt_TT_KUF_H_3:
       HASH       wt_TT_KUF_H
       MODIFIER   3
       NAME       wt_TT_KUF_H_3
     wt_TT_KUF_H_4:
       HASH       wt_TT_KUF_H
       MODIFIER   4
       NAME       wt_TT_KUF_H_4
     wt_TT_KUF_H_5:
       HASH       wt_TT_KUF_H
       MODIFIER   5
       NAME       wt_TT_KUF_H_5
     wt_TT_KUF_H_6:
       HASH       wt_TT_KUF_H
       MODIFIER   6
       NAME       wt_TT_KUF_H_6
     wt_TT_KUF_H_SetTimerOfDay:
       HASH       wt_TT_KUF_H
       MODIFIER   SetTimerOfDay
       NAME       wt_TT_KUF_H_SetTimerOfDay
       SETTIMERATMIDNIGHT 1
     wt_TT_KUF_H_delayed:
       HASH       wt_TT_KUF_H
       MODIFIER   delayed
       NAME       wt_TT_KUF_H_delayed
   dayNumber:
     !$we       8
     $we        7
     di         2
     do         4
     fr         5
     mi         3
     mo         1
     sa         6
     so         0
   helper:
     daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
     daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
     SWITCHINGTIME:
       0:
         00:00:00   16
         07:45:00   20
         08:45:00   18
         17:45:00   20
         18:30:00   16
         23:59:00   16
       1:
         00:00:00   16
         07:45:00   20
         08:45:00   18
         17:45:00   20
         18:30:00   16
         23:59:00   16
       2:
         00:00:00   16
         07:45:00   20
         08:45:00   18
         17:45:00   20
         18:30:00   16
         23:59:00   16
       3:
         00:00:00   16
         07:45:00   20
         08:45:00   18
         17:45:00   20
         18:30:00   16
         23:59:00   16
       4:
         00:00:00   16
         07:45:00   20
         08:45:00   18
         17:45:00   20
         18:30:00   16
         23:59:00   16
       5:
         00:00:00   16
         07:45:00   20
         08:45:00   18
         17:45:00   20
         18:30:00   16
         23:59:00   16
       6:
         00:00:00   16
         07:45:00   20
         08:45:00   18
         17:45:00   20
         18:30:00   16
         23:59:00   16
       7:
         00:00:00   16
         07:45:00   20
         08:45:00   18
         17:45:00   20
         18:30:00   16
         23:59:00   16
       8:
         00:00:00   16
         07:45:00   20
         08:45:00   18
         17:45:00   20
         18:30:00   16
         23:59:00   16
     WEDAYS:
       2          1
       3          1
   longDays:
     de:
       Sonntag
       Montag
       Dienstag
       Mittwoch
       Donnerstag
       Freitag
       Samstag
       Wochenende
       Werktags
     en:
       Sunday
       Monday
       Tuesday
       Wednesday
       Thursday
       Friday
       Saturday
       weekend
       weekdays
     fr:
       Dimanche
       Lundi
       Mardi
       Mercredi
       Jeudi
       Vendredi
       Samedi
       weekend
       jours de la semaine
     nl:
       Zondag
       Maandag
       Dinsdag
       Woensdag
       Donderdag
       Vrijdag
       Zaterdag
       weekend
       werkdagen
   profil:
     1:
       EPOCH      1576710000
       PARA       16
       TIME       00:00
       WE_Override 0
       TAGE:
         7
         8
     2:
       EPOCH      1576737900
       PARA       20
       TIME       07:45
       WE_Override 0
       TAGE:
         7
         8
     3:
       EPOCH      1576741500
       PARA       18
       TIME       08:45
       WE_Override 0
       TAGE:
         7
         8
     4:
       EPOCH      1576773900
       PARA       20
       TIME       17:45
       WE_Override 0
       TAGE:
         7
         8
     5:
       EPOCH      1576776600
       PARA       16
       TIME       18:30
       WE_Override 0
       TAGE:
         7
         8
     6:
       EPOCH      1576796340
       PARA       16
       TIME       23:59
       WE_Override 0
       TAGE:
         7
         8
   profile_IDX:
     0:
       00:00:00   1
       07:45:00   2
       08:45:00   3
       17:45:00   4
       18:30:00   5
       23:59:00   6
     1:
       00:00:00   1
       07:45:00   2
       08:45:00   3
       17:45:00   4
       18:30:00   5
       23:59:00   6
     2:
       00:00:00   1
       07:45:00   2
       08:45:00   3
       17:45:00   4
       18:30:00   5
       23:59:00   6
     3:
       00:00:00   1
       07:45:00   2
       08:45:00   3
       17:45:00   4
       18:30:00   5
       23:59:00   6
     4:
       00:00:00   1
       07:45:00   2
       08:45:00   3
       17:45:00   4
       18:30:00   5
       23:59:00   6
     5:
       00:00:00   1
       07:45:00   2
       08:45:00   3
       17:45:00   4
       18:30:00   5
       23:59:00   6
     6:
       00:00:00   1
       07:45:00   2
       08:45:00   3
       17:45:00   4
       18:30:00   5
       23:59:00   6
     7:
       00:00:00   1
       07:45:00   2
       08:45:00   3
       17:45:00   4
       18:30:00   5
       23:59:00   6
     8:
       00:00:00   1
       07:45:00   2
       08:45:00   3
       17:45:00   4
       18:30:00   5
       23:59:00   6
   shortDays:
     de:
       so
       mo
       di
       mi
       do
       fr
       sa
       $we
       !$we
     en:
       su
       mo
       tu
       we
       th
       fr
       sa
       $we
       !$we
     fr:
       di
       lu
       ma
       me
       je
       ve
       sa
       $we
       !$we
     nl:
       zo
       ma
       di
       wo
       do
       vr
       za
       $we
       !$we
Attributes:
   alias      Wochenplan Thermostat Küche Ferien
   commandTemplate set $NAME desiredTemperature $EVENT
   devStateIcon .*0:FS20.on .*1:FS20.off
   disable    1
   group      Thermostat
   room       RZ->Heizung,Räume->Küche
   verbose    5


Dazu habe ich mir ein Logfile definiert mit folgendem Text für heute (bislang).

2019-12-19_00:00:17 wt_TT_KUF_H nextUpdate: 2019-12-20 00:00:00
2019-12-19_00:00:17 wt_TT_KUF_H nextValue: 16
2019-12-19_00:00:17 wt_TT_KUF_H currValue: 16
2019-12-19_00:00:17 wt_TT_KUF_H 16
2019-12-19_07:45:00 wt_TT_KUF_H nextUpdate: 2019-12-20 00:00:00
2019-12-19_07:45:00 wt_TT_KUF_H nextValue: 16
2019-12-19_07:45:00 wt_TT_KUF_H currValue: 16
2019-12-19_07:45:00 wt_TT_KUF_H 20
2019-12-19_08:45:00 wt_TT_KUF_H nextUpdate: 2019-12-20 00:00:00
2019-12-19_08:45:00 wt_TT_KUF_H nextValue: 16
2019-12-19_08:45:00 wt_TT_KUF_H currValue: 16
2019-12-19_08:45:00 wt_TT_KUF_H 18


Jetzt habe ich folgende Verständnisprobleme:
Warum steht was im Log, wenn der WDT disabled sein sollte, oder ist er nicht?
'currValue' ist 16, sollte doch 18 sein?
'nextUpdate' sollte doch '2019-12-19 17:45:00 sein?
'nextValue' sollte doch 20 sein?
'state' sollte das Gegenteil von 'active' sein?

Das WDT Modul sollte aktuell sein, ich hatte gestern ein Update ausgeführt und neu gestartet.
Der WDT wurde gestern neu angelegt.
Vielleicht ist ja auch nur meine Erwartung s.o. falsch.

Beta-User

#1
Danke für den Hinweis, da scheint mit dem letzten update was unbeabsichtigt umgangen worden zu sein, muß ich mir nochmal ansehen.

Kannst du feststellen, ob der WDT die Befehle an das Zieldevice weitergegeben hat?

EDIT: Nach Durchsicht des Codes sollte keine effektive Schaltung durchgeführt worden sein, und die Änderung hat auch keine diesbezügliche Änderung der Verhaltensweise gebracht, soweit ich das überblicken kann.

Allerdings erscheint es mir auch nicht logisch, dass bei einem "disabled" Device dann im Hintergrund noch die Timer usw. erstellt werden. Ist zwar kein großes Ding, aber es wäre an sich ausreichend, das erst zu machen, wenn er enabled wird. Aber das wäre ein tieferer Eingriff in den Ausgangscode, und hätte den Nachteil, dass man dann auch nicht mehr sieht, was der wdt ggf. tun würde... (=> Eher bei Gelegenheit mal, wenn überhaupt).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

JamBay

Danke für die Rückmeldung.
Mit dem Timern und den Log Einträgen könnte ich zur Not leben, wäre zwar verwirrend, aber ok.
Was mich stört ist das falsche Reading 'currValue', damit hatte ich bislang die eigentlich gewünschte Temperatur nach Unterbrechung durch einen Fensterkontakt wiederherstellen wollen.
Ich bilde mir auch ein, dass das schon mal geklappt hat.
Aber ich denke mal, dadurch dass 'nextUpdate' die falsche Uhrzeit zeigt, wird immer die falsche Temperatur zu dem Zeitpunkt herangezogen.

Du hast recht, die Temperatur wird nicht ans device weiter gegeben, aber es sieht original so aus, als würde sie  ???

Das Problem besteht übrigens bei allen WDTs, ich hatte nur einen neu angelegt um einen Fehler von mir so gut es geht auszuschließen.

Beta-User

Weiß nicht recht, ob es "falsch" ist; kann es sein, dass das Fenster offen war und daher die nächste Schaltung zurückgehalten. "state" sah korrekt aus, oder? Ggf. mal warten, was passiert, wenn das Fenster länger wie eine Minute zu ist (oder was auch immer die Verzögerungsbedingung war).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Beta-User

#4
Vielleicht noch ein paar Anmerkungen (Achtung: bin auch erst dabei, mich in diese Heizungsthemen via WDT einzudenken...!):

- Um nach dem Fensterschließen aktuelle Daten an das Thermostat zu schicken, gibt es einen extra setter; ist evtl. besser, den zu nutzen, statt manuell was aus den Readings abzuleiten.
- die 78 könntest du auch weglassen, ebenso die Sprache (oder kommt das vom FTUI-Widget her?). Ohne Angabe von Wochentagen ist es immer die ganze Woche, und "de" leitet der WDT zwischenzeitlich von "global" her ab (war früher default)).
EDIT:
- Die Tagesanfangs- und Endzeiten kannst du weglassen, der WDT schaut nach dem letzten Wert, der kann auch vom Vortag sein. /EDIT
- Wenn es um Temperaturlisten geht, solltest du einen Blick auf die weekprofile-Option werfen, mMn. ist es einfacher, einen Timer pro Thermostat zu nutzen und den dann je nach Nutzungsanforderung dynamisch mit dem passenden Wochenprofil zu füttern...


Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

JamBay

Zitat von: Beta-User am 20 Dezember 2019, 11:22:16
- Um nach dem Fensterschließen aktuelle Daten an das Thermostat zu schicken, gibt es einen extra setter; ist evtl. besser, den zu nutzen, statt manuell was aus den Readings abzuleiten.
dieser ist mir so nicht aufgefallen, sonst hätte ich es ja nicht anders versucht, ich schaue mal, vielleicht braucht es das ja nicht s.u.
Zitat- Wenn es um Temperaturlisten geht, solltest du einen Blick auf die weekprofile-Option werfen, mMn. ist es einfacher, einen Timer pro Thermostat zu nutzen und den dann je nach Nutzungsanforderung dynamisch mit dem passenden Wochenprofil zu füttern...
Ich versuche das mal für ein Thermostat wie hier (https://forum.fhem.de/index.php/topic,105987.msg999062.html#msg999062) beschrieben, sieht vielversprechend aus, mir fehlt nur die 4.5 (https://forum.fhem.de/index.php/topic,105521.msg1003864.html#msg1003864) :)

JamBay

So, das hat mir extrem weiter geholfen.
Ich habe jetzt meine sechs Thermostate in fünf Räumen auf weekprofile umgestellt.
Die Fensterkontakte schalten über watchdogs einen dummy welcher dann mit anderen dummys (Heizperiode, abwesend, Ferien) in doifs verknüpft wird und die gewünschten Profile aktiviert.
Funktioniert saugut, auch beim Fenster öffnen wird anschließend so die aktuell gewünschte Temperatur wieder eingestellt.

Mir fällt nur ein Problem mit dem Profil 'default' auf, das mich aber nicht stört, dazu kommt noch eine Meldung in diesen Thread: https://forum.fhem.de/index.php/topic,105521.30.html