DOIF: Ändert sich ein Wert während WAIT wird nicht abgebrochen

Begonnen von JMC, 17 Juli 2017, 07:22:26

Vorheriges Thema - Nächstes Thema

JMC

Hi,

Damian hatte ich meinem Thread im Anfängerforum gepostet, da ich aber denke, dass es hier besser aufgehoben ist stelle ich meine Frage hier nochmal:

Zitat von: Damian am 11 Juli 2017, 19:41:23
nimm einfach if und watchdog in einem:

my_threshold DOIF ([mein_sensor]>[mein_schwellenwert])(set bla on)

attr my_threshold wait 600


Hi,

was bei mir aber nicht klappt ist das wenn sich der Wert in den 600 ändert (also wieder unter den Schwellwert geht) der Befehl NICHT ausgeführt wird:

([Steckdose2:merker] eq "1" and [Thermo2:humidity] >= 55 and [Steckdose2] eq "off")(set Steckdose2 on) DOELSEIF ([Steckdose2:merker] eq "1" and [Thermo2:humidity] <= 48 and [Steckdose2] eq "on")(set Steckdose2 off) DOELSEIF ([Steckdose2:merker] eq "0" and [?Steckdose2] eq "on")(set Steckdose2 off)

Als wait habe ich 300:600:600

Den merker setze ich morgens spätestens zu einer gewissen Uhrzeit (oder beim ersten anschalten über den Taster am Aktor) und abends nehme ich ihn je nach Tag zu bestimmten Zeiten weg - das ist auch bei den Uhrzeiten kein Problem. Wenn ich aber über den Taster gehe fällt er automatisch in cmd_3 (weil der merker erst gesetzt wird wenn Steckdose2 "on" ist (in einem notify) - aber der 600 timer startet weil beim Abfragen der merker auf 0 steht)

Ich hatte eben für humidity einen Wert von 49, habe dann per setreading "manuell" zum testen ein reading von 56 gesetzt. Daraufhin hat das von mir definierte wait angefangen (300 Sekunden) - während der 300 Sekunden kam aber der "echte" humidity Wert von 49 zurück und so wie ich das DOIF verstanden hatte sollte ja dann die Ausführung des Befehls (bzw der wait timer) abgebrochen werden, oder? Oder habe ich da mal wieder nur was verpeilt?

Viele Grüße
Viele Grüße
JMC

Ellert

Zitatso wie ich das DOIF verstanden hatte

Welche Bedingung (Statuswechsel) hätte Deinem Verständnis nach den Wait-Timer löschen sollen?

JMC

Ich hatte ja von Hand per setreading den humidity wert für Thermo2 auf 56 gesetzt. Damit war ja [Thermo2:humidity] >= 55 und das wait hat angefangen. In dem Thread in dem Damian geantwortet hatte ging es bei meiner ursprünglichen frage schon um das abbrechen bei über/unterschreiten .

Während das wait lief hat sich dann Thermo2:humidity auf 49 geändert, damit war der ursprüngliche Zustand für das schalten von cmd_1 ja nicht mehr gegeben. Das wait läuft aber weiter - entweder hab ich da was verpeilt oder mir fehlt nur eine Einstellung dazu. Ich denke aber, dass ich fälschlicherweise davon ausgegangen bin, dass DOIF das wait abbricht wenn die ursprünglichen Voraussetzungen nicht mehr gegeben sind?

Viele Grüße
Viele Grüße
JMC

Frank_Huber


JMC

Der steht im Grunde genommen oben (ich hatte das define weggelassen):

define di_Test_Steckdose2 DOIF ([Steckdose2:merker] eq "1" and [Thermo2:humidity] >= 55 and [Steckdose2] eq "off")(set Steckdose2 on) DOELSEIF ([Steckdose2:merker] eq "1" and [Thermo2:humidity] <= 48 and [Steckdose2] eq "on")(set Steckdose2 off) DOELSEIF ([Steckdose2:merker] eq "0" and [?Steckdose2] eq "on")(set Steckdose2 off)
attr di_Test_Steckdose2 do always
attr di_Test_Steckdose2 wait 300:600:600


Edit:
das do always ist dazugekommen damit bei zu hoher Luftfeuchtigkeit nochmal angeschaltet wird wenn der Aktor in seiner voreingestellten Zeit ausgeht
Viele Grüße
JMC

Frank_Huber

Ja sorry, hatte ich durch die lange Zeile übersehen.

wechselt dein DOIF in den anderen Zweig? Wenn nicht passt was mit den Triggernden Events nicht. in deinem Fall dann vermutlich Thermo2.
Um den Wait abzubrechen muss ein anderer Zweig aktiv werden.

