neues Modul DOIF

[Gisbert]

Hallo,

ich habe immer noch das Problem, dass die Zeitangsben sich nicht auf den gleichen Tag beziehen, sondern auf den nächsten, wenn eine Schranke bereits in der Vergangenheit liegt. Ich hatte zunächst 3 Befehle mit doelseif gekoppelt. Der Versuch es mit drei einzelnen doif's zu versuchen, brachte das gleiche falsche Ergebnis.

Mit list habe ich den Befehl ausgelesen. Anstatt von 8:20 bis 16:40 das Haustürlicht auszuschalten, falls jemand den Taster unbeabsichtigt betätigt hat, wird die Zeit 8:20 vom Folgetag herangezogen, womit der Befehl ins Gegenteil verkehrt wird.

Internals:
   DEF        ([08:20-16:40] and [Haustuer.Licht] eq "on") (set Haustuer.Licht off)
   NAME       Haustuer.Licht.AUS2
   NR         105
   NTFY_ORDER 50-Haustuer.Licht.AUS2
   STATE      cmd_2
   TYPE       DOIF
   Readings:
     2014-12-11 08:20:00   cmd_event       timer_1
     2014-12-11 08:20:00   cmd_nr          2
     2014-12-11 08:05:45   e_Haustuer.Licht_STATE off
     2014-12-11 08:20:00   state           cmd_2
     2014-12-11 08:20:00   timer_1_c1      12.12.2014 08:20:00
     2014-12-10 16:40:00   timer_2_c1      11.12.2014 16:40:00
     2014-12-09 21:55:34   wait_timer      no timer
   Condition:
     0          DOIF_time($hash->{realtime}{0},$hash->{realtime}{1},$wday,$hms,"") and InternalDoIf('Haustuer.Licht','STATE','') eq "on"
   Days:
   Devices:
     0           Haustuer.Licht
     all         Haustuer.Licht
   Do:
     0          set Haustuer.Licht off
   Helper:
     last_timer 2
     sleeptimer -1
   Internals:
     0           Haustuer.Licht:STATE
     all         Haustuer.Licht:STATE
   Readings:
   Realtime:
     0          08:20:00
     1          16:40:00
   State:
   Time:
     0          08:20:00
     1          16:40:00
   Timecond:
     0          0
     1          0
   Timer:
     0          0
     1          0
   Timerfunc:
   Timers:
     0           0  1
Attributes:
   do         always
   wait       10

[Brockmann]

Ich habe mein ursprüngliches Problem für die Diskussion der letzten Tage nun etwas weiter analysieren können und dabei die eigentliche Ursache für die gelegentlichen "Fehlfunktionen" erkannt. Allerdings kann ich mir das Verhalten auch mit den neuen Erkenntnissen bzgl. wait-Timern nicht erklären. Ich habe es mal in einem Beispiel vereinfacht:

Code Auswählen Erweitern


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


Ich setze test2 auf "test", test1 steht in dem Moment auf "ja". Damit treffe ich die erste Kondition und der wait-Timer startet. Soweit klar.
Die zweite Kondition würde auch passen, aber da die erste schon traf, sollte die zweite in dem Fall ja ignoriert werden, oder?
Während der wait-Timer läuft, setze ich test1 auf "nein". Damit wird die erste Kondition unwahr. Nun sollte der Timer abgebrochen und die Aktion nicht ausgeführt werden.
Nach meinem Verständnis sollte an der Stelle Schluss sein.

ABER: Pünktlich 20 Sekunden nach dem ursprünglichen Triggern der ersten Kondition wird die Aktion der zweiten Kondition ausgeführt?

Event-Monitor:

Code Auswählen Erweitern


2014-12-10 10:51:40 DOIF DI_test wait_timer: 10.12.2014 10:52:00 cmd_1 test2
2014-12-10 10:51:40 dummy test2 test
2014-12-10 10:51:46 dummy test1 nein
2014-12-10 10:52:00 Global global test2
2014-12-10 10:52:00 DOIF DI_test cmd_nr: 2
2014-12-10 10:52:00 DOIF DI_test cmd_event: test2
2014-12-10 10:52:00 DOIF DI_test cmd_2
2014-12-10 10:52:00 DOIF DI_test wait_timer: no timer


[Brockmann]

ich habe immer noch das Problem, dass die Zeitangsben sich nicht auf den gleichen Tag beziehen, sondern auf den nächsten, wenn eine Schranke bereits in der Vergangenheit liegt. Ich hatte zunächst 3 Befehle mit doelseif gekoppelt. Der Versuch es mit drei einzelnen doif's zu versuchen, brachte das gleiche falsche Ergebnis.

Was ist genau das Problem? Willst Du sagen, wenn jemand das Licht nach 16:40 anschaltet, dass es dann wieder ausgeschaltet wird? Kann ich mir nicht vorstellen.
Oder stört Dich der interne Timer?

Code Auswählen Erweitern

  2014-12-11 08:20:00   timer_1_c1      12.12.2014 08:20:00
Dass der am Folgetag liegt, ist aber logisch. Einen Timer für einen Zeitpunkt in der Vergangenheit zu definieren, wäre doch völlig sinnlos.
Außerdem besagt dieser Timer nur, dass das DOIF zu diesem Zeitpunkt einmal getriggert wird, um zu testen, ob die Bedingungen erfüllt sind oder nicht. Schließlich hast Du definiert, dass das Licht ab 8:20 Uhr ausgeschaltet werden soll, falls es an ist. Wenn es also um 8:20 Uhr noch an ist, soll es zu diesem Zeitpunkt ausgeschaltet werden. Und genau dafür sorgt dieser Timer.

[Gisbert]

Hallo Brockmann,

vielen Dank für deine Antwort. Ist es dann so, dass nur um wie in meinem Fall nur 8:20 geprüft wird, ob das Licht an ist? Wenn es zwischendurch durch den Taster eingeschaltet wird, wird dann nicht mehr geprüft? Was für einen Sinn hat dann die 2. Zeitschranke? In der Commandref hab ich es so verstanden, dass innerhalb des Zeitraums geprüft wird.

Was kann ich denn stattdessen tun, um mein Vorhaben zu realisieren.

Gisbert

[Brockmann]

vielen Dank für deine Antwort. Ist es dann so, dass nur um wie in meinem Fall nur 8:20 geprüft wird, ob das Licht an ist? Wenn es zwischendurch durch den Taster eingeschaltet wird, wird dann nicht mehr geprüft? Was für einen Sinn hat dann die 2. Zeitschranke? In der Commandref hab ich es so verstanden, dass innerhalb des Zeitraums geprüft wird.

Code Auswählen Erweitern

DEF        ([08:20-16:40] and [Haustuer.Licht] eq "on") (set Haustuer.Licht off)
Dieses DOIF wird angestossen

• um 8:20 (Beginn des Zeitraums)
• um 16:40 (Ende des Zeitraums)
• jedes Mal, wenn sich der Status des Device Haustuer.Licht verändert

Wenn ich richtig verstehe, was Du erreichen willst, dann ist Deine Definition genau richtig. Deshalb ja auch meine Frage, was das Problem ist bzw. was daran in der Praxis nicht funktioniert.

[Spartacus]

Ich habe mein ursprüngliches Problem für die Diskussion der letzten Tage nun etwas weiter analysieren können und dabei die eigentliche Ursache für die gelegentlichen "Fehlfunktionen" erkannt. Allerdings kann ich mir das Verhalten auch mit den neuen Erkenntnissen bzgl. wait-Timern nicht erklären. Ich habe es mal in einem Beispiel vereinfacht:

Code Auswählen Erweitern


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


Ich setze test2 auf "test", test1 steht in dem Moment auf "ja". Damit treffe ich die erste Kondition und der wait-Timer startet. Soweit klar.
Die zweite Kondition würde auch passen, aber da die erste schon traf, sollte die zweite in dem Fall ja ignoriert werden, oder?
Während der wait-Timer läuft, setze ich test1 auf "nein". Damit wird die erste Kondition unwahr. Nun sollte der Timer abgebrochen und die Aktion nicht ausgeführt werden.
Nach meinem Verständnis sollte an der Stelle Schluss sein.

ABER: Pünktlich 20 Sekunden nach dem ursprünglichen Triggern der ersten Kondition wird die Aktion der zweiten Kondition ausgeführt?

Event-Monitor:

Code Auswählen Erweitern


