[gelöst] WeekdayTimer falsche Werte für nextValue, nextUpdate, currValue

Begonnen von Kenneth, 30 März 2020, 14:42:28

Vorheriges Thema - Nächstes Thema

Kenneth

Hi Zusammen,

mir ist heute aufgefallen das der WeekdayTimer falsche Werte für "nextValue", "curValue" und "nextUpdate" anzeigt.
Wie man sehen kann würde er das nächste Mal 19:40:04 Uhr auf Position "20" fahren.

nextValue  zeigt die Position für übernächste Fahrt an
nextUpdate zeigt die Uhrzeit für die übernächste Fahrt
currValue zeigt die Position der nächsten Fahrt an



Ich habe seit ewig nichts an diesem oder den anderen WT's geändert. Hat jemand evtl. eine Idee woran das liegen könnte?


Das "LIST" ist von 13:47 Uhr.
Internals:
   CFGFN      ./FHEM/Timer_Dummys.cfg
   COMMAND   
   CONDITION  (Value("Jahreszeit") eq "Winter")
   DEF        KiZi_Lo_Rollladen !$we|{sunrise_abs('HORIZON=-3',-12,"07:00:00","9:00:00")}|hoch $we|{sunrise_abs('HORIZON=-2',-12,"08:30:10","9:00:00")}|hoch $we,!$we|{sunset_abs('HORIZON=-3',-20,"16:01:00","19:40:04")}|20 (Value("Jahreszeit") eq "Winter")
   DEVICE     KiZi_Lo_Rollladen
   FUUID      5c81233a-f33f-2783-3e97-805cb640d45aec51
   GlobalDaylistSpec
   LANGUAGE   de
   NAME       WT_Wi_KiZi_Lo_Jalou
   NR         867
   Profil 0: Sonntag 08:30:10 hoch, 19:40:04 20
   Profil 1: Montag 07:00:00 hoch, 19:40:04 20
   Profil 2: Dienstag 07:00:00 hoch, 19:40:04 20
   Profil 3: Mittwoch 07:00:00 hoch, 19:40:04 20
   Profil 4: Donnerstag 07:00:00 hoch, 19:40:04 20
   Profil 5: Freitag 07:00:00 hoch, 19:40:04 20
   Profil 6: Samstag 08:30:10 hoch, 19:40:04 20
   Profil 7: Wochenende 08:30:10 hoch, 19:40:04 20
   Profil 8: Werktags 07:00:00 hoch, 19:40:04 20
   STATE      active
   STILLDONETIME 0
   TYPE       WeekdayTimer
   READINGS:
     2020-03-30 13:46:13   currValue       20
     2020-03-30 13:45:04   disabled        0
     2020-03-30 13:46:13   nextUpdate      2020-03-31 07:00:00
     2020-03-30 13:46:13   nextValue       hoch
     2020-03-30 13:46:13   state           active
   SWITCHINGTIMES:
     !$we|{sunrise_abs('HORIZON=-3',-12,"07:00:00","9:00:00")}|hoch
     $we|{sunrise_abs('HORIZON=-2',-12,"08:30:10","9:00:00")}|hoch
     $we,!$we|{sunset_abs('HORIZON=-3',-20,"16:01:00","19:40:04")}|20
   TIMER:
     WT_Wi_KiZi_Lo_Jalou_3:
       HASH       WT_Wi_KiZi_Lo_Jalou
       MODIFIER   3
       NAME       WT_Wi_KiZi_Lo_Jalou_3
     WT_Wi_KiZi_Lo_Jalou_SetTimerOfDay:
       HASH       WT_Wi_KiZi_Lo_Jalou
       MODIFIER   SetTimerOfDay
       NAME       WT_Wi_KiZi_Lo_Jalou_SetTimerOfDay
       SETTIMERATMIDNIGHT 1
   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:
         08:30:10   hoch
         19:40:04   20
       1:
         07:00:00   hoch
         19:40:04   20
       2:
         07:00:00   hoch
         19:40:04   20
       3:
         07:00:00   hoch
         19:40:04   20
       4:
         07:00:00   hoch
         19:40:04   20
       5:
         07:00:00   hoch
         19:40:04   20
       6:
         08:30:10   hoch
         19:40:04   20
       7:
         08:30:10   hoch
         19:40:04   20
       8:
         07:00:00   hoch
         19:40:04   20
     WEDAYS:
       5          1
       6          1
   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
     nl:
       Zondag
       Maandag
       Dinsdag
       Woensdag
       Donderdag
       Vrijdag
       Zaterdag
       weekend
       werkdagen
   profil:
     1:
       EPOCH      1585544400
       PARA       hoch
       TIME       {sunrise_abs('HORIZON=-3',-12,"07:00:00","9:00:00")}
       WE_Override 0
       TAGE:
         8
     2:
       EPOCH      1585549810
       PARA       hoch
       TIME       {sunrise_abs('HORIZON=-2',-12,"08:30:10","9:00:00")}
       WE_Override 0
       TAGE:
         7
     3:
       EPOCH      1585590004
       PARA       20
       TIME       {sunset_abs('HORIZON=-3',-20,"16:01:00","19:40:04")}
       WE_Override 0
       TAGE:
         7
         8
   profile_IDX:
     0:
       08:30:10   2
       19:40:04   3
     1:
       07:00:00   1
       19:40:04   3
     2:
       07:00:00   1
       19:40:04   3
     3:
       07:00:00   1
       19:40:04   3
     4:
       07:00:00   1
       19:40:04   3
     5:
       07:00:00   1
       19:40:04   3
     6:
       08:30:10   2
       19:40:04   3
     7:
       08:30:10   2
       19:40:04   3
     8:
       07:00:00   1
       19:40:04   3
   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
     nl:
       zo
       ma
       di
       wo
       do
       vr
       za
       $we
       !$we
