neues Modul DOIF

[maxritti]

Danke Euch beiden.
Ein wenig muss ich über die Sache wohl noch nachdenken.

do always in Verbindung mit zyklisch sendenden Sensoren, hier vermutlich: EG_dr_TS_Terrasse:luminosity, ist wenig sinnvoll.

Wenn man keinen Trigger bei solchen Sensoren haben will, dann muss man sie mit ReadingsVal(..) in der Bedingung angeben.

Gruß

Damian

Das verwirrt mich jetzt ein wenig.
Was heisst denn, wenn ich keinen Trigger von dem Device in das DOIF haben will, wenn ich ReadingsVal verwende?
Denn ausgewertet wird das ReadingsVal doch auch, so dass es als Bedinung gilt?
Oder wird das dann nicht ausgewertet? Das würde aber dann doch heissen, dass ich es erst gar nicht in die Bedingung mit aufnehmen müsste wenn es eh nicht ausgewertet wird.

Damian war mal wieder schneller, aber nur weil ich es etwas ausführlicher geschrieben habe: 

Du hast in Deinen Konditionen verschiedene Bedingungen drin. Wann immer ein dazu passendes Event auftritt, wird das DOIF getriggert, also beispielsweise wenn [mySL:Pac_avg] irgendeinen Wert meldet. Dann werden die Konditionen getestet, in denen dieser Wert enthalten ist. Ist keine der Konditionen wahr (weil der Wert zu hoch/zu niedrig ist oder eine verknüpfte Bedingung nicht stimmt), fällt DOIF auf den DOELSE-Fall zurück.

Genau aus diesem Grund ist (IMHO) eine der goldenen Regeln bei DOIFs, auf DOELSE möglichst zu verzichten bzw. es nur in Ausnahmefällen einzusetzen, wo man die Auswirkung genau überblicken und Seiteneffekte ausschließen kann. Und Deine Beschreibung passt genau zu solchen unerwarteten Seiteneffekten.

Ansonsten kannst Du Dir bei jeder Bedingung überlegen, ob sie wirklich eine Auswertung des DOIFs triggern soll. In einer zukünftigen Version wird es wohl die Möglichkeit geben, Bedingungen in DOIF-Notation als nicht-triggernd zu kennzeichnen. Bis dahin kann man anstelle der DOIF-Notation ganz klassisch Value oder ReadingsVal verwenden, um denselben Effekt zu erreichen.

Das hatte ich mir jetzt auch mal als DOIF-Gesetz gemacht, im wesentlichen keinen DOELSE zu implementieren.
Nur so recht verstanden habe ich es nicht, warum der DOELSE Zweig gestern abend überhaupt als Ergebis kommt.

Ganz naiv hätte ich halt gedacht, dass MasterDummy "an", draussen dunkel und oder [22:30] ausreichen würde damit das erste Command ausgeführt wird.
Aber vielleicht gehe ich das heute Abend noch mal in Ruhe an.

[Brockmann]

Nur so recht verstanden habe ich es nicht, warum der DOELSE Zweig gestern abend überhaupt als Ergebis kommt.

Beispiel:

Code Auswählen Erweitern

DOELSEIF (([duPVRollo:state] eq "an") and ([mySL:Pac_avg] >= 2100))
Wenn Du so definierst, wird diese Kondition jedes Mal angestossen, wenn das Reading Pac_avg aktualisiert wird. Ist der Wert dabei < 2100 scheitert die Kondition. DOIF schaut, ob weitere Konditionen mit diesem Reading vorhanden sind. Sind keine da oder scheitern die ebenfalls, verzweigt es zum DOELSE-Fall.

Gegenbeispiel:

Code Auswählen Erweitern

DOELSEIF ([duPVRollo:state] eq "an" and ReadingsVal("mySL","Pac_avg",0) >= 2100)
Bei dieser Variante wird die Kondition nur getriggert, wenn sich am Status von duPVRollo etwas ändert. Änderungen am Reading Pac_avg hingegen triggern das DOIF nicht. Diese Bedingung wird nur zusätzlich geprüft, wenn die Kondition durch duPVRollo getriggert wurde.

