Autor Thema: Weekdaytimer nach Delay wegen geöffnetem Fenster kein neuer Wert im FHT-Thermost  (Gelesen 13352 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11156
  • eigentlich eher "user" wie "developer"
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).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 167
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?
FHEM 6.0 Development auf Ubuntu 20.04 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11156
  • eigentlich eher "user" wie "developer"
Ü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...
« Letzte Änderung: 14 November 2019, 16:11:56 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 167
So neue Version eingespielt, bisher nichts auffälliges. Bisherige Meldungen sind noch da.

Die Meldungen wegen möglicher Fehler.
[HZT_Schlafen] no switches to send, due to possible errors.
Kommt nur bei diesem Timer, wahrscheinlich weil nur hier das Fenster offen ist.[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.
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.
FHEM 6.0 Development auf Ubuntu 20.04 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 167
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.
FHEM 6.0 Development auf Ubuntu 20.04 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11156
  • eigentlich eher "user" wie "developer"
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?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 167
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.
FHEM 6.0 Development auf Ubuntu 20.04 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11156
  • eigentlich eher "user" wie "developer"
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...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 167
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.
FHEM 6.0 Development auf Ubuntu 20.04 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 167
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.

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.
FHEM 6.0 Development auf Ubuntu 20.04 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11156
  • eigentlich eher "user" wie "developer"
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.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 167
Ich bin dann mal auf Vorversion 19567 zurück gegangen. Mal sehen, was damit morgen früh läuft.
FHEM 6.0 Development auf Ubuntu 20.04 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 167
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.
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
FHEM 6.0 Development auf Ubuntu 20.04 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11156
  • eigentlich eher "user" wie "developer"
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...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 167
Alles klar.  Ich stehe weiterhin gern für Tests zur Verfügung.
FHEM 6.0 Development auf Ubuntu 20.04 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO