Hallo,
ich hab Weekdaytimer bei mir seit fast zwei Jahren im Einsatz um meine Z-Wave-Heizungsaktoren zu steuern.
Im Prinzip funktioniert das ziemlich gut. Immer mal wieder gehen wegen der Funkübertragung ein Schaltbefehl verloren, aber sonst funktioniert das wie am Schnürchen.
Jetzt seit ein paar Tagen habe ich bei zwei Timern das Problem, dass die Aktoren ganz normal in die Absenkungtemperatur geschaltet werden, morgens aber nicht wieder auf heizen.
Ich hatte zunächst ein Funk-Problem im verdacht, aber im FHEM-Log steht zu den Schaltzeiten kein Schaltbefehl im Log, so dass ich irgendwie davon ausgehen muss, dass der Weekdaytimer gar keinen Befehl setzt.
Die Besonderheit bei den beiden Aktoren ist, dass sie jeweils mit einem anderen Aktor im gleichen Raum stehen (Bad und Wohnzimmer), diese Konstellation hab ich sonst nirgends... ansonsten fällt mir nichts ein, was es sein könnte. Generell schalten kann Weekdaytimer ja, da absenken klappt. Weekdaytimer zeigt den Schalttermin in seinen Reading an, und der Status von Weekdaytimer steht auch auf dem Sollwert... nur ein Befehl wird nicht generiert...
Ich hab mal ein List von einem der Weekdaytimer gemacht:
Internals:
COMMAND
CONDITION (ReadingsVal("Heizung_HC1MQTT","ProgramChooseSwitch","") ne "Sommer")
DEF EG_WZ_1HEIZUNG 12345|05:03|22 60|06:05|22 12340|22:45|16 56|23:50|16 (ReadingsVal("Heizung_HC1MQTT","ProgramChooseSwitch","") ne "Sommer")
DEVICE EG_WZ_1HEIZUNG
FUUID 5d05ea2b-f33f-1c38-f6f4-4fe11d7761255cf4
GlobalDaylistSpec
LANGUAGE de
NAME HCKWZ1
NR 185
Profil 0: Sonntag 06:05:00 22, 22:45:00 16,
Profil 1: Montag 05:03:00 22, 22:45:00 16,
Profil 2: Dienstag 05:03:00 22, 22:45:00 16,
Profil 3: Mittwoch 05:03:00 22, 22:45:00 16,
Profil 4: Donnerstag 05:03:00 22, 22:45:00 16,
Profil 5: Freitag 05:03:00 22, 23:50:00 16,
Profil 6: Samstag 06:05:00 22, 23:50:00 16,
STATE 22
STILLDONETIME 0
TYPE WeekdayTimer
Helper:
DBLOG:
currValue:
logdb:
TIME 1609229573.15818
VALUE 22
nextUpdate:
logdb:
TIME 1609229573.15818
VALUE 2020-12-29 22:45:00
nextValue:
logdb:
TIME 1609229573.15818
VALUE 16
state:
logdb:
TIME 1609229573.15818
VALUE 22
READINGS:
2020-12-29 09:12:53 currValue 22
2020-12-28 09:49:27 disabled 0
2020-12-29 09:12:53 nextUpdate 2020-12-29 22:45:00
2020-12-29 09:12:53 nextValue 16
2020-12-29 09:12:53 state 22
SWITCHINGTIMES:
12345|05:03|22
06|06:05|22
01234|22:45|16
56|23:50|16
TIMER:
HCKWZ1_3:
HASH HCKWZ1
MODIFIER 3
NAME HCKWZ1_3
HCKWZ1_SetTimerOfDay:
HASH HCKWZ1
MODIFIER SetTimerOfDay
NAME HCKWZ1_SetTimerOfDay
SETTIMERATMIDNIGHT 1
HCKWZ1_delayed:
HASH HCKWZ1
MODIFIER delayed
NAME HCKWZ1_delayed
helper:
daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
SWITCHINGTIME:
0:
06:05:00 22
22:45:00 16
1:
05:03:00 22
22:45:00 16
2:
05:03:00 22
22:45:00 16
3:
05:03:00 22
22:45:00 16
4:
05:03:00 22
22:45:00 16
5:
05:03:00 22
23:50:00 16
6:
06:05:00 22
23:50:00 16
WEDAYS:
3 Neujahr
4 1
5 1
profil:
1:
EPOCH 1609214580
PARA 22
TIME 05:03
WE_Override 0
TAGE:
1
2
3
4
5
2:
EPOCH 1609218300
PARA 22
TIME 06:05
WE_Override 0
TAGE:
0
6
3:
EPOCH 1609278300
PARA 16
TIME 22:45
WE_Override 0
TAGE:
0
1
2
3
4
4:
EPOCH 1609282200
PARA 16
TIME 23:50
WE_Override 0
TAGE:
5
6
profile_IDX:
0:
06:05:00 2
22:45:00 3
1:
05:03:00 1
22:45:00 3
2:
05:03:00 1
22:45:00 3
3:
05:03:00 1
22:45:00 3
4:
05:03:00 1
22:45:00 3
5:
05:03:00 1
23:50:00 4
6:
06:05:00 2
23:50:00 4
Attributes:
WDT_Group former_HC
alias Wohnzimmer vorne
commandTemplate set $NAME desired-temp $EVENT
disable 0
group Heizplan
room Heizung
Hoffe jemand hat ne Idee?
Im Moment fehlt mich auch eine Idee dazu, zumal das ja nur einen Teil der WDT betreffen soll, was dafür spricht, dass ggf. irgendwas lokales da reinspielt und es kein generelles Problem des WDT an sich ist...
"Komisch" finde ich zunächst, dass die letzte Schaltung um 09:12:53 Uhr war. Das hängt aber vermutlich mit irgendwas außerhalb WDT zusammen (Neustart?, set-Anweisung? DEF angefasst?).
Wenn im Normalbetrieb der Schalt-/Aktualisierungszeitpunkt paßt, gibt es m.E. eigentlich keinen Anlass zu der Annahme, dass der erste Schaltzeitpunkt irgendwie anders sein soll als einer der weiteren. Wie hast du festgestellt, dass die Befehle "ausfallen"?
(Insbesondere) wegen der ZWave-Funk-Thematik gibt es grade eine Testversion (https://forum.fhem.de/index.php/topic,111401.0.html), mit der sich die Befehle etwas verzögern lassen - falls speziell um die Zeitpunkte herum noch andere Dinge (relativ) synchron laufen sollen...
(Eventuell könnte das vermehrte Auftreten von Funkaussetzern (falls es solche sind) mit Änderungen am ZWave-Modul zusammenhängen. Aber dazu sollte man erst mal eine gesicherte Basis haben, dass die Befehle wirklich rausgehen).
Hi,
Naja, ich lasse die Schaltzeitpunkte halt immer um eine Minute versetzt laufen, so gibt es normalerweise keine Probleme bei den Aktoren... die Aktoren, die schalten sind halt im Log von FHEM zu den entsprechenden Zeiten mit den den entsprechenden Befehlen im Log.
Zu dem letzten Zeitpunkt: ich hatte mit Switch in the past und enable/disable gespielt. Das ganze ist jetzt mindestens seit drei Tagen so... für mich echt sonderbar. Kann es irgendwie daran liegen, dass die Namen der Timer bei denen die nicht klappen gleiche Präfixes haben?
Hab mal nen Auszug vom FHEM-Log von heute dazu gepackt, wo eigentlich beide Devices hörten schalten müssen
2020.12.29 05:02:00 3: ZWave set OG_BAD_HEIZUNG desired-temp 22.5
2020.12.29 05:02:00 3: ZWave set EG_WZ_2HEIZUNG desired-temp 22.0
2020.12.29 05:04:00 3: ZWave set EG_KUC_HEIZUNG desired-temp 21.5
2020.12.29 05:04:00 3: ZWave set DG_VOR_HEIZUNG desired-temp 21.5
2020.12.29 05:04:05 2: ZWave: No ACK from DG_VOR_HEIZUNG after 5s for sentset:1327064301012200d72560
2020.12.29 05:05:00 3: ZWave set EG_FLUR_HEIZUNG desired-temp 21.5
2020.12.29 05:15:00 3: ZWave set DG_AZ_HEIZUNG desired-temp 21.5
2020.12.29 05:16:00 3: ZWave set EG_GWC_HEIZUNG desired-temp 21.5
2020.12.29 05:31:01 3: ZWave set OG_BZ_HEIZUNG desired-temp 21.5
Das wäre EG_WZ_1HEIZUNG um 05:03 und einmal OG_BAD_HTHEIZUNG um 05:06... die Befehle kommen nicht ins log... als es noch geklappt hat, sah es so aus:
2020.12.08 05:02:00 3: ZWave set OG_BAD_HEIZUNG desired-temp 22.5
2020.12.08 05:02:00 3: ZWave set EG_WZ_2HEIZUNG desired-temp 22.0
2020.12.08 05:02:05 2: ZWave: No ACK from EG_WZ_2HEIZUNG after 5s for sentset:1321064301012200dc255f
2020.12.08 05:03:00 3: ZWave set EG_WZ_1HEIZUNG desired-temp 22.0
2020.12.08 05:04:00 3: ZWave set EG_KUC_HEIZUNG desired-temp 21.5
2020.12.08 05:04:00 3: ZWave set DG_VOR_HEIZUNG desired-temp 21.5
2020.12.08 05:05:00 3: ZWave set EG_FLUR_HEIZUNG desired-temp 21.5
2020.12.08 05:06:00 3: ZWave set OG_BAD_HTHEIZUNG desired-temp 22.5
2020.12.08 05:30:01 3: ZWave set DG_AZ_HEIZUNG desired-temp 21.5
Hab jetzt auch nochmal ins Log geschaut. Das letzte mal sind die beiden am 25.12. morgens korrekt eingeschaltet worden. Ich mach eigentlich recht regelmäßig, fast täglich, Updates, gab es da irgendwie was neues? Was mich auch irritiert ist, dass nach einem Neustart on FHEM die Sets von allen Aktoren nicht mehr pro Forma nachgeholt werden. Ist das so gewollt?
Hmm, wenn es nicht im Log steht, kann das zwei Ursachen haben: Den verbose-Level des Zieldevices hast du aber nicht angefaßt, nehme ich an.
Updates via svn für den WDT gab es auch nicht seit dem 01.11., und es ist offenbar auch kein generelles Thema (sonst wären die anderen Schaltungen nicht da, das sind ja auch WDT).
ABER: es gibt seit neuestem ja ein Reading "desired-temp" in ZWave, wenn du das betreffende Attribut im IO gesetzt hast. Das bedeutet u.A. auch, dass WDT (in diesem Fall noch nicht so lange) prüfen kann, ob die aktuelle Schaltanweisung überhaupt was am Zieldevice verändert. Wenn nein, wird nämlich nicht geschaltet; das ist genau das, was du jetzt auch bei einem Neustart beobachtest...
Kurz: Ich gehe davon aus, dass "im Prinzip" auf der WDT-Seite noch alles ok ist. Du solltest ggf. mal nachsehen, ob du das logging der ZWave-Thermostate umbaust, um besser nachvollziehen zu können, ob alle Schaltanweisungen durchgestellt werden.
Hi,
Ja das scheint es zu sein, das desired-temp reading ist bei den beiden irgendwie out-of-Sync... danke!! Mal schauen wie ich das besser hinkriege.
Zu deiner Testversion muss ich mal in den Thread schauen, was du da vorhast :)
Vg!
Danke für die Rückmeldung.
Dass WDT erst mal schaut, ob der alte der neue Wert ist, ist übrigens "schon immer" so, habe grade mal auf Verdacht hier nachgesehen: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/98_WeekdayTimer.pm?rev=10392#L919 (ist also mind. 5 Jahre alt...).
Die Testversion bringt eingentlich "nur" drei Sachen:
- das WDT_sendDelay; das ist speziell für ZWave interessant;
- WDT_eventMap; das ist eher für KNX-User interessant, die das mit weekprofile zusammen nutzen wollen;
- das ganze als package. Das ist eher für mich interessant, weil es mir das Leben vereinfacht...
"Nachteil": die Brücke zu Heating_Control ist endgültig abgerissen. Aber du hattest das ja erfolgreich umgestellt, wie man an der Gruppenzugehörigkeit gut ablesen kann :) .
Weiter ist das umstellen auf package "etwas" gefährlich, weil man die Funktionsaufrufe abändern muss, und dabei das Risiko der "undefined subroutine" besteht, was dann FHEM abschmieren läßt. Scheint aber keine Stellen mehr zu geben, von daher: herzliche Einladung, das auszutesten und ggf. auch mal die Kombi mit weekprofile mal anzusehen. Die, bei denen "der Groschen gefallen ist", fanden das bisher alle cool :) .