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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11156
  • eigentlich eher "user" wie "developer"
Hmm,

kannst du dann testweise noch am Ende der "Start"-Routine (bei L249) eine Zeile einfügen, so dass das dort so ausschaut:
$attr{$name}{commandTemplate} =
     'set $NAME '. WeekdayTimer_isHeizung($hash) .' $EVENT' if (!defined $attr{$name}{commandTemplate});

  WeekdayTimer_SetTimerOfDay({ HASH => $hash});
  WeekdayTimer_SetTimer($hash);
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
Okay habe die Zeile an besagter Stelle so eingefügt. Leider kommt noch immer die gleiche Meldung
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
Leider  mit letzter Version von gestern Nachmittag keine Verbesserungen. Die Meldungen kommen immer noch so und der Timer wird bei geöffnetem Fenster um 6:55 Uhr für den Wochentag geskiped. Aber es ist laut Aufruf auch heute noch Wochenende.
2019.10.1107:44:00 3: [HZT_Schlafen] delay of switching sz_heizung stopped.
2019.10.1106:55:00 3: [HZT_Schlafen] timer at 05:30 skiped by new timer at 06:55
2019.10.1105:30:00 3: [HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'

Was auch auffällt ist, dass der State des Timers selbst nach schließen des Fensters immer noch auf Window open stehen bleibt. Erst nach dem manuellem Anstoßen des Timers geht er wieder in den normalen Modus laut Zeitplan.
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"
 :o Hmm, die spannende Frage Frage ist doch, warum die 05:30 Uhr-Angabe überhaupt "angefahren" wird, wenn $we ist, eigentlich sollte dann nur 06:55 Uhr ein Rolle spielen...

Kannst du mal ein aktuelles list davon einstellen?
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 5:30 Uhr soll er schon anfahren, der Schaltpunkt gilt für jeden Tag. Werktags soll er dann eine Heizpause von 6:55 Uhr bis 16:00 Uhr einlegen und am Wochenende halt nicht. Warum fährt er 6:55 am Wochenende an, aber nur wenn das Fenster offen ist. Mit geschlossenem Fenster hat alles funktioniert.
Hier das aktuelle List.
Internals:
   COMMAND   
   CONDITION 
   DEF        sz_heizung 05:30|20.0 7|20:25|16.0 8|06:55|16.0 8|16:00|20.0 8|20:15|16.0
   DEVICE     sz_heizung
   FUUID      5d949033-f33f-73c2-f688-cd4b36882bbe6364
   GlobalDaylistSpec
   LANGUAGE   de
   NAME       HZT_Schlafen
   NR         321
   Profil 0: Sonntag 05:30:00 20.0, 20:25:00 16.0
   Profil 1: Montag 05:30:00 20.0, 20:25:00 16.0
   Profil 2: Dienstag 05:30:00 20.0, 20:25:00 16.0
   Profil 3: Mittwoch 05:30:00 20.0, 20:25:00 16.0
   Profil 4: Donnerstag 05:30:00 20.0, 20:25:00 16.0
   Profil 5: Freitag 05:30:00 20.0, 20:25:00 16.0
   Profil 6: Samstag 05:30:00 20.0, 20:25:00 16.0
   Profil 7: Wochenende 20:25:00 16.0
   Profil 8: Werktags 06:55:00 16.0, 16:00:00 20.0, 20:15:00 16.0
   STATE      20.0
   STILLDONETIME 0
   TYPE       WeekdayTimer
   Helper:
     DBLOG:
       currValue:
         DBLogging:
           TIME       1570776802.03367
           VALUE      20.0
       nextUpdate:
         DBLogging:
           TIME       1570776802.03367
           VALUE      2019-10-11 20:25:00
       nextValue:
         DBLogging:
           TIME       1570776802.03367
           VALUE      16.0
       state:
         DBLogging:
           TIME       1570776802.03367
           VALUE      20.0
   READINGS:
     2019-10-11 08:53:22   currValue       20.0
     2019-10-11 08:53:22   nextUpdate      2019-10-11 20:25:00
     2019-10-11 08:53:22   nextValue       16.0
     2019-10-11 08:53:22   state           20.0
   SWITCHINGTIMES:
     05:30|20.0
     7|20:25|16.0
     8|06:55|16.0
     8|16:00|20.0
     8|20:15|16.0
   TIMER:
     HZT_Schlafen_1:
       HASH       HZT_Schlafen
       MODIFIER   1
       NAME       HZT_Schlafen_1
       immerSchalten 1
     HZT_Schlafen_2:
       HASH       HZT_Schlafen
       MODIFIER   2
       NAME       HZT_Schlafen_2
     HZT_Schlafen_4:
       HASH       HZT_Schlafen
       MODIFIER   4
       NAME       HZT_Schlafen_4
     HZT_Schlafen_5:
       HASH       HZT_Schlafen
       MODIFIER   5
       NAME       HZT_Schlafen_5
     HZT_Schlafen_SetTimerOfDay:
       HASH       HZT_Schlafen
       MODIFIER   SetTimerOfDay
       NAME       HZT_Schlafen_SetTimerOfDay
       SETTIMERATMIDNIGHT 1
     HZT_Schlafen_delayed:
       HASH       HZT_Schlafen
       MODIFIER   delayed
       NAME       HZT_Schlafen_delayed
   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:
         05:30:00   20.0
         20:25:00   16.0
       1:
         05:30:00   20.0
         20:25:00   16.0
       2:
         05:30:00   20.0
         20:25:00   16.0
       3:
         05:30:00   20.0
         20:25:00   16.0
       4:
         05:30:00   20.0
         20:25:00   16.0
       5:
         05:30:00   20.0
         20:25:00   16.0
       6:
         05:30:00   20.0
         20:25:00   16.0
       7:
         20:25:00   16.0
       8:
         06:55:00   16.0
         16:00:00   20.0
         20:15:00   16.0
   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
   profil:
     1:
       EPOCH      1570764600
       PARA       20.0
       TIME       05:30
       TAGE:
         0
         1
         2
         3
         4
         5
         6
     2:
       EPOCH      1570818300
       PARA       16.0
       TIME       20:25
       TAGE:
         7
     3:
       EPOCH      1570769700
       PARA       16.0
       TIME       06:55
       TAGE:
         8
     4:
       EPOCH      1570802400
       PARA       20.0
       TIME       16:00
       TAGE:
         8
     5:
       EPOCH      1570817700
       PARA       16.0
       TIME       20:15
       TAGE:
         8
   profile_IDX:
     0:
       05:30:00   1
       20:25:00   2
     1:
       05:30:00   1
       20:25:00   2
     2:
       05:30:00   1
       20:25:00   2
     3:
       05:30:00   1
       20:25:00   2
     4:
       05:30:00   1
       20:25:00   2
     5:
       05:30:00   1
       20:25:00   2
     6:
       05:30:00   1
       20:25:00   2
     7:
       20:25:00   2
     8:
       06:55:00   3
       16:00:00   4
       20:15:00   5
   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
Attributes:
   WDT_Group  Heizung_Eco
   WDT_delayedExecutionDevices sz_fenster
   commandTemplate set $NAME desired-temp $EVENT
   group      Steuerung Heizpläne
   room       Heizung
   sortby     4
   switchInThePast 1
« Letzte Änderung: 11 Oktober 2019, 13:03:20 von dlehmann69 »
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"
 :) :'( :-\ :)