2014-12-10 10:51:40 DOIF DI_test wait_timer: 10.12.2014 10:52:00 cmd_1 test2
2014-12-10 10:51:40 dummy test2 test
2014-12-10 10:51:46 dummy test1 nein
2014-12-10 10:52:00 Global global test2
2014-12-10 10:52:00 DOIF DI_test cmd_nr: 2
2014-12-10 10:52:00 DOIF DI_test cmd_event: test2
2014-12-10 10:52:00 DOIF DI_test cmd_2
2014-12-10 10:52:00 DOIF DI_test wait_timer: no timer


Hallo Brockmann,
wenn ich  Dein Beispiel/Problem richtig verstehe, trifft das genau den Kern meines Problems, welches ich ein paar Posts zuvor (10.12.14, 18:46:01) geschildert habe.

Wenn ich das Verhalten des DOIFs auf meine Steuerung übertrage, dann würde der Timer der Ausschaltverzögerung nicht  zurückgesetzt, wenn die Lampe durch den Tastendruck der Sequence ausgeschaltet wird. Das heißt, das Wiedereinschalten der Beleuchtung durch die Lichtschranke/Türkontakt ist frühestens nach Ablauf des Timers möglich....

Ist das so? Oder habe ich es falsch verstanden?
Spartacus.

[dieda]

Ich schubse mal meinen Beitrag: http://forum.fhem.de/index.php/topic,23833.msg228914.html#msg228914

Vlt. hat jemand ja eine Lösung. Mein Log ist imo total vollgemüllt und ich habe Verbose auf 0 stehen.

[automatisierer]

@dieda
in der commandref unter DOIF - Filtern nach Zahlen. Steht das du hinter das Reading noch ein :d

Code Auswählen Erweitern


[device:reading:d] 

machen musst um die zahlen werte von buchstaben zu befreien. damit sollte dein problem gelöst sein.
Gruß Ingo

[dieda]

Danke.

[Damian]

Ich habe mein ursprüngliches Problem für die Diskussion der letzten Tage nun etwas weiter analysieren können und dabei die eigentliche Ursache für die gelegentlichen "Fehlfunktionen" erkannt. Allerdings kann ich mir das Verhalten auch mit den neuen Erkenntnissen bzgl. wait-Timern nicht erklären. Ich habe es mal in einem Beispiel vereinfacht:

Code Auswählen Erweitern


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


Ich setze test2 auf "test", test1 steht in dem Moment auf "ja". Damit treffe ich die erste Kondition und der wait-Timer startet. Soweit klar.
Die zweite Kondition würde auch passen, aber da die erste schon traf, sollte die zweite in dem Fall ja ignoriert werden, oder?
Während der wait-Timer läuft, setze ich test1 auf "nein". Damit wird die erste Kondition unwahr. Nun sollte der Timer abgebrochen und die Aktion nicht ausgeführt werden.
Nach meinem Verständnis sollte an der Stelle Schluss sein.

ABER: Pünktlich 20 Sekunden nach dem ursprünglichen Triggern der ersten Kondition wird die Aktion der zweiten Kondition ausgeführt?

Die Programmierung ist ganz einfach: ein laufender Timer wird nur dann zurückgesetzt, wenn ein anders Kommando ausgeführt werden soll bzw. ein Timer für dieses Kommando gestartet wird (wenn ein wait für dieses Kommando definiert ist), also wenn der Zustand cmd_x auf cmd_y wechsel oder timerbedingt später wechseln soll. Das gilt auch, wenn es nur einen If-Fall gibt, hier gibt es nämlich auch den Zustand cmd_2.

Gruß

Damian

[Gisbert]

Hallo Brockmann,
meine Haustuer.Licht-Schaltung funktioniert jetzt wie gewünscht. Wahrscheinlich hat sie schon die ganze Zeit richtig funktioniert, wie du gesagt hast. Ich habe vermutlich beim Testen etwas falsch gemacht, als ich andere Zeiten genutzt habe. Der doif-Befehl geht auch mit sunrise und sunset, so dass jetzt bei Tageslicht fie Lampe ausgeschaltet wird, falls sie jemand aus Versehen am Taster eingeschaltet hat.
Vielen Dank für deine Erklärung und deine Geduld.
Gisbert

[Brockmann]