Vielleicht ist der Unterschied nun etwas klarer. Grundsätzlich kann man sagen: Bedingungen mit [] triggern und werden geprüft, Bedingungen ohne [] triggern nicht und werden nur geprüft, wenn von anderer Seite getriggert wurde.

Wobei es prinzipiell kein Problem ist, alle Bedingungen auch triggern zu lassen. Nur dann muss man eben mit einem DOELSE sehr aufpassen, da das DOIF bei JEDEM Event mit einer triggernden Bedingung etwa tut. Entweder führt es das passende DOIF bzw. DOELSEIF aus oder - wenn keines davon passt - kommt das DOELSE zur Ausführung, auch wenn das oftmals nicht gewollt ist.

[maxritti]

Brockmann ich danke Dir.

Die Beispiele sind prima und jetzt sollte es auch bei mir angekommen sein. 

[moonsorrox]

Vielleicht ist der Unterschied nun etwas klarer. Grundsätzlich kann man sagen: Bedingungen mit [] triggern und werden geprüft, Bedingungen ohne [] triggern nicht und werden nur geprüft, wenn von anderer Seite getriggert wurde.

ich lese ja ständig mit und sage auch wiedereinmal Danke für die Super Erklärung, aber dies nun letztendlich so zu begreifen braucht wohl etwas mehr, denn auch ich habe elendig viele Fehler gemacht...
Aber momentan laufen meine DOIFs mit Hilfe von Brockmann  weiter so, vllt begreife ich es ja nochmal

[Brockmann]

Ich habe gerade ein sonderbares Verhalten in Kombination mit dem wait-Attribut festgestellt.

Ich habe ein etwas komplexeres DOIF mit fünf DOELSEIFs, also sechs Konditionen und sechs Aktionen. Dazu gehört:

Code Auswählen Erweitern

attr MeinDOIF wait 300:0:0:0:300:0

Nun passiert folgendes: Zwei verschiedene Konditionen des DOIFs werden praktisch zeitgleich durch zwei verschiedene Readings getriggert und beide Konditionen sind insgesamt wahr. Ich gebe zu, dass ist etwas unglücklich und lässt sich sicher irgendwie vermeiden, nur habe ich es bei der Komplexität des DOIFs bislang einfach übersehen.
Die erste Kondition hat ein 300s-wait, so dass das DOIF pausiert. Die zweite getroffene Kondition wird ebenfalls nicht ausgeführt, obwohl sie ein 0s-wait hat.
Nach ca. 20 Sekunden ändert sich eine Bedingung der ersten Kondition, so dass diese nun abgebrochen wird. Das klappt auch, zumindest wird die entsprechende Aktion zu keinem Zeitpunkt ausgeführt.

ABER: Pünktlich 300 Sekunden nach dem ursprünglichen Triggern wird nun die Aktion der zweiten getroffenen Kondition ausgeführt, deren wait mit 0 definiert ist.

In diesem Szenario mit zwei Instanzen eines DOIFs in der Queue scheint mir irgendwie die zweite Instanz den wait-Intervall der ersten zu "erben"?

[Damian]

Ich habe gerade ein sonderbares Verhalten in Kombination mit dem wait-Attribut festgestellt.

Ich habe ein etwas komplexeres DOIF mit fünf DOELSEIFs, also sechs Konditionen und sechs Aktionen. Dazu gehört:

Code Auswählen Erweitern

attr MeinDOIF wait 300:0:0:0:300:0