Das Verhalten scheint der Beschreibung nach also aus WeekdayTimer_delayedTimerInPast() zu kommen. Damit bin ich zwar einen kleinen Schritt weiter, habe aber mal wieder erst mal keine Idee, wie die Lösung dazu sein könnte :( . Ist einfach recht abstrakt, was Dietmar da gecoded hatte...
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
Naja du hast wenigstens mehr Ahnung vom Programmieren als ich.

So eine Idee von einem absoluten Laien, der einen Blick auf den Code geworfen hat. Kann es vielleicht auch um die Zeile 955 mit der Prüfung zu tun haben, ob der nächste Timer überhaupt relevant ist?
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"
Na ja, bin da auch nur mehr oder weniger zufällig rangeraten, und ob ich da wirklich viel weiter bin als du, mag ich nicht beurteilen ;D ::) .

Das Problem scheint mir zu sein, dass diese Funktion ständig aufgerufen wird, hier aber gar nicht hätte aufgerufen werden dürfen (bzw. mit einem anderen Parameter, nämlich dem Schaltzeitpunkt für $we, nicht dem für !$we). Der Code ist leider (?) sehr verschachtelt, so dass ich auch eher am Raten bin, was jetzt wie zusammengehört und wo eine Auswirkung hat. (Daher mußten auf jeden Fall erst mal die überflüssigen Schaltzeitpunkte aus profile_IDX raus).
Jetzt ist die spannende Frage (mMn.), wieso der Code dann bei der "Rückwärtssuche" plötzlich doch wieder auf die "basics" zurückkommt und dann die 7 bzw. 8 wieder ohne Berücksichtigung von den aktuellen tatsächlichen Gegebenheiten (IsWe()) "drüberschiebt". Vermute, das hat damit zu tun, dass das ohne Initialisierung auf den heutigen Tag (das, was jetzt "set ... enable" ist, und zuvor nur durch einen Tageswechsel veranlaßt wurde) sonst gar nicht anders möglich war.

