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

[Beta-User]

Wenn du kein weekEnd-holiday-Device hast: Kannst du mal testen, ob das Problem mit der Version 19567 auch schon bestanden hat?

Ich versuche grade, den Code wieder in diese Richtung zu ändern, dabei aber die deutlich komplexere Auswertung, ob bzw. wann denn jetzt $we ist, (die mit 19806 kam, und auch andere unerwünschte Nebenwirkungen zu haben scheint) auf eine andere, zentrale Stelle zu verlagern (die dann auch nur einmal am Tag/auf Anforderung erneuert wird).

[dlehmann69]

Also ein Holiday Device habe ich, welches sich auf meine holiday Datei bezieht. In dieser steht dann halt drin, ob gerade ein Tag ist, welcher wie ein Wochenende behandelt werden soll. Ich könnte es ja testweise löschen und danach wieder anlegen. Die nächsten Tage brauche ich Datei gerade nicht.

Soll ich das testweise einmal tun und auf die genannte Version zurück gehen? Wo bekomme ich die eigentlich her? Aus einem Backup und/oder von SVN?

[Beta-User]

Über svn ist in der Regel einfacher (finde ich).

Anbei aber eine neue Version, die etwas näher an dem ursprünglichen h2we-Code dran ist. Jetzt werden die $we-Angaben (hoffentlich) nur einmal am Tag bzw. auf Anforderung ermittelt und können dann als statische Abfrage direkt aus einem Hash gelesen werden.

Test wäre willkommen, evtl. schaffe ich es auch, das Problem mal nachzustellen...

[dlehmann69]

So neue Version eingespielt, bisher nichts auffälliges. Bisherige Meldungen sind noch da.

Die Meldungen wegen möglicher Fehler.

Code Auswählen Erweitern

[HZT_Schlafen] no switches to send, due to possible errors.

Kommt nur bei diesem Timer, wahrscheinlich weil nur hier das Fenster offen ist.

Code Auswählen Erweitern

[HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'

Das holiday Device haben ich zunächst noch so belassen. Aktuell ist kein Wochenende. Trotzdem hatte die alte Version bei geöffnetem Fenster einen Timer fürs Wochenende berücksichtigt. Hätte ja eigentlich schon 20:15 Uhr geschaltet werden sollen.

Code Auswählen Erweitern

2019.10.14 20:25:00 3: [HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'

Mal sehen was morgen so läuft.

[dlehmann69]

Hier das bisherige Ergebnis.

Der unter Beobachtung stehende Timer hate heute Abend zu den Schaltzeiten ein geöffnetes Fenster. Laut Log hat der Timer um 20:25 Uhr reagiert. Das ist ja aber die Zeit fürs Wochenende. Dies ist laut Profile des Timers auch so.

Heute früh war zur Schaltzeit um 5:30 Uhr das Fenster offen und dieses wurde um 5:38 Uhr geschlossen. Der Timer hat immer richtig reagiert und die Heizung auch um 6:55 Uhr wieder runter gefahren.

Mal sehen wie es morgen früh mit geöffnetem Fenster läuft.

[Beta-User]

Der unter Beobachtung stehende Timer hate heute Abend zu den Schaltzeiten ein geöffnetes Fenster. Laut Log hat der Timer um 20:25 Uhr reagiert. Das ist ja aber die Zeit fürs Wochenende. Dies ist laut Profile des Timers auch so.

Wenn es im Profil so vorgesehen ist, sollte es passen. Ist denn das Profil nicht richtig, oder wie ist das obige zu deuten?
(Dann sollte ich aber die Infos haben, was in global als h2we-Attribut eingetragen ist, und ggf. ob in den holiday-Devices irgendwelche Urlaubs-/Feiertage usw. eingetragen sind.)

Ansonsten klingt das nach: Paßt soweit?

[dlehmann69]

Sorry war wohl gestern Abend schon etwas spät 

Laut Profil, was auch richtig ist, sollte er um 20:15 Uhr für Werktag schalten. Der Timer hat aber um 20:25 Uhr auf die Zeit fürs Wochenende reagiert und diese geskiped. Laut Abfrage ist auch kein Wochenende. Wegen dem geöffnetem Fenster aber erst mal kein Problem.


Heute früh hat er bei geöffnetem Fenster beide Zeiten für den Werktag geskiped, passt also erst einmal.

Am Freitag ist laut holiday Datei wieder Wochenende. Steht so auch schon im Profil des Timers. Da werden wir sehen, ob der Timer richtig reagiert.

[Beta-User]

Geskiped klingt trotdem erst mal nicht optimal, aber das war vermutlich vorher schon so.

Es scheint aber zumindest dahingehend eine Verbesserung zu sein, dass jetzt immer korrekt auf ein Schließen des Fensters reagiert wird, oder?

(Dann werde ich im anderen Thread nämlich auch mal um einen Test dieser Version bitten.)

Ist zwar irgendwie noch unfertig, denn eigentlich sollte der WEDAY-Hash komplett via IsWe() gefüllt werden und die Initialisierung noch etwas weiter verzögert (damit die holiday-Devices schon richtige Werte enthalten), aber wichtig wäre ja erst mal, dass auch bei Sonderkonstellationen die richtige Reaktion veranlaßt wird...

[dlehmann69]

Ja geskiped war vorher auch schon.

Das Schließen des Fenster war aus meiner Sicht nicht das Problem. Das Problem war, dass bei geöffnetem Fenster statt dem Timer fürs Wochenende der Timer für Werktag berücksichtigt wurde und dann beim Schließen des Fensters die Heizung wegen Werktag nicht geheizt hat. Gestern Abend war der Fall eher andersrum. Er hat beim skipen den Timer für das Wochenende berücksichtigt statt dem für den Werktag.

Ich würde gern den Freitag morgen abwarten. Da ist wieder laut Datei Wochenende und das Fenster steht offen. Mal sehen, ob er dann beim Schließen des Fensters den richtigen Timer berücksichtigt.

[dlehmann69]

So der Test heute früh mit der bekannten Konstellation ist gelaufen. Leider bringt das geöffnete Fenster die Abfrage, ob Wochenende ist, immer noch durcheinander. Hier die dazugehörigen Auszüge aus dem Log. Selbst gestern Abend wurde der Timer für Werktag um 20:15 richtig geschaltet für Werktag. Dann wurde das Fenster geöffnet und der Timer fürs Wochenende um 20:25 wurde geskiped. Und heute früh wurden bei geöffnetem Fenster alle Timer geskiped. Leider halt auch der für Werktag um 6:55 Uhr, obwohl heute wieder Wochenende ist.

Code Auswählen Erweitern

2019.10.18 08:45:49 2: FHT set sz_heizung desired-temp 20.0
2019.10.18 08:45:44 3: [HZT_Schlafen] set HZT_Schlafen enable
2019.10.18 07:54:00 3: [HZT_Schlafen] delay of switching sz_heizung stopped.
2019.10.18 06:55:00 3: [HZT_Schlafen] timer at 05:30 skiped by new timer at 06:55
2019.10.18 05:30:00 3: [HZT_Schlafen] timer at 20:25 skiped by new timer at 05:30
2019.10.17 20:25:00 3: [HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'
2019.10.17 20:15:00 2: FHT set sz_heizung desired-temp 16.0

Das Verhalten ist aus meiner Sicht auch unabhängig von einem Holiday Device. Den morgen früh ist ja normal immer Wochenende auch ohne einen Eintrag in der Datei für holiday. Wird aber auch wieder das gleiche Verhalten wie heute geben. Können wir noch abwarten.

[Beta-User]

Hmmm, dann muß ich da wohl weiter knobeln.

Was das $we-Thema angeht: Es ist nicht mehr zwangsläufig $we, nur weil grade Samstag oder Sonntag ist, man kann das mit einem Eintrag "weekEnd" bei holiday2we in global unterbinden bzw. dann mit entsprechenden Einträgen da entsprechend steuern. Gerade aus dem Grund scheint auch das Gefüge durcheinandergekommen zu sein (vermute ich jedenfalls).
Eventuell wäre es einen Versuch wert zu sehen, ob auch die Vorversion (19568 oder so) dieses Verhalten (schon) aufweist; das sollte immer dann komplikationslos gehen, wenn man keinen weekEnd- (und noWeekEnd-) Eintag hat bzw. braucht.

[dlehmann69]

Ich bin dann mal auf Vorversion 19567 zurück gegangen. Mal sehen, was damit morgen früh läuft.

[dlehmann69]

Der Test mit der Vorversion ist durch und ich muss leider sagen, gleiches Verhalten. Das geöffnete Fenster bringt die Timer durcheinander. Gestern Abend mit geschlossenem Fenster korrekt für Wochenende geschaltet. Heute früh bei geöffnetem Fenster dann wieder für Wochentag geschaltet und damit die Heizung ausgeschaltet. Für das aktivieren heute Früh funktionierte das enable nicht, nur ein single set hat den Timer wieder richtig gesetzt.

Code Auswählen Erweitern

2019.10.19 09:43:29 2: FHT set sz_heizung desired-temp 20.0
2019.10.19 09:42:39 3: [HZT_Schlafen] set HZT_Schlafen enable
2019.10.19 09:21:00 3: [HZT_Schlafen] delay of switching sz_heizung stopped.
2019.10.19 06:55:00 3: [HZT_Schlafen] timer at 05:30 skiped by new timer at 06:55
2019.10.19 05:30:00 3: [HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'
2019.10.18 20:25:00 2: FHT set sz_heizung desired-temp 16.0
2019.10.18 16:40:40 3: [HZT_Schlafen] Reading/Attribute 'Window' of sz_fenster not found, sz_fenster ignored - inform maintainer

[Beta-User]

Zwischeninfo: Das Thema ist noch auf der Liste, und durch den update, den ich eben ins svn geschubst habe, ist das auch nicht behoben; der bringt nur etwas mehr Transparenz dahingehend, was das IsWe()-Umfeld so an Ergebnis liefert und ergänzt HMCCUDEV als FK-Typ (das war der eigentliche Anlaß).
Irgendwie "beruhigt" es mich einerseits, dass der auf 19567 folgende commit zumindest für das Problem hier nicht als "Schuldiger" festgemacht werden kann, andererseits bedeutet das, dass ich wohl den Code gedanklich nochmal komplett auseinandernehmen muß und auch die Teile verstehen, die älteren Ursprungs sind. Das wird nochmal etwas dauern...

[dlehmann69]

Alles klar.  Ich stehe weiterhin gern für Tests zur Verfügung.