Nun passiert folgendes: Zwei verschiedene Konditionen des DOIFs werden praktisch zeitgleich durch zwei verschiedene Readings getriggert und beide Konditionen sind insgesamt wahr. Ich gebe zu, dass ist etwas unglücklich und lässt sich sicher irgendwie vermeiden, nur habe ich es bei der Komplexität des DOIFs bislang einfach übersehen.
Die erste Kondition hat ein 300s-wait, so dass das DOIF pausiert. Die zweite getroffene Kondition wird ebenfalls nicht ausgeführt, obwohl sie ein 0s-wait hat.
Nach ca. 20 Sekunden ändert sich eine Bedingung der ersten Kondition, so dass diese nun abgebrochen wird. Das klappt auch, zumindest wird die entsprechende Aktion zu keinem Zeitpunkt ausgeführt.

ABER: Pünktlich 300 Sekunden nach dem ursprünglichen Triggern wird nun die Aktion der zweiten getroffenen Kondition ausgeführt, deren wait mit 0 definiert ist.

In diesem Szenario mit zwei Instanzen eines DOIFs in der Queue scheint mir irgendwie die zweite Instanz den wait-Intervall der ersten zu "erben"?

Wenn du es reproduzieren kannst, dann kann ich da mal schauen. Prinzipiell, gibt es zu einem Zeitpunkt immer nur einen Wait-Timer.
Dieser kann gesetzt sein oder nicht. Wenn während der Wartezeit eine andere Bedingung zuschlägt, dann wird der wartende Timer gelöscht. Wenn bei der jeweiligen Bedingung ein Timer gesetzt wurde, dann wird wieder ein Timer gesetzt. Mehr Logik steckt da nicht dahinter. Es gibt keine mehreren Timer, die sich irgendwie beeinflussen könnten.

Gruß

Damian

[Brockmann]

Wenn du es reproduzieren kannst, dann kann ich da mal schauen. Prinzipiell, gibt es zu einem Zeitpunkt immer nur einen Wait-Timer.

Ich versuche mal ein leicht reproduzierbares Beispiel.

Folgendes DOIF:

Code Auswählen Erweitern

define DI_test DOIF ([Datastore:test1] eq "test")(trigger global test1)
DOELSEIF ([Datastore:test2] eq "test")(trigger global test2)
attr DI_test wait 20:0


Dazu irgendein Dummy (im Beispiel Datastore) mit den Readings test1 und test2.

Dann den Befehl
setReading Datastore test1 test;setReading Datastore test2 test

Man kann die beiden Befehle auch nacheinander abschicken. Solange der zweite innerhalb des wait-Intervalls vom ersten erfolgt wird er (vorläufig) ignoriert.

Schickt man dann innerhalb des definierten wait-Intervalls (im Beispiel 20 Sekunden) hinterher
setReading Datastore test1 wasauchimmer
und macht so die erste Kondition nachträglich unwahr, wird plötzlich die Aktion der zweiten Kondition ausgeführt.

Die Events sehen dann beispielsweise so aus:

Code Auswählen Erweitern

2014-12-08 17:28:38 DOIF DI_test wait_timer: 08.12.2014 17:28:58 cmd_1 Datastore
2014-12-08 17:28:38 dummy Datastore test1: test
2014-12-08 17:28:38 dummy Datastore test2: test
2014-12-08 17:28:46 DOIF DI_test wait_timer: no timer
2014-12-08 17:28:46 Global global test2
2014-12-08 17:28:46 DOIF DI_test cmd_nr: 2
2014-12-08 17:28:46 DOIF DI_test cmd_event: Datastore
2014-12-08 17:28:46 DOIF DI_test cmd_2
2014-12-08 17:28:46 dummy Datastore test1: bla
2014-12-08 17:29:00 CUL_HM CUL_HM_HM_CC_TC_201407_Climate 0

Um 17:28:46 habe ich das setReading Datastore test1 bla hinterhergeschickt und dadurch die erste (verzögerte) Kondition unwahr werden lassen. In dem Moment wird dann die Aktion der zweiten Kondition ausgeführt (Global global test2).

Kannst Du das nachvollziehen?

[Damian]

Ich versuche mal ein leicht reproduzierbares Beispiel.

Folgendes DOIF:

Code Auswählen Erweitern

