Hallo Damian,
Bis vor kurzem hat ein DOIF nur Events erzeugt, wenn eine Bedingung wahr wurde.
Jetzt führt auch jede Timeraktualisierung zu einem Event, auch wenn der Timer mit ? gekennzeichnet ist.
Dieses Verhalten führt dazu, dass ein abhängiges DOIF unerwartet schaltet.
erstes_di DOIF ([?07:00-08:00] and [Trigger]) (set ...)
DOELSEIF ([22:00]) (set ...)
abhaengig_di DOIF ([erstes_di] eq "cmd_2") (set ...)
DOELSEIF ...
...
...
...
abhaengig_di do always
Das abhängige DOIF schaltet geplant um 22:00, wenn das erste DOIF auf cmd_2 geht.
Das abhängige DOIF schaltet aber auch unerwartet, wenn um 07:00 der Timer des ersten DOIF aktualisiert wird.
Ist dieses Verhalten gewollt, oder könntest Du es wieder abstellen.
Gruß
Ellert
Zitat von: Ellert am 11 März 2016, 09:00:57
Hallo Damian,
Bis vor kurzem hat ein DOIF nur Events erzeugt, wenn eine Bedingung wahr wurde.
Jetzt führt auch jede Timeraktualisierung zu einem Event, auch wenn der Timer mit ? gekennzeichnet ist.
Dieses Verhalten führt dazu, dass ein abhängiges DOIF unerwartet schaltet.
erstes_di DOIF ([?07:00-08:00] and [Trigger]) (set ...)
DOELSEIF ([22:00]) (set ...)
abhaengig_di DOIF ([erstes_di] eq "cmd_2") (set ...)
DOELSEIF ...
...
...
...
abhaengig_di do always
Das abhängige DOIF schaltet geplant um 22:00, wenn das erste DOIF auf cmd_2 geht.
Das abhängige DOIF schaltet aber auch unerwartet, wenn um 07:00 der Timer des ersten DOIF aktualisiert wird.
Ist dieses Verhalten gewollt, oder könntest Du es wieder abstellen.
Gruß
Ellert
Ja, ich habe für die Aktualisierung der Timer wie auch beim Wait-Timer ein Event verpasst. Das war für die Leute gedacht die FHEM2FHEM benutzen, um wie beim Wait-Timer die Informationen aktualisiert zu bekommen.
Da müssen wir überlegen, was wichtiger ist.
1. Die Timer-Events ließen sich schnell ausbauen.
2. Ich könnte Timer-Events per Attribut einschaltbar machen.
3. Du könntest auf ein Event des ersten DOIFs statt auf Status abfragen (falls beim ersten DOIF ein Wait-Timer definiert wäre, hätte man in deiner Konstellation auch früher schon das Problem)
Gruß
Damian
Ich denke das DOIF grundsätzlich nur Events erzeugen sollte, wenn es schaltet oder ein Wait-Timer aktiv wird, das ist leicht zu verstehen und zu überblicken.
Dann müsste dieser Fall
Zitat(falls beim ersten DOIF ein Wait-Timer definiert wäre, hätte man in deiner Konstellation auch früher schon das Problem)
mit einem cmd_x_0 gekennzeichnet werden. Dann hätte man auch ein Status für Wait-Beginn.
Abweichungen sollten dann per Attribut eingeschaltet werden.
ZitatDu könntest auf ein Event des ersten DOIFs statt auf Status abfragen
Ja, das macht etwas Arbeit und es muss immer überprüft werden, ob Stati mit and verknüpft werden, dann ist die Umstellung nicht so einfach.
Die Timer-Events ließen sich schnell ausbauen. Lieber nicht, es verlässt sich bestimmt schon jemand darauf.
ZitatIch könnte Timer-Events per Attribut einschaltbar machen.
Die Events sind ja relativ neu, das wäre sicher eine akzeptable Lösung.
Alternativ kann man auch die Attribute "event-on-update-reading" und "event-on-change-reading" nutzen, das wäre etwas umständlicher, weil man die Readings benennen muss, für die Events zugelassen werden. Für state ist es noch umständlicher, da hier auch noch das Attribut "addStateEvent" gesetzt werden muss.
Wenn nur "state" Events erzeugen soll, dann:
event-on-change-reading state
addStateEvent
Ich bin für "Bestandschutz" und daher für das Einschalten zusätzlicher Events per Attribut und wenn es unschädlich ist, für einen Status cmd_x_0 für Wait-Beginn.
Ich denke, ich baue ein Attribut für Timer-Events ein.
cmd_x_0 ist kritisch, weil dann ein Zustandswechsel des Moduls stattfindet, obwohl sich der Zustand erst später oder gar nicht ändert.
Das Verhalten vieler DOIF-Definitionen würde sich dadurch verändern.
Gruß
Damian
cmd_x_0 ist kritisch, weil dann ein Zustandswechsel des Moduls stattfindet
Ja, wenn man es benötigt, könnte man vor einem Statuswechsel das Timer-Ereignis als Timer-Beginn auswerten.
Danke
Ellert
Zitat von: Ellert am 11 März 2016, 15:14:12
cmd_x_0 ist kritisch, weil dann ein Zustandswechsel des Moduls stattfindet
Ja, wenn man es benötigt, könnte man vor einem Statuswechsel das Timer-Ereignis als Timer-Beginn auswerten.
Danke
Ellert
Testversion siehe hier: https://forum.fhem.de/index.php/topic,49109.msg423981.html#msg423981
Danke, es funktioniert wieder, wie gewohnt.