Anders gesagt: Vermutlich muß in WeekdayTimer_delayedTimerInPast() geprüft werden, ob SETTIMERATMIDNIGHT (?) vorhanden ist. Wenn nein, wäre es die alte Routine, wenn ja, müßte erst rückwärts geschaut werden, was für timer für heute so anstehen. Ist da "noch nicht Zeit" (also noch kein Schaltzeitpunkt erreicht), entsprechend für den Vortag usw., wobei dann (korrekterweise eigentlich) für "gestern" und andere vergangene tage auch noch eine IsWe()-Prüfung dazukäme (die wird in den Profilen für die Zukunft gemacht)...
Das ganze ist aber ein feature, das in WDT dann eigentlich "schon immer" da gewesen sein müßte (bei Feiertagen). Komisch, dass das all die Jahre niemandem aufgefallen ist ??? .

Wie dem auch sei, ich werde wohl mal versuchen, das mit der simplen Unterstellung da reinzucoden, der Wert sei wahr (was neuerdings ja stimmen dürfte), dann können wir ja sehen, ob die grundsätzliche Überlegung richtig ist...
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 Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11156
  • eigentlich eher "user" wie "developer"
Anbei ein Versuch...

Kann im Moment nur sagen, dass das lädt, habe aber keine Ahnung, ob das wirklich was hilft ;D .
« Letzte Änderung: 12 Oktober 2019, 08:30:43 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
Funktioniert leider überhaubt nicht. FHEM stürzt nach dieser Meldung im Log komplett ab, ist nicht mehr erreichbar. Nach einem Neustart gleiche Situation.

Can't use string ("7") as an ARRAY ref while "strict refs" in use at ./FHEM/98_WeekdayTimer.pm line 1109.
Gehe zurück auf die vorherige Version
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"
UPS, da fehlen je ein paar eckige Klammern...Uptade folgt, dauert aber min. bis morgen.
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 und kein Problem. Bis jetzt ist da Fenster ja nur bei diesem einen Timer um die Schaltzeit offen.
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"
nur kurz angetestet, aber mit eckigen Klammern...
Führt jedenfalls bei delayed-FK's scheinbar nicht zum Absturz.
« Letzte Änderung: 14 November 2019, 16:12:11 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
Okay startet schon einmal problemlos. Test läuft dann später zu den Schaltzeiten morgen früh wieder. Oder ich lege zum testen mal heute einen zusätzlichen Timer an. Da heute ja Wochenende ist, wird das mit der Simulation eines Werktags aber schwierig.

Zur Info, diese Meldung ist noch da.
[HZT_Schlafen] no switches to send, due to possible errors.
Diese Meldung kam beim Start richtigerweise, da das Fenster noch offen ist.
[HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'
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 hier nun die Ergebnisse der letzten 24 Stunden. Aufgrund des schönen Wetters war das Fenster die gesamte Zeit offen. Trotzdem sieht man im Log, wie er trotz Wochenende jeden Schaltpunkt mitnimmt und immer wieder den Timer skiped.
2019.10.13 16:00:00 3: [HZT_Schlafen] timer at 06:55 skiped by new timer at 16:00
2019.10.13 06:55:00 3: [HZT_Schlafen] timer at 05:30 skiped by new timer at 06:55
2019.10.13 05:30:00 3: [HZT_Schlafen] timer at 20:25 skiped by new timer at 05:30
2019.10.12 20:25:00 3: [HZT_Schlafen] timer at 20:15 skiped by new timer at 20:25
2019.10.12 20:15:00 3: [HZT_Schlafen] timer at 16:00 skiped by new timer at 20:15
2019.10.12 16:00:00 3: [HZT_Schlafen] switch of sz_heizung delayed - sensor 'sz_fenster' Reading/Attribute 'Window' is 'Open'

Auch bleibt weiterhin der State im Timer nach dem Schließen des Fensters auf "Window open" stehen. So gesehen auch bei einem weiteren Timer mit Homematic Geräten.

Das war es leider nicht.  :(
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

 

decade-submarginal