Hallo zusammen,
nach einen Update habe ich ein geändertes Verhalten bei meinem DOIF (Workflows)
Hier ein kleines Beispiel:
([Shelly_5:state] eq "on") (set Shelly_5 off)
do always
wait 300
Bisher war es so, dass beim Einschalten von Shelly_5 300 Sekunden gewartet wurde und danach wurde Shelly_5 ausgeschaltet.
Ein Lichtschalter der nach der Betätigung das Licht einschaltet und nach 5 Minuten wieder automatisch ausschaltet.
Seit einem Update Beginnt wait von Beginn an neu die 300 Sekunden, wenn Shelly_5 den Status "on" zwischenzeitlich erneut meldet.
Also immer wenn der Shelly_5 meldet er sei noch an, beginnt der Zähler von neuem.
Das war bisher nicht der Fall.
Übersehe ich etwas?
Grüße
Der Tom
Hallo es gibt mehrer Möglichkeiten es zu realisieren.
Du kannst den Befehl "set Shelly_5 on-for-timer 300" nehmen
oder
im Shelly selbst über die Weboberfläche eine Ausschaltzeit setzen.
Gruß
Zitat von: Tommyland78 am 01 April 2019, 11:06:14
Hallo zusammen,
nach einen Update habe ich ein geändertes Verhalten bei meinem DOIF (Workflows)
Hier ein kleines Beispiel:
([Shelly_5:state] eq "on") (set Shelly_5 off)
do always
wait 300
Bisher war es so, dass beim Einschalten von Shelly_5 300 Sekunden gewartet wurde und danach wurde Shelly_5 ausgeschaltet.
Ein Lichtschalter der nach der Betätigung das Licht einschaltet und nach 5 Minuten wieder automatisch ausschaltet.
Seit einem Update Beginnt wait von Beginn an neu die 300 Sekunden, wenn Shelly_5 den Status "on" zwischenzeitlich erneut meldet.
Also immer wenn der Shelly_5 meldet er sei noch an, beginnt der Zähler von neuem.
Das war bisher nicht der Fall.
Übersehe ich etwas?
Grüße
Der Tom
Beim always hat sich nichts geändert, ein wait wird nicht unterbrochen, wenn der Timer noch läuft. Ansonsten brauche ich einen Gegenbeweis.
Zitat von: Damian am 01 April 2019, 15:10:52
Beim always hat sich nichts geändert, ein wait wird nicht unterbrochen, wenn der Timer noch läuft. Ansonsten brauche ich einen Gegenbeweis.
Also bei mir wird wait unterbrochen und beginnt von vorn an zu zählen.
Wie erbringe ich denn den Gegenbeweis den Du gern hättest.
Was genau brauchst Du?
Grüße
Der Tom
unterbrochen wird bei "do resetwait"
prüfe das doch nochmal und/oder poste ein vollständiges list vom DOIF.
Internals:
DEF ([Shelly_5:state] eq "on") (set Shelly_5 off)
FUUID 5c6920c2-f33f-6de2-315b-dc73b97b7faf7491
MODEL FHEM
NAME Auto_Licht_Aus_Treppenlicht_Workflow
NR 363
NTFY_ORDER 50-Auto_Licht_Aus_Treppenlicht_Workflow
STATE cmd_1
TYPE DOIF
VERSION 18890 2019-03-13 18:56:41
READINGS:
2019-03-31 23:04:37 cmd 1
2019-03-31 23:04:37 cmd_event set_cmd_1
2019-03-31 23:04:37 cmd_nr 1
2019-03-31 23:04:37 state cmd_1
2019-03-31 22:53:00 wait_timer 31.03.2019 22:58:00 cmd_1 Auto_Licht_Aus_Treppenlicht_Workflow
Regex:
accu:
attr:
wait:
0:
300
condition:
0 ::ReadingValDoIf($hash,'Shelly_5','state') eq "on"
devices:
0 Shelly_5
all Shelly_5
do:
0:
0 set Shelly_5 off
1:
helper:
globalinit 1
last_timer 0
sleeptimer -1
itimer:
perlblock:
readings:
0 Shelly_5:state
all Shelly_5:state
uiState:
uiTable:
Attributes:
do always
group Workflow Licht
room Workflow
wait 300
Mit dem set-Kommando hebelst du natürlich den wait aus. So steht das auch in der Commandref: https://fhem.de/commandref_DE.html#DOIF_setcmd
Hallo,
1) der set-Befehl übersteuert alle Attribute wie z. B. wait, do, usw.
2) ein laufender Wait-Timer wird unterbrochen
Ich glaube ich verstehe etwas nicht ganz.
Nach meinem Verständnis ist 1 +2 genau das was ich will.
Mit dem set-Befehl soll wait unterbrochen werden und der Timer beendet werden.
Nur wird der set-Befehl ja gar nicht ausgeführt. Der Timer beginnt ja immer wieder neu ohne den Set-Befehl.
Der Timer beginnt dann immer wieder neu, denn der Status vom Shelly_5 erneuert wird.
Wird der Status während der Wait-Timer läuft erneuert, beginnt wait von vorn an zu zählen ohne jemals den set-Befehl auszuführen.
und vor allem....es funktionierte ja bisher monatelang gut.
Grüße
Der Tom
Zitat von: Tommyland78 am 04 April 2019, 19:24:29
Hallo,
1) der set-Befehl übersteuert alle Attribute wie z. B. wait, do, usw.
2) ein laufender Wait-Timer wird unterbrochen
Ich glaube ich verstehe etwas nicht ganz.
Nach meinem Verständnis ist 1 +2 genau das was ich will.
Mit dem set-Befehl soll wait unterbrochen werden und der Timer beendet werden.
Nur wird der set-Befehl ja gar nicht ausgeführt. Der Timer beginnt ja immer wieder neu ohne den Set-Befehl.
Der Timer beginnt dann immer wieder neu, denn der Status vom Shelly_5 erneuert wird.
Wird der Status während der Wait-Timer läuft erneuert, beginnt wait von vorn an zu zählen ohne jemals den set-Befehl auszuführen.
und vor allem....es funktionierte ja bisher monatelang gut.
Grüße
Der Tom
Mit set cmd führst du den Befehl aus und beendest ggf. einen wait-Timer der lief. Bei jedem neuen Trigger läuft der wait-timer (der ja unterbrochen worden ist) neu an. Das ist so designt und funktionierte immer schon so.
Was nicht funktionieren darf, ist die Tatsache, dass ein
laufender Timer durch einen Trigger neugestartet wird. Das ist deinem List nicht zu sehen.
Hallo,
ja genau, so sollte es sein - ist es aber eben nicht.
Der laufende Timer wird durch das Triggern des Status vom Shelly_5 neu gestartet.
Ich kann das ja einsehen, kommt eine neue Statusmeldung, startet der Timer neu.
Wir können uns das gern per Teamviewer oder Skype gemeinsam ansehen.
Grüße
Der Tom
Also zuerst eine Anmerkung: wenn der Modulautor dir sagt, etwas hat sich nicht geändert, kannst Du ihm grundsätzlich glauben. Es können ja bei der Entwicklung Fehler passieren, aber für so ein simpel DOIF hätten schon viele andere Benutzer zwei Wochen nach der letzte Änderung gemeckert.
Bist Du sicher, dass inzwischen dein Shelly keinen anderen Status hat? Die log vom Schelly wäre nicht schlecht. Und/oder ein "list" vom DOIF vor dem Problem und nach dem Problem (und nicht nach einem "set <DOIFname> cmd_1")
EDIT: ich habe deinen Fall simuliert (ein dummy statt shelly, dass ich 2 oder dreimal mit "on" betätige) und ein DOIF. Ich kann dein Problem nicht reproduzieren
Hallo,
ich wollte nicht zum Ausdruck bringen, dass ich ihm nicht glauben würde! Das wäre etwas anmaßend...
Wenn das anders rüber kam, dann bitte ich um Entschuldigung.
Ich wollte nur sagen, dass es eben genau so ist wie ich schildere und ich mir das ja auch nicht erklären kann.
Ich habe aber absolut keine Ahnung wo ich ansetzen soll.
Das DOIF ist so simpel, dass ja im Grunde kaum weitere Fehlerquellen anstehen würden.
Ein List vom DOIF vor und nach dem Problem kann ich leider nicht bieten, ein davor habe ich nicht.
Das Log liefere ich gleich nach.
Grüße
Der Tom
dann evtl. ein "list" vom DOIF nach einem "set Shelly_5 on" und wieder ein "list" vom DOIF nach einem erneuten "set Shelly_5 on" vor dem Ende der 5 Minuten?
Ich habe den Fall bei mir nachgestellt, und es funktioniert wie erwartet.
Was allerdings an deinem List auffällig ist, ist die Tatsache, dass der Waiteintrag:
2019-03-31 22:53:00 wait_timer 31.03.2019 22:58:00 cmd_1 Auto_Licht_Aus_Treppenlicht_Workflow
nicht auf no timer steht.
Das kann eigentlich nur dann passieren, wenn man während der Timer noch lief, also vor 22:58, das System heruntergefahren hätte.
Eine andere Frage ist, warum führst du
Zitatset Auto_Licht_Aus_Treppenlicht_Workflow cmd_1
überhaupt aus.
Edit: Du kannst über DEF-Button das Modul neu initialisieren, dann wird der wait_timer-Eintrag definitiv gelöscht und dann noch mal testen.
ZitatDas kann eigentlich nur dann passieren, wenn man während der Timer noch lief, also vor 22:58, das System heruntergefahren hätte.
So dass er das Ende des Timers irgendwie "verpasst" hat?
Sollten wir nicht auch ein e_<doif>_state haben sollen?
Zitat von: amenomade am 04 April 2019, 20:49:15
So dass er das Ende des Timers irgendwie "verpasst" hat?
Sollten wir nicht auch ein e_<doif>_state haben sollen?
ja, da fehlen einige Sachen.
So sieht es im Normalfall aus:
Internals:
DEF ([FS:state] eq "on")(set bla blblb)
MODEL FHEM
NAME test_di
NR 614
NTFY_ORDER 50-test_di
STATE initialized
TYPE DOIF
VERSION 18890 2019-03-13 18:56:41
READINGS:
2019-04-04 20:55:13 Device FS
2019-04-04 20:55:11 cmd 0
2019-04-04 20:05:26 diff 0
2019-04-04 20:55:13 e_FS_state on
2019-04-04 20:55:11 mode enabled
2019-04-04 20:55:11 state initialized
2019-02-23 20:16:43 version 18557 2019-02-10 16:58:11
2019-04-04 20:55:13 wait_timer 04.04.2019 20:55:43 cmd_1 FS
...
Attributes:
do always
wait 30Man sieht den Auslöser:
2019-04-04 20:55:13 e_FS_state on
und das auslösende Device:
2019-04-04 20:55:13 Device FS
Ein Problem mit dem statefile?
EDIT: ne eigentlich nicht, es denn... heruntergefahren
Hier https://forum.fhem.de/index.php/topic,99243.msg926295.html#msg926295 ff. ist beschrieben, wie es zu dem Timerfragment kommt.