Attributes:
   commandTemplate set $NAME  $EVENT
   disable    0
   group      WeekdayTimer_Winter
   room       Timer
Intel NUC @Ubuntu > FHEM 5.8
HM-LAN, NanoCul, Signalduino
EchoDot, Gardena Sileno, XT1, Somfy RTS
TabletUI

Beta-User

Liegt vermutlich an
"$we,!$we|"Mach' das weg...

(Ich hatte nie vermutet, dass es so viele Leute gibt, die derartige - an sich sinnfreie - Konstruktionen verwenden. Das Verhalten zu ändern, war aber notwendig, um die Änderungen rund um IsWe() abzufangen.
Bei Gelegenheit versuche ich da mal einen Fix einzubauen, der sowas direkt aus der DEF fischt...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Kenneth

#2
Hi Beta-User,


naja sinnfrei war es für mich, zum Zeitpunkt der Erstellung des WT (vor 5 Jahren) nicht weil ich der Annahme war man muss an der Stelle die Information zum "TAG" mitgeben... Aber du hast natürlich Recht, es ist sinnfrei  ;D
Danke für deinen Hinweis, jetzt werden die Werte wieder korrekt angezeigt.


Danke nochmal

VG

KiZi_Lo_Rollladen !$we|{sunrise_abs('HORIZON=-3',-12,"07:00:00","9:00:00")}|hoch $we|{sunrise_abs('HORIZON=-2',-12,"08:30:10","9:00:00")}|hoch {sunset_abs('HORIZON=-3',-20,"16:01:00","19:40:04")}|20 (Value("Jahreszeit") eq "Winter")
Intel NUC @Ubuntu > FHEM 5.8
HM-LAN, NanoCul, Signalduino
EchoDot, Gardena Sileno, XT1, Somfy RTS
TabletUI

det.

Hallo Beta-User,
Da es bei mir genau solch eine Fehlfunktion gab, ohne das ich irgendwelche  Wochenend Sachen in meinem Heizungs-Steuerung Weekendtimer drin habe, meine 2ct.
Heute geht es ohne Änderung wieder wie gewünscht. Tippe mal, wenn wir 2021 immer noch von Winter auf Sommerzeit umstellen, ist einen Tag lang der Fehler wieder da.
LG
det.

Beta-User

@det.:
Es mag zu beobachten gewesen sein, dass es am So. nicht "richtig" war (die Timer werden im Normalbetrieb nur einmal am Tag berechnet, und zwar kurz nach Mitternacht; für die Tage der Zeitumstellung ist das auch anderswo ein Thema, das vermutlich am einfachsten durch einen Neustart nach der Umstellung an diesen beiden Tagen "übergangsweise" gelöst werden könnte...), aber das hier geschilderte Problem lag und liegt deutlich tiefer und stammt ausdrücklich ja auch vom Montag (!).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors