neues Modul DOIF

[Brockmann]

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)


eher so:

Code Auswählen Erweitern


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


[Damian]

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.

Es ist alles so, wie du es beschreibst. Im ersten Fall wird der Timer zum Ausführen des ersten Kommandos gesetzt und durch das Eintreffen der zweiten des Triggers der zweiten Bedingung unterbrochen und das zweite Kommando wird ausgeführt.

Im zweiten Fall wird zuerst die zweite Bedingung getrigger und ausgeführt, da kein Waittimer definiert ist, dann folgt der zweite Trigger der ersten Bedingung und führt zur Ausführung des ersten Kommandos nach 20 Sekunden, wenn er nicht unterbrochen wird, wie z. B im ersten Beispiel.

Auch wenn die erste Bedingung wahr ist, ist sie durch den zweiten Trigger nicht mehr aktuell. Genau so wäre es auch ohne Wait, nur da hätte das erste Kommando bereits geschaltet. Wichtig ist natürlich noch der Zusatz aus der Commandref:"... Hinzu kommt, dass nur die Bedingungen überprüft werden, die zum ausgelösten Event auch ein Device beinhalten (Angaben in eckigen Klammern)." Heißt hier, wenn der Trigger zum Device der zweiten Bedingung kommt, wird die erste Bedingung nicht ausgewertet, weil dort ein anderes Devices angegeben ist.

Für mich heißt das, jede andere Verhalten des Moduls entspreche nicht dem, was in der Commandref steht.

Du kannst mir gerne ein konkretes Beispiel nennen, was sich so verhält, wie du es für sinnvoll erachtest, ohne, dass es im Widerspruch zur Commandref des Moduls steht.

Gruß

Damian

[Spartacus]

Hallo,
ich habe eine Frage zur Zeitsteuerung in Verbindung mit DOIF
in der commandRef steht:

Code Auswählen Erweitern

Nur am Wochenende bzw. an Feiertagen lt. holiday-Datei (7 entspricht $we):
define di_radio DOIF ([08:00-10:00|7]) (set radio on) DOELSE (set radio off)
Nur an Arbeitstagen (8 ist das Gegenteil von 7, entspricht !$we):
define di_radio DOIF ([08:00-10:00|8]) (set radio on) DOELSE (set radio off)

bedeutet dies, dass "7" und "8" bzw. die Variable $we und !$we) automatisch für alle Feiertage in der holiday Datei gesetzt wird, oder muss man da noch irgendetwas in fhem konfiguriren. zumindest muss doch das holiday Modul geladen sein, oder?

Christian

[Damian]

Hallo,
ich habe eine Frage zur Zeitsteuerung in Verbindung mit DOIF
in der commandRef steht:

Code Auswählen Erweitern

Nur am Wochenende bzw. an Feiertagen lt. holiday-Datei (7 entspricht $we):
define di_radio DOIF ([08:00-10:00|7]) (set radio on) DOELSE (set radio off)
Nur an Arbeitstagen (8 ist das Gegenteil von 7, entspricht !$we):
define di_radio DOIF ([08:00-10:00|8]) (set radio on) DOELSE (set radio off)

bedeutet dies, dass "7" und "8" bzw. die Variable $we und !$we) automatisch für alle Feiertage in der holiday Datei gesetzt wird, oder muss man da noch irgendetwas in fhem konfiguriren. zumindest muss doch das holiday Modul geladen sein, oder?

Christian

Du musst unter Global das Attribut holiday2we auf deine holiday-Datei setzen. Bei mir steht da holidy2we nrw. Damit wird $we nicht nur am Wochenende wahr, sondern auch an Feiertagen. Das hat erst mal nichts mit DOIF zu tun. Da aber DOIF die Variable auswertet, gilt dann bei 7 nicht nur Wochenende, sondern auch ein Feiertag. 8 ist das Gegenteil von 7.

Gruß

Damian

[Spartacus]

Hallo,
ah! ok. Danke, dass wusste ich nicht!
Christian

[dieda]

Ich zacker gerade an so einen Ausdruck rum:

Code Auswählen Erweitern

([{sunset("REAL")}-22:35|01234]) (mach dies) DOELSE ([{sunset("REAL")}-(23:30)|56] (mach das)

Bekomme dann im Log so was:

Code Auswählen Erweitern

Error: {sunset("REAL")}-23 has no TYPE

Wo ist da der Denkfehler?

[Damian]

Ich zacker gerade an so einen Ausdruck rum:

Code Auswählen Erweitern

([{sunset("REAL")}-22:35|01234]) (mach dies) DOELSE ([{sunset("REAL")}-(23:30)|56] (mach das)

Bekomme dann im Log so was:

Code Auswählen Erweitern

Error: {sunset("REAL")}-23 has no TYPE

Wo ist da der Denkfehler?

([{sunset("REAL")}-22:35|01234]) (mach dies) DOELSE ([{sunset("REAL")}-23:30|56]) (mach das)

Du musst schon auf die korrekte Klammerung achten.

Gruß

Damian

[Brockmann]

Du kannst mir gerne ein konkretes Beispiel nennen, was sich so verhält, wie du es für sinnvoll erachtest, ohne, dass es im Widerspruch zur Commandref des Moduls steht.

Mich interessiert primär, dass ich die Funktionsweise richtig verstehe und ob es eine bewusste Design-Entscheidung war, dies so zu machen oder es vielleicht technisch auch gar nicht anders machbar ist.
Im letzteren Fall muss man halt damit leben. Im ersteren Fall würde ich die Entscheidung für unglücklich halten.

Ein Szenario, bei dem ein laufender wait-Timer abgebrochen wird, nur weil eine andere Kondition wahr wird (ohne dass die auslösende Kondition deshalb unwahr wird), ist im Grunde genommen immer ein ungewollter Seiteneffekt. Denn wenn ich WOLLTE, dass irgendein Ereignis meinen laufenden wait-Timer abbricht, dann hätte ich das entsprechende Reading von vorne herein in die Kondition einfügen sollen, die den wait-Timer startet. Dann würde diese Kondition beim Eintreffen des Ereignisses unwahr und der Timer deshalb abgebrochen.

[Damian]

Mich interessiert primär, dass ich die Funktionsweise richtig verstehe und ob es eine bewusste Design-Entscheidung war, dies so zu machen oder es vielleicht technisch auch gar nicht anders machbar ist.
Im letzteren Fall muss man halt damit leben. Im ersteren Fall würde ich die Entscheidung für unglücklich halten.

Ein Szenario, bei dem ein laufender wait-Timer abgebrochen wird, nur weil eine andere Kondition wahr wird (ohne dass die auslösende Kondition deshalb unwahr wird), ist im Grunde genommen immer ein ungewollter Seiteneffekt. Denn wenn ich WOLLTE, dass irgendein Ereignis meinen laufenden wait-Timer abbricht, dann hätte ich das entsprechende Reading von vorne herein in die Kondition einfügen sollen, die den wait-Timer startet. Dann würde diese Kondition beim Eintreffen des Ereignisses unwahr und der Timer deshalb abgebrochen.

Es war von mir eine bewusste Entscheidung wait mit Reset zu realisieren. Ich wollte in erster Linie eine Art watchdog-Funktionaltät haben. Tue etwas nach einer gewissen Zeit, wenn der Zustand sich nicht ändert. Der andere Fall tue etwas, wenn eine gewisse Zeit nichts passiert steht ja bereits auf der todo-Liste.

Ein weiteres Problem, welches z. T. sehr abenteuerlich gelöst wird, ist das Setzen von at-Timern, die man dann löschen muss, wenn sich während der Wartezeit etwas ändert und der Timer seine Bedeutung verliert. Auch dafür ist wait eine Erleichterung, weil man sich um das Löschen als Anwender nicht kümmern muss.

Möchte man dagegen den einfachen Fall haben, tue etwas auf jeden Fall nach X-Sekunden, dann braucht man nur einen at-Timer zu setzen oder sonst ein Sleep (natürlich nicht in Kombination mit DOIF). Dieser Fall ist aus meiner Sicht, aber oft wenig sinnvoll. Denn wenn ein Ereignis während der Wartezeit mehrfach vorkommt, dann habe ich mehrere Timer, die mehrfach die gleiche Aktion ausführen - wozu?

Von daher ist wait nicht mit at bzw. sleep gleichzusetzen - das war von Anfang an so von mir beabsichtigt gewesen.

Gruß

Damian

[Brockmann]

Es war von mir eine bewusste Entscheidung wait mit Reset zu realisieren. Ich wollte in erster Linie eine Art watchdog-Funktionaltät haben. Tue etwas nach einer gewissen Zeit, wenn der Zustand sich nicht ändert. Der andere Fall tue etwas, wenn eine gewisse Zeit nichts passiert steht ja bereits auf der todo-Liste.

Wir reden immer noch etwas aneinander vorbei. Ich versuche es mal, auf den Punkt zu bringen.
Du sagst:
Wenn sich bei laufendem wait-Timer der Zustand eines DOIFs ändert, muss die Kondition, die den wait-Timer gestartet hat, unwahr geworden sein. Also wird der Timer gelöscht.

Ich sage:
Wenn sich bei laufendem wait-Timer der Zustand eines DOIFs ändert, muss die Kondition, die den wait-Timer gestartet hat, nicht automatisch unwahr geworden sein. Deshalb sollte der Timer nicht gelöscht werden. Ein laufender Timer sollte nur gelöscht werden, wenn die auslösenden Kondition erneut getriggert wurde und dadurch tatsächlich unwahr geworden ist.

Möchte man dagegen den einfachen Fall haben, tue etwas auf jeden Fall nach X-Sekunden, dann braucht man nur einen at-Timer zu setzen oder sonst ein Sleep (natürlich nicht in Kombination mit DOIF). Dieser Fall ist aus meiner Sicht, aber oft wenig sinnvoll. Denn wenn ein Ereignis während der Wartezeit mehrfach vorkommt, dann habe ich mehrere Timer, die mehrfach die gleiche Aktion ausführen - wozu?

Von daher ist wait nicht mit at bzw. sleep gleichzusetzen - das war von Anfang an so von mir beabsichtigt gewesen.

Es geht mir nicht um den einfachen Fall "tue etwas nach x Sekunden". Selbstverständlich sollte ein wait-Timer gelöscht werden, wenn die Voraussetzungen dafür nicht mehr gegeben sind. Aber eben nur dann. Und dass das dazugehörige DOIF seinen Status ändert bedeutet eben - zumindest rein logisch - nicht, dass die Voraussetzungen für den Timer nicht mehr gegeben sind.

[dieda]

([{sunset("REAL")}-22:35|01234]) (mach dies) DOELSE ([{sunset("REAL")}-23:30|56]) (mach das)

Du musst schon auf die korrekte Klammerung achten.

Gruß

Damian

Da habe ich wohl einen Fehler beim Posten gemacht. Die Klammer steht da. Werde es heute Abend nochmals so durchlaufen lassen und mich dann melden.

[Damian]

Wir reden immer noch etwas aneinander vorbei. Ich versuche es mal, auf den Punkt zu bringen.
Du sagst:
Wenn sich bei laufendem wait-Timer der Zustand eines DOIFs ändert, muss die Kondition, die den wait-Timer gestartet hat, unwahr geworden sein. Also wird der Timer gelöscht.

Ich sage:
Wenn sich bei laufendem wait-Timer der Zustand eines DOIFs ändert, muss die Kondition, die den wait-Timer gestartet hat, nicht automatisch unwahr geworden sein. Deshalb sollte der Timer nicht gelöscht werden. Ein laufender Timer sollte nur gelöscht werden, wenn die auslösenden Kondition erneut getriggert wurde und dadurch tatsächlich unwahr geworden ist.

ok. Das würde aber bedeuten, dass man mehrere Timer bräuchte, denn die zweite und dritte und usw. Bedingung kann ja auch ein wait haben. Das würde einen nicht unerheblichen Verwaltungsaufwand bedeuten, da zukünftig auch noch wait´s zwischen den Kommandos dazukommen sollen. Ich möchte eigentlich die Sache möglichst einfach halten und mit einem Timer auskommen. Wenn mehrere Bedingungen bzgl. der Timer unabhängig voneinander funktionieren sollen, dann muss man sie halt in mehrere DOIFs aufteilen.

Gruß

Damian

[dieda]

Habe da noch eine weitere Frage:

Bei meinem DOIF's für einen Trockner bekomme ich solche Meldungen:

2014.12.10 16:42:55 1: PERL WARNING: Argument "1840.85 W" isn't numeric in numeric gt (>) at (eval 8682) line 1.

Anbei der passenden Screenshot des Trockners. Es handelt sich um Fritz DECT-Dosen.

Definition des DOIF

Code Auswählen Erweitern

([Trockner:power]>4) (set Trockner_betrieb on) DOELSEIF ([Trockner:power]<3) (set Trockner_betrieb off)

Code Auswählen Erweitern

Internals:
   DEF        ([Trockner:power]>4) (set Trockner_betrieb on) DOELSEIF ([Trockner:power]<3) (set Trockner_betrieb off)
   NAME       Trockner_DI
   NR         828
   NTFY_ORDER 50-Trockner_DI
   STATE      cmd_1
   TYPE       DOIF
   Readings:
     2014-12-10 16:49:55   cmd_event       Trockner
     2014-12-10 16:49:55   cmd_nr          1
     2014-12-10 16:48:55   e_Trockner_power 1883.91 W
     2014-12-10 16:49:55   state           cmd_1
     2014-12-10 16:49:55   wait_timer      no timer
   Condition:
     0          ReadingValDoIf('Trockner','power','')>4
     1          ReadingValDoIf('Trockner','power','')<3
   Devices:
     0           Trockner
     1           Trockner
     all         Trockner
   Do:
     0          set Trockner_betrieb on
     1          set Trockner_betrieb off
   Helper:
     last_timer 0
     sleepdevice Trockner
     sleeptimer -1
   Internals:
   Readings:
     0           Trockner:power
     1           Trockner:power
     all         Trockner:power
   State:
   Timerfunc:
Attributes:
   do         always
        wait       60:300

[Spartacus]

Hallo,
ich mal wieder ein Brett vorm Kopf und weiß nicht so recht, wie ich die neue Anforderung am Besten einbauen soll!

Ich habe hier wieder mein DOIF welches meine Eingangsbeleuchtung in Abhängigkeit des Reedkontakts an der Haustür und der Lichschranke in der Zuwegung steuert. Silverster wird dann für 2h auf Dauerlich geschaltet. Das funzt soweit auch ganz gut.

Code Auswählen Erweitern

define di.02.EI.ss.SA.Licht DOIF ((([EG.ss.TK.Haustuer:buttons] eq "pressed") or \
   [EG.ss.LS.Eingang:buttons] eq "pressed") and [tw.01.Daemmerung:twilight] <55 or \
   [00:00-02:00] and [hl.01.Feiertag:state] eq "Silvester")\
   (set EI.ss.SA.Licht on)\
DOELSEIF\
(([EG.ss.TK.Haustuer:buttons] eq "released" or \
   [EG.ss.LS.Eingang:buttons] eq "released") and [hl.01.Feiertag:state] ne "Silvester" )\
   (set EI.ss.SA.Licht off)\
DOELSEIF \
  ([Notaus] eq "on" and [hl.01.Feiertag:state] ne "Silvester")
attr di.02.EI.ss.SA.Licht alias autom. Eingangslicht
attr di.02.EI.ss.SA.Licht cmdState on|off|off
attr di.02.EI.ss.SA.Licht disable 0
attr di.02.EI.ss.SA.Licht room 05-Eingang
attr di.02.EI.ss.SA.Licht wait 0:120:0
#
#
# Email senden, wenn Tür länger als 10min auf steht
#
define di.03.EI.ss.SA.Licht DOIF ([EG.ss.TK.Haustuer:buttons] eq "pressed") ({eMail('muster@mann.de','Warnung','Haustür steht offen')}, \
set EI.ss.SA.Licht off, set Notaus on)\

attr di.03.EI.ss.SA.Licht alias Warnung Eingang
attr di.03.EI.ss.SA.Licht cmdState active
attr di.03.EI.ss.SA.Licht room 05-Eingang
attr di.03.EI.ss.SA.Licht wait 600

Nun habe ich neuerdings einen Taster im Innenbereich, der unabhängig vom DOIF das Licht ein/aus schalten soll, bzw. ein Langdruck schaltet das Licht für 60min ein.
Das sieht so aus:

Code Auswählen Erweitern

#kurzer Druck:
seq.01.EG.fl.WS.Eingangslicht:trigger set EI.ss.SA.Licht toggle
#langer Druck:
seq.01.EG.fl.WS.Eingangslicht:partial_1 set EI.ss.SA.Licht on-for-timer 3600

Funktioniert auch, allerdings:
Ist die Beleuchtung durch Türkontakt oder LS in der Ausschaltverzögerung, kann ich mit dem kurzen Tastendruck zwar das Licht ausschalten, aber das DOIF bekommt nichts davon mit. D.h. Wenn ich jetzt bei ausgeschaltetem Licht, die Haustür öffne, bzw. durch die LS gehe, passiert nichts, da für das DOIF die Lampe noch an ist.

Andersherum schaltet das Licht nach der Auschaltverzögerung des DOIFs ab, wenn es durch den Taster auf "Dauerlicht" geschaltet wurde und dann jemand durch die LS geht und damit das DOIF aktiviert.

Wie muss ich das jetzt machen? Muss das alles in das DOIF, aber wie kann ich dann das "toggle" des Tasters verarbeiten!
Oder kann man das DOIF einfach "resetten" und "disablen", wenn der Taster betätigt wird! Brauche hier mal einen Tipp in welche Richtung man hier gehen sollte.
Gruß,
Christian

[micomat]

Hallo

kann ich mit DOIF auch eine Aktion ausfuehren, wenn sich ein Wert beispielsweise fuer 30minuten nicht aktualisiert hat?

Sorry falls das schon mal im Thread geklaert wurde, aber 60 Seiten kann man nicht mehr in einem angemessenen Zeitraum durcharbeiten
Bin gerne bereit, sollte es gehen, das als Beispiel mit in den WIKI Artikel zu schreiben.

Gruß
Markus