JMC

Zitat von: Frank_Huber am 17 Juli 2017, 09:13:51
Um den Wait abzubrechen muss ein anderer Zweig aktiv werden.

Und da haben wir den Fehler (in meiner Denkweise). Leider wurde das aus dem Wiki zum DOIF in der Einsteigerhilfe nicht wirklich klar:

Zitatwait

Das Attribut verzögert die Befehlsausführung, nach wahr werden einer Bedingung.

Laufende Wait-Timer werden bei einem Statuswechsel abgebrochen und die Befehle werden nicht ausgeführt.

Das klang für mich nach: "Wenn nach einem Statuswechsel die Bedingung nicht mehr wahr ist wird abgebrochen"

Er springt in keinen anderen zweig, daher wird das wait nicht abgebrochen. Dann muss ich mir was anderes einfallen lassen... Aber jetzt weiß ich ja wenigstens wozu ich mir was überlegen muss. Danke!
Viele Grüße
JMC

Ellert

Zitat von: JMC am 17 Juli 2017, 08:25:06
Ich hatte ja von Hand per setreading den humidity wert für Thermo2 auf 56 gesetzt. Damit war ja [Thermo2:humidity] >= 55 und das wait hat angefangen. In dem Thread in dem Damian geantwortet hatte ging es bei meiner ursprünglichen frage schon um das abbrechen bei über/unterschreiten .

Während das wait lief hat sich dann Thermo2:humidity auf 49 geändert, damit war der ursprüngliche Zustand für das schalten von cmd_1 ja nicht mehr gegeben. Das wait läuft aber weiter - entweder hab ich da was verpeilt oder mir fehlt nur eine Einstellung dazu. Ich denke aber, dass ich fälschlicherweise davon ausgegangen bin, dass DOIF das wait abbricht wenn die ursprünglichen Voraussetzungen nicht mehr gegeben sind?

Viele Grüße

Die Frage ist in der Commandref bereits beantwortet, zum Attribut wait steht dort:
ZitatEine bereits ausgelöste Verzögerung wird zurückgesetzt, wenn während der Wartezeit ein Kommando eines anderen DO-Falls, ausgelöst durch ein neues Ereignis, ausgeführt werden soll.

Das wäre erst ab 48 der Fall?

JMC

Mein Fehler - ich hatte mir die ref zum DOIF wait durchgelesen, allerdings scheinbar überhaupt nicht registriert, dass das ja genau mein Fall wäre. Vielen Dank!

Als Anregung: Vielleicht sollte dann auch der Wiki Text https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#wait abgeändert werden damit auch Einsteigern (für die der Artikel ja ist) klar wird, dass ein laufender Timer nur abgebrochen wird wenn ein anderer Fall ausgeführt werden soll, nicht wenn die ursprüngliche Bedingung nicht mehr Wahr ist nach einem Statuswechsel.
Viele Grüße
JMC

Ellert

Zitat von: JMC am 17 Juli 2017, 09:55:43
Mein Fehler - ich hatte mir die ref zum DOIF wait durchgelesen, allerdings scheinbar überhaupt nicht registriert, dass das ja genau mein Fall wäre. Vielen Dank!

Als Anregung: Vielleicht sollte dann auch der Wiki Text https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#wait abgeändert werden damit auch Einsteigern (für die der Artikel ja ist) klar wird, dass ein laufender Timer nur abgebrochen wird wenn ein anderer Fall ausgeführt werden soll, nicht wenn die ursprüngliche Bedingung nicht mehr Wahr ist nach einem Statuswechsel.

Ich finde es lobenswert, wenn Du im Wiki mitarbeiten möchtest.

Zitatdass ein laufender Timer nur abgebrochen wird wenn ein anderer Fall ausgeführt werden soll

Genau diese Aussage steht im Wiki, mit anderen Worten.
ZitatLaufende Wait-Timer werden bei einem Statuswechsel abgebrochen,

Zitatnicht wenn die ursprüngliche Bedingung nicht mehr Wahr ist nach einem Statuswechsel.

Es ist nicht notwendig, dass die ursprüngliche Bedingung unwahr wird, egal ob vor oder nach einem Statuswechsel.

Beispiel
([A]) (set ...)
DOELSEIF ([B]) (set ...)

wait 600:0


Wenn A logisch wahr wird, startet der Waittimer.
Wenn B logisch wahr wird, innerhalb des laufenden Waittimers, wird er abgebrochen, obwohl die Bedingung 1 noch wahr ist.

