Weekdaytimer nach Delay wegen geöffnetem Fenster kein neuer Wert im FHT-Thermost

dlehmann69 · 09 Oktober 2019, 12:09:47

Hallo,

ist natürlich beides gemacht. Sowohl ein Device für holiday angelegt als auch das Attribut in global gesetzt.

Dirk

Beta-User · 09 Oktober 2019, 12:42:26

Thx. Ich denke, das Problem gefunden zu haben. Leider habe ich noch keine Idee, wie man es behebt:

Für einen Tag, der per weekEnd zum Wochenende erklärt ist, tauchen die Schaltzeitpunkte zwar nicht in den helper-SWITCHINGTIME-Infos auf, aber in den profile_IDX-Angaben (im list). Das scheint übrigens für alle holiday-Devices zu gelten, hat also mit weekEnd/IsWe() eigentlich gar nicht direkt was zu tun.

Na jedenfalls werden bei WeekdayTimer_searchAktNext() dann diese profile_IDX-Angaben ausgewerten. Ergo muß verhindert werden, dass die da überhaupt reinkommen (denke ich jedenfalls)... Ganz schön kompliziert, das ganze.

dlehmann69 · 09 Oktober 2019, 16:34:09

Immerhin hast du eine Idee, woran es liegen könnte. Wenn ich was testen soll, sag einfach Bescheid.

Beta-User · 09 Oktober 2019, 17:34:46

Also, anbei mal eine Testversion, die das Problem zu beseitigen scheint. Für einen beschleunigten Start bitte den fraglichen Timer auch gleich mit "enable" dazu bewegen, die heutigen Zeiten nochmal zu ermitteln...

dlehmann69 · 09 Oktober 2019, 19:09:44

Version ist eingespielt und FHEM neu gestartet. Erste zugehörige Meldung beim FHEM Start im Log ist:

Code Auswählen

2019.10.09 18:59:28 3: [HZT_Schlafen] Reading/Attribute 'Window' of sz_fenster not found, sz_fenster ignored - inform maintainer

sz_fenster hat aber eigentlich ein solches Reading. Hier mal die komplette Definition.

Code Auswählen

defmod sz_fenster CUL_FHTTK 58f177
attr sz_fenster userattr HomeModeAlarmActive HomeReadings HomeValues HomeContactType:doorinside,dooroutside,doormain,window HomeOpenMaxTrigger HomeOpenDontTriggerModes HomeOpenDontTriggerModesResidents HomeOpenTimeDividers HomeOpenTimes
attr sz_fenster HomeContactType window
attr sz_fenster HomeModeAlarmActive armaway
attr sz_fenster HomeValues Open
attr sz_fenster IODev CUL_1
attr sz_fenster alias Schlafen Fenster
attr sz_fenster model FHT80TF
attr sz_fenster room CUL_FHTTK,Schlafen

setstate sz_fenster Closed
setstate sz_fenster 2019-10-09 06:18:34 Previous Open
setstate sz_fenster 2019-10-09 19:01:54 Reliability ok
setstate sz_fenster 2019-10-09 19:01:54 Window Closed
setstate sz_fenster 2019-10-09 19:01:54 batteryState ok
setstate sz_fenster 2019-10-09 19:01:54 state Closed

Beta-User · 09 Oktober 2019, 19:43:50

? Bin etwas ratlos, wo das jetzt herkommen soll...

Kannst du bitte zum einen mal nachsehen, ob das früher schon mal kam und zum anderen testen, ob es trotzdem funktioniert (könnte etwas mit der Reihenfolge in der cfg bzw. dem späteren Laden der Werte aus der statefile zu tun haben). An der Reihenfolge bzw. der Initialisierung des Moduls wollte ich eh' nochmal was drehen - per default sollte bei nicht deaktiviertem Device immer gleich ein "enable" ausgeführt werden, dann stimmen auch alle Timerwerte zeitnah zum FHEM-Start...

dlehmann69 · 09 Oktober 2019, 20:23:35

Okay sorry. Beim letzten Neustart am 5. Oktober gab es die Meldung auch schon. Habe ich damals in den zahlreichen Meldungen beim Neustart übersehen / nicht darauf geachtet. Scheint ja trotzdem zu funktionieren.

Ich nutze die configdb, da kann ich die Reihenfolge nicht mehr beeinflussen (denke ich).

Also warten wir morgen früh ab. Ich schließe das Fenster wieder erst nach 6:55 Uhr.

Beta-User · 09 Oktober 2019, 20:56:08

Puh, "wenigstens das"... (Man kann durch löschen/Neuanlegen auch @configDB was an der Reihenfolge drehen, aber das ist ja nicht Sinn der Übung, außerdem dürfte das bei Readings alleine nichts helfen, die statefile wird trotzdem erst nach allen defines gelesen

).

Im Anhang der Versuch, manche der Initialisierungsroutinen etwas verzögert auszuführen. Könnte sein, dass das das die Einträge bereits eliminiert, kann aber auch Nebenwirkungen haben...

dlehmann69 · 09 Oktober 2019, 21:20:47

Okay eingespielt und neu gestartet. Jetzt kommen folgende Meldungen bzgl. WeekdayTimer.

Code Auswählen

