WeekdayTimer inactive

[Achim]

Hallo Beta-User

das Problem ist, das bei "state = inactive" die Bedingung auch bei der nächsten Schaltzeit nicht geprüft wird, bzw. wahrscheinlich der Weekdaytimer auch die Zeit nicht mehr prüft. Die Readings sehen zwischen 12:46:03 und 12:47:00 so aus.

Code Auswählen Erweitern

currValue   22.0                 2020-03-25 12:46:03
nextUpdate  2020-03-25 12:47:00  2020-03-25 12:46:03
nextValue   22.0                 2020-03-25 12:46:03
state       inactive             2020-03-25 12:45:57
Dann setze ich den Dummy in der Bedingung auf wahr (noch von 12:47 aber nichts passiert um 12:47. Auch kein Update der Readings (nextUpdate). Der Zeitpunkt verstreicht ohne das sich an dem Timer etwas ändert.
In Wirklichkeit habe ich einiges mehr an Schaltzeiten und eine umfangreichere Bedingung. Der Effekt ist aber auch bei der unten beschriebenen einfachen Definition nachzuvollziehen. Zumindest bei mir.

Viele Grüße
Achim

[Beta-User]

Hmm,

Habe eben versucht, das nachzustellen, aber mit der DEF aus dem letzten Post, (wg. zu schaltendem Dummy mit switchInThePast-Attribut versehen), bekomme ich kein reading mit nextUpdate, das irgendwas zeitnahes auswerfen würde. Da steht auch direkt der morgige Zeitpunkt drin.

Grundsätzlich wird bei CONDITION auch nur einmalig (zum jeweiligen Schaltzeitpunkt) geprüft, ob die wahr ist, wenn nein, ist dieser Schaltzeitpunkt eben um. Das ist bei den "Fensterkontakten" und "delayedExecutionCond" anders: da wird alle Minute geprüft, ob das anders ist. Also entweder fehlt da noch eine Angabe, oder ich habe irgendwo was übersehen?

Kannst du mir evtl. vollst. Testcode mit einem Dummy als Zielgerät liefern?

[Achim]

Hallo Beta User,

die Definitionen sehen folgendermassen aus (Raw Definition aus FHEM)

Code Auswählen Erweitern

defmod Bad_Heizung_Controlx WeekdayTimer Bad_Heizung 12:47:00|22.0 (Value("Feiertag") eq 1)
attr Bad_Heizung_Controlx commandTemplate set $NAME desired-temp $EVENT

setstate Bad_Heizung_Controlx inactive
setstate Bad_Heizung_Controlx 2020-03-25 12:46:03 currValue 22.0
setstate Bad_Heizung_Controlx 2020-03-25 12:46:03 nextUpdate 2020-03-25 12:47:00
setstate Bad_Heizung_Controlx 2020-03-25 12:46:03 nextValue 22.0
setstate Bad_Heizung_Controlx 2020-03-25 12:45:57 state inactive

defmod Feiertag dummy
attr Feiertag setList 0 1

setstate Feiertag 1
setstate Feiertag 2020-03-25 12:46:27 state 1

Bad_Heizung ist ein FHT Device. Da weiss ich nicht, wie das mit dem Dummy funktioniert das WeekdayTimer dies als Temperaturdevice erkennt. switchInThePast Attribut habe ich nicht gesetzt. Ich vermute mal, das beim "state = inactive" auch am Schaltzeitpunkt die CONDITION nicht geprüft wird. So stellt es sich mir zumindest dar.

Viele Grüße
Achim

[Beta-User]

Hm, ok, jetzt kann ich das soweit nachvollziehen, mir war nicht klar, wo die 12:47 Uhr her waren, das hätte ein verzögerter Timer sein können....

Sieht so aus, als würde CONDITION tatsächlich (im Prinzip) nur einmal am Tag ausgewertet, nämlich bei der Erstellung aller timer für diesen Tag. Ist das "durch", wird eben auch nachträglich nur noch dann geprüft, wenn man den WDT zu einer vollen Neuberechnung "zwingt", sonst nicht...

Das macht für mich auch Sinn, und dieses eher statische Verhalten war mit ein Grund, warum ich die "enable- und WDT-Params-setter" eingeführt habe, damit man auf Änderungen im Umfeld reagieren kann, ohne das bei Heating_Control noch beschriebene Perl-Kommando zu nehmen. Kurz: Wenn du unter Tage den Dummy umschalten können willst, solltest du auch ein Aktualisierungskommando für deine(n) WDT dazupacken.

Ergo ist das m.E. keine wirkliche Fehlfunktion, ich muß mir nur irgendwann mal die commandref noch vornehmen, damit das alles etwas klarer wird.

Gruß, Beta-User

[Achim]

Hallo Beta-User,

ich hatte schon als "Workaround" jede Nacht um 0:10 alle WDT mit "set WDT enable" "neu gestartet". Die Conditions sind alles dummys welcher Tag heute ist und werden um 0:05 gesetzt. Damit bekam ich dann für diese Tag die richtigen WDTs aktiv, habe aber ein anderes Problem bekommen. Wenn ich die FHTs auf "auto" laufen habe (im Normalfall) setze ich an bestimmten Tagen z.B. die Temperatur in einem Raum morgens um 06:00 auf 21 Grad. Nur ein Zeitpunkt im WDT. Mit dem "set WDT enable" wird dann aber diese eine Temperatur auch Nachts um 0:10 gesetzt. Und das ist etwas zu früh.
Wie bekomme ich diesen Effekt weg.

PS.: das von mir beschriebene Verhalten war "früher" nicht. Ich weiß nur nicht genau, ab wann das so der Fall ist.

Viele Grüße
Achim

[Beta-User]

Hmm,

kann nicht sagen, ob das "früher" wirklich anders war, ich kann jedenfalls so oder so aus diversen Gründen nicht zurück... Und "alle" aktivieren, geht mit dem "WDT_.*"-Setter einfacher.

Die Mischung der Steuerungsebenen ist vermutlich mit ein Grund, warum das so komplex ist, und dann noch die Timings. WDT erwartet grundsätzlich, dass die "Rahmenbedingungen" bereits gesetzt sind, wenn er die Schaltzeiten ermittelt, da bist du mit deinen Dummy's vermutlich schlicht zu spät dran.
Du solltest also auch die Absenktemperatur mit angeben, und wenn es für 23:59 Uhr ist, oder eine disableCondition setzen...

M.E. solltest du dir die beiden Hauptgründe mal ansehen, warum das Verhalten sich geändert hat:
Da war zum einen IsWe(), das eine sehr viel komplexere "Anwesenheitssteuerung" über Feiertagskalender uä. zuläßt, und zum anderen die Option, via "weekprofile" und dem dortigen Topic-feature dynamisch Schaltzeiten zu ändern. Kombinierst du das, dürfte im Ergebnis die Komplexität geringer werden.