Glaubt mir bitte ich habe nichts verändert :-( aber zwei DOIF funktionieren nicht mehr, sie zeigen STATE inactive und nextUpdate 1970-01-01 01:00:00.
Internals:
CHANGED
COMMAND
CONDITION
DEF Elch Mo-So|06:45:00|on Mo-So|{sunrise_abs('HORIZON=-2',0,"07:15","08:40")}|off
DEVICE Elch
FUUID 5c500794-f33f-a44f-63b5-6862707fa29ac78c
GlobalDaylistSpec
LANGUAGE en
NAME ElchMorgends
NR 60
STATE inactive
STILLDONETIME 0
TYPE WeekdayTimer
READINGS:
2019-12-17 12:42:35 currValue off
2020-01-15 15:12:42 nextUpdate 1970-01-01 01:00:00
2019-12-17 12:42:35 nextValue on
2020-01-15 15:12:42 state inactive
SWITCHINGTIMES:
Mo-So|06:45:00|on
Mo-So|{sunrise_abs('HORIZON=-2',0,"07:15","08:40")}|off
TIMER:
ElchMorgends_SetTimerOfDay:
HASH ElchMorgends
MODIFIER SetTimerOfDay
NAME ElchMorgends_SetTimerOfDay
SETTIMERATMIDNIGHT 1
dayNumber:
!$we 8
$we 7
fr 5
mo 1
sa 6
su 0
th 4
tu 2
we 3
helper:
daysRegExp (su|mo|tu|we|th|fr|sa|\$we|\!\$we)
daysRegExpMessage (su|mo|tu|we|th|fr|sa|$we|!$we)
SWITCHINGTIME:
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 1579499100
PARA on
TIME 06:45:00
WE_Override 0
TAGE:
2:
EPOCH 1579503401
PARA off
TIME {sunrise_abs('HORIZON=-2',0,"07:15","08:40")}
WE_Override 0
TAGE:
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
room Garten
Was kann den da schief gelaufen sein ?
Gruß
Micha
selbe Fehlermeldung hatte ich gestern bei ein paar Thresholds...
habe die Wochentage Mo, Die usw. durch Zahlen (0 für Sonntag, 1für Montag usw.) ersetzt, dann gings wieder...
Ich glaube wir sind im falschen Film:
Zitat
LANGUAGE en
NAME ElchMorgends
NR 60
STATE inactive
STILLDONETIME 0
TYPE WeekdayTimer
READINGS:
2019-12-17 12:42:35 currValue off
2020-01-15 15:12:42 nextUpdate 1970-01-01 01:00:00
2019-12-17 12:42:35 nextValue on
2020-01-15 15:12:42 state inactive
stimmt, es ware WD-Timer bei mir, nicht Threshold...
Zitat von: kumue am 20 Januar 2020, 22:21:59
stimmt, es ware WD-Timer bei mir, nicht Threshold...
Es handelt sich in beiden Fällen dann wohl um WeekdayTimer und nicht um das DOIF-Modul. Am besten in Automatisierung verschieben.
Dann bitte Thread verschieben und umbenennen. [emoji6]
Gesendet von meinem Doogee S60 mit Tapatalk
sorry :-( umbenannt habe ich, verschieben kann bestimmt nur ein MOD ?
Nein, verschieben kann man auch selbst, und WeekdayTimer gehört nach "Kalendermodule", https://forum.fhem.de/index.php/board,85.0.html (https://forum.fhem.de/index.php/board,85.0.html), siehe MAINTAINER.txt, wie üblich (warum auch immer das schon immer so ist)...
In der Sache würde ich mal empfehlen, die Wochentagsangaben ganz rauszunehmen, also die DEF so zu ändern:
Elch 06:45:00|on {sunrise_abs('HORIZON=-2',0,"07:15","08:40")}|off
(Das Phänomen scheint mit der Änderung der Wochentagssteuerung auf volle Berücksichtigung aller holiday2we-Features zusammenzuhängen.
Sobald man "sinnvolle" Differenzierungen macht, (mit $we und !$we oder "echter" Wochentagssteuerung) scheint das auch kein Thema zu sein, nur diese "immer"-Angabe durch 0-6 oder Mo-So macht Probleme).
Zitat von: Beta-User am 21 Januar 2020, 11:01:55
Nein, verschieben kann man auch selbst, und WeekdayTimer gehört nach "Kalendermodule", https://forum.fhem.de/index.php/board,85.0.html (https://forum.fhem.de/index.php/board,85.0.html), siehe MAINTAINER.txt, wie üblich (warum auch immer das schon immer so ist)...
offensichtlich bin ich blind :-( Ich gehe auf ändern, finde aber keine Option zum verschieben.
Zitat von: mfeske am 21 Januar 2020, 14:14:42
offensichtlich bin ich blind :-( Ich gehe auf ändern, finde aber keine Option zum verschieben.
Na jedenfalls steht hier (https://forum.fhem.de/index.php/topic,13092.msg80067.html#msg80067):
ZitatFalls die Frage in der falschen Gruppe landen sollte, kann der Ersteller sie mit dem Button ganz unten links verschieben.
Du bist bei weitem nicht der erste, der das übersieht, aber bisher hat es dann bei den meisten, die den Button auch zunächst nicht gefunden hatten, dann am Ende doch geklappt...
prima, morgens steht jetzt wieder auf active
Elch 06:45:00|on {sunrise_abs('HORIZON=-2',0,"07:15","08:40")}|off
aber abends weigert sich noch. Ich habe leider die Zeile noch in der Zwischenablage von morgens gehabt und in abends kopiert :-( Ich weiss nicht mehr was drin stand.
Ich wollte eine Stunde vor Sonnenuntergang einschalten und um 23:30 ausschalten. Könnt ihr mir da bitte helfen ?
Gruß
Micha
Ungetestet:
{sunset_abs_dat($date,"CIVIL",-HOURSECONDS,"18:00","21:00")}|on 23:30|off
Hallo,
ich habe seit einiger Zeit ebenfalls das Problem, das viele meiner Weekdaytimer Definitionen auf "inactive" stehen. Mir ist das auch nicht sofort aufgefallen. Nun habe ich mir das mal genauer angesehen. Bei mir ist folgendes Problem. Wenn bei einem Neustart von FHEM oder bei einer manuellen Änderung der Definition die Bedingung "false" ist, geht der state auf "inactive". define Bad_Heizung_Control1 WeekdayTimer Bad_Heizung 08:00|22.0 (Value("Feiertag") eq 1) Und das "inactive" bekomme ich nur weg, wenn die Bedingung wieder "true" ist. Auch über den Tageswechsel bekomme ich kein "active", auch nicht mit "set xxx enable". Einzige Möglichkeiten sind: Die Bedingung ist "true" und ich ändere die Definition oder die Bedingung ist "true und ich führe "set xxx enable" aus.
Habe ich da etwas übersehen oder ist das so beabsichtigt?
Viele Grüße
Achim
Also ich habe:
Elch Mo-So|06:45:00|on Mo-So|{sunrise_abs('HORIZON=-2',0,"07:15","08:40")}|off
gegen
Elch 06:45:00|on {sunrise_abs('HORIZON=-2',0,"07:15","08:40")}|off
getauscht und es ging wieder.
nur für Abends
Elch Mo-So|{sunset_abs('HORIZON=-2',0,"15:30","22:30")}|on Mo-So|23:30|off
habe ich noch keine Lösung.
Zitat von: mfeske am 25 März 2020, 10:39:38
nur für Abends
Elch Mo-So|{sunset_abs('HORIZON=-2',0,"15:30","22:30")}|on Mo-So|23:30|off
habe ich noch keine Lösung.
??? Warum nicht
Elch {sunset_abs('HORIZON=-2',0,"15:30","22:30")}|on 23:30|offNochmal: Die Angabe "die ganze Woche" als "Mo-So" oder "0-6", "78" oä. macht keinen großen Sinn und bringt den WDT nur durcheinander, wenn man "
die ganze Woche" will, sollte man die
Wochentag-Angabe einfach weglassen!
Und warum packst du das alles nicht in einen WDT?
Grade getestet:
06:45:00|on {sunrise_abs('HORIZON=-2',0,"07:15","08:40")}|off {sunset_abs('HORIZON=-2',0,"15:30","22:30")}|on 23:30|offscheint zumindest plausible Ergebnisse zu liefern...
Zitat von: Achim am 25 März 2020, 08:38:02
Habe ich da etwas übersehen oder ist das so beabsichtigt?
Hi Achim,
ich habe das Problem noch nicht so richtig verstanden: MMn. sollte der WDT zum angegebenen Zeitpunkt den Befehl raussenden, wenn die Bedingung ok ist, ansonsten bleibt es bei "inactive", und zwar bei "switchInThePast"-Geräten (oder Heizungen) auch nach dem Tageswechsel, weil da direkt "rückwirkend" geprüft wird, was bei der letzten Schaltung des Vortags hätte passieren sollen.
Stimmen denn die Timer? bzw. wird tatsächlich geschaltet, wenn du das willst und die Bedingung paßt?
Oder was ist das eigentliche Thema?
Gruß, Beta-User
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.
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
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?
Hallo Beta User,
die Definitionen sehen folgendermassen aus (Raw Definition aus FHEM)
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
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
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
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.