Also, das Abbrechen des Waittimers hat nichts mit dem unwahr werden der Bedingung zu tun, sondern geschieht nur im Zusammenhang mit einem Statuswechsel.

JMC

Ich verstehe worauf du hinaus willst und was du erklärst - ich möchte den Beitrag im Wiki allerdings nicht einfach editieren da ich ja erst vor wenigten Tagen mit FHEM angefangen habe - und ja scheinbar den Satz aus dem Einsteigerleitfaden (als Einsteiger) anders verstehe (bzw auf den "falschenb" Status beziehe):

ZitatLaufende Wait-Timer werden bei einem Statuswechsel abgebrochen und die Befehle werden nicht ausgeführt.

Wenn man den Satz genau nimmt, dann steht da, dass ein Wait-Timer abgebrochen wird wenn sich ein Status wechselt. Ob das jetzt der Status des DOIF selber ist - oder der Status eines der abgefragten Werte im IF Teil des DOIFs wird da für mich als Einsteiger überhaupt nicht klar, bzw war das für mich halt auf den IF Teil bezogen (in deinem Beispiel A = 1 wechsel auf A = 2. Das die Bedingung natürlich weiterhin wahr ist (ungleich 0) ist ja vollkommen richtig. Ich denke, dass es generell dann länger ausformuliert sein sollte im Einsteigerleitfaden - mir war es als DOIF Neuling bei dem Satz wie gesagt überhaupt nicht klar, für mich ist ein Statuswechsel in dem Moment ein Statuswechsel der Bedingungen vom IF-Teil - nicht ein Statuswechsel vom DOIF (das dann von cmd_1 auf cmd_2 springt) - daher gab es da das Missverständniss.

Ich möchte hier aber auch keine Haare spalten oder 'stänkern' - ich bin froh, dass ich meinen Fehler mit Hilfe des Threads finden und beheben konnte und etwas mehr Einsicht in das DOIF bekommen habe. Danke! Ich überlege mir ggf. mal eine andere Formulierung und schreibe die mal hier auf als Vorschlag fürs Wiki
Viele Grüße
JMC

Damian

Zitat von: JMC am 17 Juli 2017, 15:47:18
Ich verstehe worauf du hinaus willst und was du erklärst - ich möchte den Beitrag im Wiki allerdings nicht einfach editieren da ich ja erst vor wenigten Tagen mit FHEM angefangen habe - und ja scheinbar den Satz aus dem Einsteigerleitfaden (als Einsteiger) anders verstehe (bzw auf den "falschenb" Status beziehe):

Wenn man den Satz genau nimmt, dann steht da, dass ein Wait-Timer abgebrochen wird wenn sich ein Status wechselt. Ob das jetzt der Status des DOIF selber ist - oder der Status eines der abgefragten Werte im IF Teil des DOIFs wird da für mich als Einsteiger überhaupt nicht klar, bzw war das für mich halt auf den IF Teil bezogen (in deinem Beispiel A = 1 wechsel auf A = 2. Das die Bedingung natürlich weiterhin wahr ist (ungleich 0) ist ja vollkommen richtig. Ich denke, dass es generell dann länger ausformuliert sein sollte im Einsteigerleitfaden - mir war es als DOIF Neuling bei dem Satz wie gesagt überhaupt nicht klar, für mich ist ein Statuswechsel in dem Moment ein Statuswechsel der Bedingungen vom IF-Teil - nicht ein Statuswechsel vom DOIF (das dann von cmd_1 auf cmd_2 springt) - daher gab es da das Missverständniss.

Ich möchte hier aber auch keine Haare spalten oder 'stänkern' - ich bin froh, dass ich meinen Fehler mit Hilfe des Threads finden und beheben konnte und etwas mehr Einsicht in das DOIF bekommen habe. Danke! Ich überlege mir ggf. mal eine andere Formulierung und schreibe die mal hier auf als Vorschlag fürs Wiki

Man kann sicherlich im Wiki "Statuswechsel des DOIF-Moduls" ergänzen, damit es eindeutig wird.

Ich würde empfehlen zusätzlich auch die Commandref des DOIF-Moduls zu lesen. In diesem Fall steht beim Attribut "wait" dazu:

ZitatEine bereits ausgelöste Verzögerung wird zurückgesetzt, wenn während der Wartezeit ein Kommando eines anderen DO-Falls, ausgelöst durch ein neues Ereignis, ausgeführt werden soll.

Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert

Nach dem wir die Missverständlichkeit des Begriffes Statuswechsel im Einsteigerleitfaden herausgearbeitet haben, werde ich Damians Vorschlag aufgreifen  ;)