define DI_test DOIF ([Datastore:test1] eq "test")(trigger global test1)
DOELSEIF ([Datastore:test2] eq "test")(trigger global test2)
attr DI_test wait 20:0


Dazu irgendein Dummy (im Beispiel Datastore) mit den Readings test1 und test2.

Dann den Befehl
setReading Datastore test1 test;setReading Datastore test2 test

Man kann die beiden Befehle auch nacheinander abschicken. Solange der zweite innerhalb des wait-Intervalls vom ersten erfolgt wird er (vorläufig) ignoriert.

Schickt man dann innerhalb des definierten wait-Intervalls (im Beispiel 20 Sekunden) hinterher
setReading Datastore test1 wasauchimmer
und macht so die erste Kondition nachträglich unwahr, wird plötzlich die Aktion der zweiten Kondition ausgeführt.

Die Events sehen dann beispielsweise so aus:

Code Auswählen Erweitern

2014-12-08 17:28:38 DOIF DI_test wait_timer: 08.12.2014 17:28:58 cmd_1 Datastore
2014-12-08 17:28:38 dummy Datastore test1: test
2014-12-08 17:28:38 dummy Datastore test2: test
2014-12-08 17:28:46 DOIF DI_test wait_timer: no timer
2014-12-08 17:28:46 Global global test2
2014-12-08 17:28:46 DOIF DI_test cmd_nr: 2
2014-12-08 17:28:46 DOIF DI_test cmd_event: Datastore
2014-12-08 17:28:46 DOIF DI_test cmd_2
2014-12-08 17:28:46 dummy Datastore test1: bla
2014-12-08 17:29:00 CUL_HM CUL_HM_HM_CC_TC_201407_Climate 0

Um 17:28:46 habe ich das setReading Datastore test1 bla hinterhergeschickt und dadurch die erste (verzögerte) Kondition unwahr werden lassen. In dem Moment wird dann die Aktion der zweiten Kondition ausgeführt (Global global test2).

Kannst Du das nachvollziehen?

Ja, es verhält sich so wie programmiert. Das Problem ist, dass das Modul immer getriggert wird, wenn sich irgendetwas im devices ändert. Da bei dir beide Readings im gleichen Device stecken, wird durch "setReading Datastore test1 bla" eben auch die zweite Bedingung wegen Datastore getriggert und wenn sie wahr ist wird das Kommando ausgeführt.

Das Problem kannst du entzerren, wenn du verschiedene Devices nimmst.

Dieses Problem war insb. hier schon mal beim HM-Bewegungsmelder aufgefallen.

Das Modul bekommt das Device und das Event beim Trigger von FHEM übergeben. Es wird leider kein Reading explizit übergeben, es ist ein Bestandteil des Events und ist leider nicht immer eindeutig zu erkennen. Ich werde mir da noch etwas für die nächste Version einfallen müssen.

Gruß

Damian

[Gisbert]

Ich möchte, mit DOIF einen Schaltvorgang zwischen 2 Zeitpunkten ablaufen lassen. Dies läuft auch solange gut, solange beide Zeitpunkte in der Zukunft liegen. Liegt der linke Zeitpunkt vermeintlich in der Vergangenheit, wird als Zeitpunkt die Uhrzeit am folgenden Tag herangezogen. Damit ist Zeitabfrage natürlich nicht mehr möglich, da diese Bedingung nie erfüllt werden kann. Dasgleiche passiert auch bei Benutzung von sunrise_abs oder sunset_abs, die ich eigentlich lieber benutzt hätte.

Meine Frage: Wie schaffe ich es, dass sich die Zeitangaben auf den aktuellen Tag beziehen und nicht auf den nächsten Tag, sobald der Zeitpunkt in der Vergangenheit liegt?

Mein Code (sorry, dass ich dass nicht so schön einstellen kann, wie die anderen Forenmitglieder):