2019.10.09 21:09:20 3: [main::WeekdayTimer_SetTimerOfDay] myHash not valid
2019.10.09 21:09:20 3: [main::WeekdayTimer_SetTimerOfDay] myHash not valid
2019.10.09 21:09:20 3: [main::WeekdayTimer_SetTimerOfDay] myHash not valid
2019.10.09 21:09:19 3: [main::WeekdayTimer_SetTimerOfDay] myHash not valid
2019.10.09 21:09:19 3: [main::WeekdayTimer_SetTimerOfDay] myHash not valid
2019.10.09 21:09:19 3: [main::WeekdayTimer_SetTimerOfDay] myHash not valid
2019.10.09 21:09:19 3: [main::WeekdayTimer_SetTimerOfDay] myHash not valid
2019.10.09 21:09:16 3: [HZT_Schlafen] Reading/Attribute 'Window' of sz_fenster not found, sz_fenster ignored - inform maintainer

Da die neue Meldung sieben Mal kommt und ich sieben Timer für die Heizung haben, könnte das damit zusammen hängen. Dafür brauchte ich kein enable mehr setzen, die Timer hatten alle ihre aktuellen Werte.

Noch was anderes. Mir ist beim anlegen aufgefallen, das das Attribute commandTemplate für die FHT Thermostate und das HM Wandthermostat schon richtig eingestellt waren auf

Code Auswählen

commandTemplate set $NAME desired-temp $EVENTBei den HM Heizungthermostaten fehlte das "disired-temp". Kann das damit zusammenhängen, das für diese Thermostate der Channel Clima und nicht Climate verwendet werden muss.

Beta-User · 10 Oktober 2019, 07:29:29

Anbei eine wg. der Startgeschichte nochmals angepaßte Fassung; damit sollten die "7-fach"-Meldungen und auch das mit dem Fensterkontakt Geschichte sein (allerdings bin ich nicht ganz sicher, ob die Meldung später dann noch im Log landet, wenn man wirklich eine falsche Type hat...). (Was in dem Zuge immer noch nicht erledigt ist, ist ein Hinweis, wenn das Zieldevice noch nicht definiert ist, also in der config hinter dem WDT steht...).

Was das mit den Homematics angeht: Kannst du mal schauen, ob du bei dem WT nicht den Climate-Kanal direkt angegeben hast? Entsprechend wäre bei den RT's dann der Clima-Kanal auszuwählen.

dlehmann69 · 10 Oktober 2019, 10:26:30

Also neue Version jetzt heute früh eingespielt, leider erst nach dem Test mit dem Fenster. Folgendes ergaben die Tests:

der Timer wird mit der Version von gestern immer noch um 6:55 Uhr geskiped
mit der Version von gestern Abend hat heute früh nur der Timer, der getestet wird wegen dem Fenster, geschaltet. Alle anderen 6 haben nicht zur angegebenen Zeit geschaltet und brauchten einen manuellen Anstoß. Kann vielleicht an dem enable liegen. Habe ich nur für den einen Timer gemacht.
Version von heute früh lief beim Start ohne Meldungen. Dafür hat der im Test befindliche Timer wieder zurück auf 16°C geschaltet. Stand vorher auf 20°C durch manuellen Anstoß von mir. Das Zurückschalten auf 16°C erfolgte beim Start von FHEM. Der Timer ließ sich aber wieder manuell zu den 20°C bewegen. Dies lässt sich mit jedem Neustart nachstellen.

Zu den Homematics habe ich noch einmal meinen Anlagevorgang geprüft. Ich hatte für die Heizkörperthermostate den Channel Climate angegeben. Und erst im Nachhinein den Fehler bemerkt und im Timer das Device auf Clima geändert. Daher wahrscheinlich das fehlende desired-temp im Attribut.

Beta-User · 10 Oktober 2019, 15:52:52

Geskipped hat die Version von 20:56 Uhr, nehme ich an?

Bisher scheint die Version von 17:34 ganz ok zu sein, wenn man von der Initialisierung absieht, oder bezog sich der Test auf diese Fassung? Wenn möglich, dann bitte erst mal die verwenden.

Wegen der gesamten Initialisierung bastle ich grade noch etwas rum, aber dabei passieren teils "lustige" Sachen

...

dlehmann69 · 10 Oktober 2019, 16:33:24

Okay die Version von 17:34 Uhr ist wieder eingespielt, das FHEM neu gestartet und alle Timer einmal auf enable gesetzt. Nun schauen wir einmal morgen früh.
Das mit dem Fenstersensor ist aber schon komisch. Er meckert nur bei dem einen Sensor. Ich habe ja drei FHT und drei HM Thermostate mit einem Fenstersensor. Aber nur das Reading ist noch nicht da.

Beta-User · 10 Oktober 2019, 16:38:34

ebend. Es ist ein Reading, der Rest dürften Attribute sein. (Attribut: vorheriges define reicht; Reading: statefile muß gelesen werden...)

Wie dem auch sei: Auf Basis der 17:34-Version anbei nochmal ein update, dieses Mal mit einer funktionierenden Initialisierung erst nach $init_done (hoffe ich wenigstens)

.

Bis auf etwas cleanup bin ich jetzt optimistisch, dass das so passen müßte

.

Danke für die Geduld bis dahin!

dlehmann69 · 10 Oktober 2019, 16:52:31

Aktuelle Version vom letzten Post ist eingespielt, FHEM neu gestartet und alle Timer einmal auf enable gesetzt. Jetzt kam folgende Meldung, aber wieder nur für den einen Timer:

Code Auswählen

2019.10.10 16:46:46 3: [HZT_Schlafen] no switches to send, due to possible errors.