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