Die Programmierung ist ganz einfach: ein laufender Timer wird nur dann zurückgesetzt, wenn ein anders Kommando ausgeführt werden soll bzw. ein Timer für dieses Kommando gestartet wird (wenn ein wait für dieses Kommando definiert ist), also wenn der Zustand cmd_x auf cmd_y wechsel oder timerbedingt später wechseln soll. Das gilt auch, wenn es nur einen If-Fall gibt, hier gibt es nämlich auch den Zustand cmd_2.

Die Verwirrung lichtet sich. Ich denke, der Grund für das (für mich) unerwartete Verhalten ist letztlich folgender (und das war mir bislang so nicht klar):

Wenn ich ein DOIF mit mehreren Konditionen aber ohne DOELSE definiere, kann dieses DOIF letztlich nicht den Fall abbilden, dass keine der Konditionen wahr ist. Es bleibt dann einfach in dem letzten Status, auch wenn die Bedingungen dafür nicht mehr zutreffen. Im "normalen" Betrieb fälllt das nicht weiter auf, obwohl es auch da Implikationen hat. Aber wenn man mit wait operiert, kann es zu verschiedenen Seiteneffekten führen.

Wohlgemerkt: Ich will damit nicht sagen, dass das ein "Fehler" von DOIF wäre. Man kann in dieser Situation grundsätzlich auf (mindestens) zwei Arten reagieren und beide haben Vor- und Nachteile.

Meine Konsequenz ist, dass ich bei DOIFs mit wait-Timer in Zukunft wohl grundsätzlich ein (ggf. leeres) DOELSE ans Ende setzen werde, denn das sollte diese Seiteneffekte vermeiden. Wenn eine Bedingung unwahr wird, verzweigt das DOIF in den ELSE-Fall und der Status ändert sich dementsprechend, so dass der Timer abgebrochen werden sollte.

[sam50]

Hallo Zusammen.
Ich bin voll von diesem Modul und seinen möglichkeiten begeistert, habe aber noch einiges in Sachen Perl und FHEM zu lernen. Nun zu meinem aktuellen problem.
Ich möchte für meine heizungssteuerung jeden Morgen bei Sonnenaufgang den Durschnittswert der Nachttemperatur errechnen um daraufhin auf Sommer/Winter betrieb umstellen.
Die Durschnittsberechnung funktioniert lediglich di doif Anweisung bringt mir den folgenden fehler:
'DOIF: the at function "myAverage("86400", "FileLog_Aussen_Temp", "4:::")" must return a timespec and not 4.6.: {myAverage("86400", "FileLog_Aussen_Temp", "4:::")}'
Dies ist meine DOIF Anweisung:
define Jahreszeit_st DOIF ({[Sunrise()}] and [{myAverage("43200", "FileLog_Aussen_Temp", "4:::")}] < 12)({set Jahreszeit Winter})
Meinem verständniss nach bedeutet der Fehler 'must return a timespec and not 4.6.: ' es soll dort eine zeitangabe rein und nicht der wert 4.6 (Ist der Durschnittswert).

Das verstehe ich nicht --> Vielleicht kann mir ja jemand einen Tip geben.

[Spartacus]

Hallo zusammen,
mein Problemchen scheint irgendwie untergegangen zu sein.
http://forum.fhem.de/index.php/topic,23833.msg228951.html#msg228951
Vielleicht kann mir noch jemand einen Tipp dazu geben, wie ich das am Besten lösen sollte.

Danke und Gruß,
Spartacus

[Brockmann]

define Jahreszeit_st DOIF ({[Sunrise()}] and [{myAverage("43200", "FileLog_Aussen_Temp", "4:::")}] < 12)({set Jahreszeit Winter})
Meinem verständniss nach bedeutet der Fehler 'must return a timespec and not 4.6.: ' es soll dort eine zeitangabe rein und nicht der wert 4.6 (Ist der Durschnittswert).

Das verstehe ich nicht --> Vielleicht kann mir ja jemand einen Tip geben.

Da ist mit der Klammerung einiges im Argen. Versuche es mal so (ungetestet):

Code Auswählen Erweitern


define Jahreszeit_st DOIF ([{sunrise()}] and myAverage("43200", "FileLog_Aussen_Temp", "4:::") < 12)(set Jahreszeit Winter)