Hallo,
ich nutze verschiedene Weekdaytimer je Thermostat um verschiedene Szenarien gerecht zu werden. So gibt es "normal" für Arbeitstage, "KeinArbeitstag" für Ferien, Urlaub "Off" für den Sommerbetrieb und "Minimal" für die Übergangszeit. Über ReadingsVal wird das so gesteuert, dass jeweils nur eines dieser Weekdaytimer aktiv ist. Nun ist es aber so, dass bei machen (nicht bei allen!!) Weekdaytimern statt der aktuellen Temperatur dort nur "active" im state steht. Die Temperatur wird dann auch nicht gesetzt. Hier mal am Beispiel meines Schlafzimmerthermostats:
Internals:
COMMAND
CONDITION ((ReadingsVal("Familie","state","zuhause") ne "verreist")&&(ReadingsVal("KAT","state","0")==1)&&(ReadingsVal("HC_Schlafz_Profile","state","Fehler") eq "Auto"))
DEF OG_Schlafz_T 78|08:00|19 78|19:30|19.5 ((ReadingsVal("Familie","state","zuhause") ne "verreist")&&(ReadingsVal("KAT","state","0")==1)&&(ReadingsVal("HC_Schlafz_Profile","state","Fehler") eq "Auto"))
DEVICE OG_Schlafz_T
FUUID 5d924a77-f33f-e65d-60c2-13698c196239e95a
FVERSION 98_WeekdayTimer.pm:0.207690/2019-12-17
GlobalDaylistSpec
LANGUAGE de
NAME HC_Schlafz_KeinArbeitstag
NR 273
Profil 0: Sonntag 08:00:00 19, 19:30:00 19.5
Profil 1: Montag 08:00:00 19, 19:30:00 19.5
Profil 2: Dienstag 08:00:00 19, 19:30:00 19.5
Profil 3: Mittwoch 08:00:00 19, 19:30:00 19.5
Profil 4: Donnerstag 08:00:00 19, 19:30:00 19.5
Profil 5: Freitag 08:00:00 19, 19:30:00 19.5
Profil 6: Samstag 08:00:00 19, 19:30:00 19.5
Profil 7: Wochenende 08:00:00 19, 19:30:00 19.5
Profil 8: Werktags 08:00:00 19, 19:30:00 19.5
STATE active
STILLDONETIME 0
TYPE WeekdayTimer
READINGS:
2019-12-24 08:10:28 currValue 19.5
2019-12-24 08:10:28 nextUpdate 2019-12-25 08:00:00
2019-12-24 08:10:28 nextValue 19
2019-12-24 08:10:28 state active
SWITCHINGTIMES:
78|08:00|19
78|19:30|19.5
TIMER:
HC_Schlafz_KeinArbeitstag_2:
HASH HC_Schlafz_KeinArbeitstag
MODIFIER 2
NAME HC_Schlafz_KeinArbeitstag_2
forceSwitch 1
HC_Schlafz_KeinArbeitstag_SetTimerOfDay:
HASH HC_Schlafz_KeinArbeitstag
MODIFIER SetTimerOfDay
NAME HC_Schlafz_KeinArbeitstag_SetTimerOfDay
SETTIMERATMIDNIGHT 1
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:
08:00:00 19
19:30:00 19.5
1:
08:00:00 19
19:30:00 19.5
2:
08:00:00 19
19:30:00 19.5
3:
08:00:00 19
19:30:00 19.5
4:
08:00:00 19
19:30:00 19.5
5:
08:00:00 19
19:30:00 19.5
6:
08:00:00 19
19:30:00 19.5
7:
08:00:00 19
19:30:00 19.5
8:
08:00:00 19
19:30:00 19.5
WEDAYS:
1 1
2 2. Weihnachtstag
4 1
5 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 1577170800
PARA 19
TIME 08:00
WE_Override 0
TAGE:
7
8
2:
EPOCH 1577212200
PARA 19.5
TIME 19:30
WE_Override 0
TAGE:
7
8
profile_IDX:
0:
08:00:00 1
19:30:00 2
1:
08:00:00 1
19:30:00 2
2:
08:00:00 1
19:30:00 2
3:
08:00:00 1
19:30:00 2
4:
08:00:00 1
19:30:00 2
5:
08:00:00 1
19:30:00 2
6:
08:00:00 1
19:30:00 2
7:
08:00:00 1
19:30:00 2
8:
08:00:00 1
19:30:00 2
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:
DbLogExclude .*
WDT_Group WDT_Schlafz
WDT_delayedExecutionDevices OG_Schlafz_Fensterkontakt
commandTemplate set $NAME desiredTemperature $EVENT
group Profile
room Roomdetails->Schlafzimmer
switchInThePast 1
Hier fallen mir 2 Dinge auf, die meiner Meinung nach falsch sind:
STATE = active
nextUpdate 2019-12-25 08:00:00
der nächste Schaltpunkt ist doch 2019-12-24 19:30:00...
Hmm, also:
Ich nehme an, dass bei der Auswertung des ersten Schaltzeitpunkts (08:00 Uhr) mindestens einer der in CONDITION berücksichtigten Parameter nicht paßte. Der von dir gewählte WDT scheint am 24.12. daher "active" stehen geblieben zu sein, weil er nie eine Temperatur zu setzen hatte.
Damit war auch der folgende timer an dem Tag nicht als aktiver Timer zu erkennen, weswegen der WDT meldete, dass er davon ausgeht, dass an diesem Tag gar nicht mehr geschaltet werden muß (daher der nächste aktive Timer am Folgetag, für den noch keine Auswertung erfolgt war).
Am Internal "TIMER:HC_Schlafz_KeinArbeitstag_2" ist aber (indirekt) zu erkennen, dass er das "profil:2" (19:30 Uhr) noch ausführen wird, um zu checken, ob das zum Schaltzeitpunkt wirklich noch der Fall ist. Sollten also zu diesem Zeitpunkt dann alle CONDITION-Parameter gegeben gewesen sein, müßte auch die Temperatur gesetzt worden sein.
Kannst du das irgendwie verifizieren?
Das mit dem verifizieren wird schwierig. Andere WDT, die prinzipiell die selben Bedingungen haben, haben in der Nacht geschaltet. Es wurde durch das einschalten der Umwälzpumpe der Heizung je Raum ein WeekdayTimer_SetAllParms je WDT aufgerufen. KAT wurde am 23.12. (Ferienbeginn) auf 1 gesetzt, HC_Schlafz_Profile habe ich nach der Übergangszeit also irgendwann im Herbst auf "Auto" gesetzt. Und Familie ist natürlich abhängig von Presence der Handys.
Der Sollablauf wäre also gewesen, dass ca. um 2 oder 3 Uhr, wenn die Heizung per Außenfühler entschieden hat, dass die Nachtabsenkung vorbei ist werden alle Thermostate von 17°C auf ihre eingestellte Nachttemperatur eingestellt. Hintergrund: wenn die Umwälzpumpe ausgeschaltet ist kann der Thermostat regeln was er will, es wird nicht funktionieren. Und da in diesem Fall die Thermstate weit übersteuern, dann hab ich das eingebaut. Somit ist das übersteuern ein wenig besser. Die MAX Thermostate sind hier wesentlich schlechter als z.b einen Homematic Thermostat den ich habe.
Für die Fehlersuche wäre es natürlich besser, wenn es ein Fehler wäre, der ständig auftritt. Dem ist aber nicht so, es ist ab und zu schon gewesen, aber zu 99% funktioniert es.
Dann wird das schwierig festzustellen, ob überhaupt ein Fehler vorlag; sollte das nochmal auftreten, bitte die CONDITION auch auswerten - wobei auch das nichts (mehr) bringt, wenn zwischenzeitlich eine Änderung eingetreten sein sollte. CONDITION wird nämlich nur zur Schaltzeit ausgewertet, anders als eine delayedExecutionCond, die immer wieder überprüft wird.
Eventuell kannst du das ganze setup etwas vereinfachen, indem du die neue Option nutzt, einfach pro Thermostat nur einen WDT anzulegen und bei dem das weekprofile auszutauschen, je nachdem, welches Topic/Profil grade - abhängig von den anderen Rahmenbedingungen - aktiv sein soll.
Hallo beta-User,
von dieser neuen Methode habe ich gelesen, aber so wirklich überzeugt bin ich davon nicht.
1. für die Übertragung des Wochenprogrammes an 10 Thermostate werden sicherlich sehr, sehr viele Credits benötigt und darum dauert das ewig
2. Durch die Verwendung des Auto-modes nimmt man sich die Flexibilität der Anwesenheitssteuerung anhand von Presence.
Oder wie macht man das dann sinnvoll?
Moin. Habe ich vielleicht nicht gut erklärt: Der (dann nur noch eine) WeekdayTimer ist weiter das Element, das zur "richtigen Zeit" einfach nur die neue Solltemperatur übermittelt, es ändert sich also weder am Credit-Verbrauch was, noch nutzt man den "auto"-Mode der Thermostate.
Man kann zwar auch weekprofile nutzen, um Wochenprogramme auf diverse Thermostat-Typen zu schieben, bei der "neuen" Methode wird aber eben ein WeekdayTimer genutzt, der dann im laufenden Betrieb angewiesen werden kann, ein anderes Profil zu nutzen (ohne die DEF zu ändern).
Du legst also in weekprofile z.B. ein Profil für HC_Schlafz an, aktivierst die Nutzung von Topics und legst dann Profile für diverse Topics an wie KeinArbeitstag, Arbeitstag, Urlaub, Abwesend.
Dann läßt du den einen WDT, der für HC_Schlafz zuständig sein soll auf dieses weekprofile-Device hören und setzt z.B. das Profil KeinArbeitstag:HC_Schlafz. Schon sollte der WDT dieses Temperaturprofil fahren.
Hast du mehrere, sollte es möglich sein, über "set ... restore_topic KeinArbeitstag" alle WDT, die entsprechend konfiguriert sind mit dem für sie passenden Profil zu versorgen - wie gesagt, ohne dass dabei mehr wie die jeweils grade aktuelle Solltemperatur tatsächlich an die Thermostate geschickt wird...
Achso, das ist natürlich etwas ganz anderes. Dann hatte ich das in der Tat falsch verstanden und sollte mich mal damit beschäftigen. Dann wird das wohl meine nächste große Änderung.