define Haustuer.Licht.AUS DOIF ([Haustuer.Licht] eq "on" and [Schalter.1] eq "on") (set Haustuer.Licht off) DOELSEIF ([08:20-16:40] and [Haustuer.Licht] eq "on") (set Haustuer.Licht off) DOELSEIF ([23:15-06:40] and [Haustuer.Licht] eq "on") (set Haustuer.Licht off)
attr Haustuer.Licht.AUS do always
attr Haustuer.Licht.AUS wait 150:10:270

[Gisbert]

Ich möchte, mit DOIF einen Schaltvorgang zwischen 2 Zeitpunkten ablaufen lassen. Dies läuft auch solange gut, solange beide Zeitpunkte in der Zukunft liegen. Liegt der linke Zeitpunkt vermeintlich in der Vergangenheit, wird als Zeitpunkt die Uhrzeit am folgenden Tag herangezogen. Damit ist Zeitabfrage natürlich nicht mehr möglich, da diese Bedingung nie erfüllt werden kann. Dasgleiche passiert auch bei Benutzung von sunrise_abs oder sunset_abs, die ich eigentlich lieber benutzt hätte.

Meine Frage: Wie schaffe ich es, dass sich die Zeitangaben auf den aktuellen Tag beziehen und nicht auf den nächsten Tag, sobald der Zeitpunkt in der Vergangenheit liegt?

Mein Code (sorry, dass ich dass nicht so schön einstellen kann, wie die anderen Forenmitglieder):

define Haustuer.Licht.AUS DOIF ([Haustuer.Licht] eq "on" and [Schalter.1] eq "on") (set Haustuer.Licht off) DOELSEIF ([08:20-16:40] and [Haustuer.Licht] eq "on") (set Haustuer.Licht off) DOELSEIF ([23:15-06:40] and [Haustuer.Licht] eq "on") (set Haustuer.Licht off)
attr Haustuer.Licht.AUS do always
attr Haustuer.Licht.AUS wait 150:10:270

[Brockmann]

Moin,

Ja, es verhält sich so wie programmiert. Das Problem ist, dass das Modul immer getriggert wird, wenn sich irgendetwas im devices ändert. Da bei dir beide Readings im gleichen Device stecken, wird durch "setReading Datastore test1 bla" eben auch die zweite Bedingung wegen Datastore getriggert und wenn sie wahr ist wird das Kommando ausgeführt.

OK, das ist schon mal eine wichtige Erkenntnis. War mir bislang entgangen.

Das ist aber nur das halbe Problem. Denn mich stört ebenso, dass beim
setReading Datastore test1 test;setReading Datastore test2 test
das zweite setReading bzw. die dazu gehörende Kondition<>Aktion im DOIF komplett ignoriert wird. Denn das würde bedeuten, dass man bei Verwendung des wait-Attributs innerhalb eines DOIFs nur Konditionen haben darf, die in einem exklusiven Oder-Verhältnis stehen. Andernfalls bestünde die Gefahr, dass das DOIF wie in diesem Beispiel unter Umständen nicht reagiert, wenn es reagieren sollte.

Nun gebe ich zu, dass alleine schon DOELSEIF ein Exklusiv-Oder impliziert, aber ich war irgendwie davon ausgegangen, dass DOIF sich in dieser Hinsicht etwas toleranter verhalten würde.

[Damian]

Moin,
OK, das ist schon mal eine wichtige Erkenntnis. War mir bislang entgangen.

Das ist aber nur das halbe Problem. Denn mich stört ebenso, dass beim
setReading Datastore test1 test;setReading Datastore test2 test
das zweite setReading bzw. die dazu gehörende Kondition<>Aktion im DOIF komplett ignoriert wird. Denn das würde bedeuten, dass man bei Verwendung des wait-Attributs innerhalb eines DOIFs nur Konditionen haben darf, die in einem exklusiven Oder-Verhältnis stehen. Andernfalls bestünde die Gefahr, dass das DOIF wie in diesem Beispiel unter Umständen nicht reagiert, wenn es reagieren sollte.

Nun gebe ich zu, dass alleine schon DOELSEIF ein Exklusiv-Oder impliziert, aber ich war irgendwie davon ausgegangen, dass DOIF sich in dieser Hinsicht etwas toleranter verhalten würde.

Ich weiß nicht ob ich dich richtig verstanden habe, aber ob wait oder nicht wait, das Abarbeiten der Bedingungen ist immer gleich.

Naja, DOIF habe ich bewusst dem if-then-else-elseif Konstrukt in höheren Sprachen nachgebildet und genau so verhält sich auch dieses Modul. Zitat aus der Commandref: "Die Angaben werden immer von links nach rechts abgearbeitet. Es wird immer nur ein Kommando ausgeführt, und zwar das erste, für das die dazugehörige Bedingung in der abgearbeiteten Reihenfolge wahr ist. Hinzu kommt, dass nur die Bedingungen überprüft werden, die zum ausgelösten Event auch ein Device beinhalten (Angaben in eckigen Klammern)."
 
Natürlich hätte man es auch anders programmieren können, aber dann wären Missverständnisse vorprogrammiert, denn nicht wenige FHEM-User können auch programmieren und denen sind solche if-Konstrukten vertraut.

Gruß

Damian

[Spartacus]

Problem gefixed und eingecheckt. Korrektur ab morgen per FHEM-Update.

Gruß

Damian

Hallo Damian,
danke für den schnellen Support. Habe gestern das Update gemacht und alles läuft, wie es soll!
Gruß,
Christian

[chriz]

Danke für dieses tolle Modul!

Ich versuche momentan einige Notifies auf DOIF umzustellen, wie z.B. das Notify meiner 4 Fernbedienungen:

Code Auswählen Erweitern


define act_on_Taste1 notify (RC1_TASTE1:Long.1-.*|RC2_TASTE1:Long.1-.*|RC3_TASTE1:Long.1-.*|RC4_TASTE1:Long.1-.*) set USW2_GANG on-for-timer 1



Kann ich stattdessen Folgendes für DOIF verwenden, oder muss ich ggf. etwas ändern?

Code Auswählen Erweitern


define DI_act_on_Taste1 DOIF ([RC1_TASTE1] =~ "Long.1-")|([RC2_TASTE1] =~ "Long.1-")|([RC3_TASTE1] =~ "Long.1-")|([RC4_TASTE1] =~ "Long.1-") (set USW2_GANG on-for-timer 1)



Danke
Chris

[Brockmann]

Ich weiß nicht ob ich dich richtig verstanden habe, aber ob wait oder nicht wait, das Abarbeiten der Bedingungen ist immer gleich.

Nee, wir reden noch so ein bißchen aneinander vorbei, aber das liegt auch an mir. Ich kämpfe noch etwas mit dem Verständnis.

Können wir uns auf folgende Aussage einigen?
"Ein laufender wait-Timer aus einer Kondition1 wird abgebrochen, wenn eine andere Kondition2 desselben DOIFs getriggert wird und wahr ist, auch wenn die Kondition1, die den wait-Timer ursprünglich ausgelöst hat, zu diesem Zeitpunkt immer noch wahr ist."

Beispiel:

Code Auswählen Erweitern


define DI_test DOIF ([test1] eq "test")(trigger global test1)
DOELSEIF ([test2] eq "test")(trigger global test2)
attr DOIF wait 20:0


test1 und test2 sind jeweils Dummys.
set test1,test2 test => Die Aktion trigger global test2 wird sofort ausgeführt, trigger global test1 gar nicht.
set test2,test1 test => Die Aktion trigger global test2 wird sofort ausgeführt, trigger global test1 20 Sekunden später.

Ist das so korrekt?

Wohlgemerkt: Ich will gar nicht darauf hinaus, dass hier ein "Fehler" in DOIF vorliegen würde. Ich halte es nur für eine Beschränkung, bei der man darüber diskutieren kann, ob sie notwendig, sinnvoll oder unvermeidlich ist.