neues Modul DOIF

[Damian]

Hallo Damian,

ich habe hierzu noch einmal eine Frage. Kann es sein das durch den von Push_MSG verursachten Error, die weiteren Nachrichten nicht mehr versendet werden.
Immer wenn ich in der DEF auf modify klicke, wird das DOIF neu initialisiert und sendet einmal die Nachricht zur nächsten Zeitpunkt. Dann erscheint der Error und es kommen keine weiteren Nachrichten. Klicke ich erneut in der DEF wieder auf modify, versendet das DOIF zum nächsten Zeitpunkt wieder eine Nachricht.
Oder habe ich in meiner DEF einen Fehler. Ziel ist es, dass ich zu mehreren Zeitpunkten eine Erinnerungs-Nachricht bekommen möchte.

Grüße
Ralph

Du hast da was vergessen 

Zitat aus der Doku:

"Angaben, bei denen aufgrund der Definition kein Zustandswechsel erfolgen kann z. B.:

Code Auswählen Erweitern

define DI_Licht DOIF ([08:00]) (set Switch on)
attr DI_Licht do always

müssen mit Attribut "do always" definiert werden, damit sie nicht nur einmal, sondern jedes mal (hier jeden Tag) ausgeführt werden."

Gruß

Damian

[tekki]

Danke, werde ich am Abend testen.


Grüße
Ralph

[Brockmann]

Code Auswählen Erweitern

DEF 
([05:05] or [12:00] or [19:00]) (set Push_msg msg 'Test' 'Das ist ein Test'' '' 0 '')


Geht es dabei immer noch um diese Definition?
Hmm, ok, steht ja in der Doku, dass man in solchen Fällen do always verwenden muss.

Aber wenn ich statt dessen

Code Auswählen Erweitern

DEF 
([05:05-05:06] or [12:00-12:01] or [19:00-19:01]) (set Push_msg msg 'Test' 'Das ist ein Test'' '' 0 '')

nehme, würde es ohne do always gehen und die Aktion würde trotzdem jeweils nur einmal ausgeführt werden.
Das legt zumindest dieses Beispiel aus der Doku nahe:

Code Auswählen Erweitern

define DI_Radio DOIF ([08:00-10:00] or [20:00-22:00]) (set Radio on) DOELSE (set Radio off)

Anscheinend werden einzelne Zeitpunkte intern anders behandelt als Intervalle. Beim Intervall wird jeweils am Anfang des Intervalls und direkt nach dem Ende des Intervalls getriggert. Bei einem Zeitpunkt wird nur am Anfang getriggert, aber nicht nach dem Ende.
Klingt erstmal logisch, aber gibt es dafür wirklich einen guten Grund? Könnte man nicht einen Zeitpunkt intern als ein "Miniintervall" behandeln, also [05:05] entspricht intern [05:05:00-05:05:59]? Dann würde die Bedingung nach dem Zeitpunkt wieder unwahr werden und das DOIF beim nächsten Erreichen des Zeitpunkts auch ohne do always wieder ausgeführt werden.

Ich stelle das mal zur Diskussion, weil ich es etwas unintuitiv finde, dass man beim Angeben von klassischen Schaltzeitpunkten per DOIF grundsätzlich do always setzen muss. Ohne ergibt keinen Sinn, weil das DOIF dann nur ein einziges Mal getriggert würde, also ein einmaliger Schaltzeitpunkt im wahrsten Sinn des Wortes wäre, was ja ein eher exotisches Anwendungszenario ist.

[Damian]

Ich stelle das mal zur Diskussion, weil ich es etwas unintuitiv finde, dass man beim Angeben von klassischen Schaltzeitpunkten per DOIF grundsätzlich do always setzen muss. Ohne ergibt keinen Sinn, weil das DOIF dann nur ein einziges Mal getriggert würde, also ein einmaliger Schaltzeitpunkt im wahrsten Sinn des Wortes wäre, was ja ein eher exotisches Anwendungszenario ist.

Das stimmt nicht. Auch hier ein Beispiel aus der Doku:

Code Auswählen Erweitern

define DI_Licht DOIF ([08:00] or [10:00] or [20:00]) (set Switch on) DOELSEIF ([09:00] or [11:00] or [00:00]) (set Switch off)

Hier kommt man ohne do always aus, weil es zwei Zustände gibt (cmd1 und cmd2), die sich abwechseln.

Grundsätzlich ist eine Zeitpunktangabe nur zum Ausführungszeitpunkt wahr, Intervalle sind dagegen über einen bestimmten Zeitraum wahr. Das sind aus meiner Sicht zwei unterschiedliche Dinge.

Und mit der Angabe:

Code Auswählen Erweitern

([05:05-05:06] or [12:00-12:01] or [19:00-19:01]) (set Push_msg msg 'Test' 'Das ist ein Test'' '' 0 '')

würde man unnötig doppelt so oft triggern.

Man könnte auch auf die Idee kommen bei Angaben ohne ELSE-Fall "do always" immer automatisch zu setzen. Diese Vorgehensweise würde allerdings kollidieren mit Abfragen von kontinuierlich sendenden Sensoren, bei denen es Sinn machen kann, kein do always und keinen ELSE-Fall zu definieren - siehe Waschmaschine-fertig-Beispiel.

Ich denke es reicht diesen Sachverhalt deutlich zu dokumentieren. Ich sehe da keinen logischen Bruch.

Gruß

Damian

[Damian]

Ich denke es reicht diesen Sachverhalt deutlich zu dokumentieren. Ich sehe da keinen logischen Bruch.

Was mir dazu noch eingefallen ist:

Ich könnte bei der Definition erkennen, ob in allen Bedingungen nur Timer (Timeintervalle) definiert sind und dann automatisch do always-Attribut setzen.

Gruß

Damian

[satprofi]

Hallo.
Leider klappt es nur bedingt.

Code Auswählen Erweitern


([myTwilight:aktEvent] eq "sr_weather") (set AquaLamp3000K on)
DOELSEIF ([myTwilight:aktEvent] eq "sr_weather") (set AquaLamp4000K_1 on)
DOELSEIF ([myTwilight:aktEvent] eq "sr_weather") (set AquaLamp4000K_2 on)
DOELSEIF ([10:00]) (set AquaLamp3000K off)
DOELSEIF ([17:00]) (set AquaLamp3000K on)
DOELSEIF ([myTwilight:aktEvent] eq "ss_weather) (set AquaLamp4000K_1 off)
DOELSEIF ([myTwilight:aktEvent] eq "ss_civil) (set AquaLamp4000K_2 off)
DOELSEIF ([21:45]) (set AquaLamp3000K off)


die lampen werden eingeschaltet, auch 3000k um 10:00 aus. aber eine stunde später wieder an, weil "sr_weather" noch immer aktiv.
hat jemand schon mal mit diesem event geschalten? wenn es nicht klappen sollte muss ich auf "sr" umstellen, das ist nach einiger zeit von sr_weather überschrieben. aber klappt dann das sleep noch?

[maxritti]

Hallo zusammen,

seit längerem lese ich hier bei dem DOIF Modul mit.
Da bin ich so begeistert von und wollte es nun auch mal einsetzen.

Daher mal einfach angefangen. Ich habe einen HM Regensensor und im Dachgeschoss an Dachfenstern Kontakte.
Nun wollte ich wenn es anfängt zu regnen und die Fenster offen sind ein Pushover schicken.
Soweit so gut und dieses DOIF definiert.

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        (([DG_xx_RS_Markise_Rain:state] eq "rain") and (([DG_hz_TK_Dachfenster:state] eq "open") or ([DG_wz_TK_Dachfenster:state] eq "open"))) ( set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 '')
   NAME       di_Rain
   NR         163
   NTFY_ORDER 50-di_Rain
   STATE      cmd_2
   TYPE       DOIF
   CHANGETIME:
   Helper:
     Dblog:
       Last_cmd:
         Mydblog:
           TIME       1408371955.65279
           VALUE      2
       Last_cmd_event:
         Mydblog:
           TIME       1408371955.65279
           VALUE      DG_hz_TK_Dachfenster
       Last_error:
         Mydblog:
           TIME       1408424752.34098
           VALUE       set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 ''
       State:
         Mydblog:
           TIME       1408371955.65279
           VALUE      cmd_2
   Readings:
     2014-08-18 16:25:55   last_cmd        2
     2014-08-18 16:25:55   last_cmd_event  DG_hz_TK_Dachfenster
     2014-08-19 07:05:52   last_error       set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 '': OK
     2014-08-18 16:25:55   state           cmd_2
   Condition:
     0          (ReadingValDoIf('DG_xx_RS_Markise_Rain','state','') eq "rain") and ((ReadingValDoIf('DG_hz_TK_Dachfenster','state','') eq "open") or (ReadingValDoIf('DG_wz_TK_Dachfenster','state','') eq "open"))
   Devices:
     0           DG_xx_RS_Markise_Rain  DG_hz_TK_Dachfenster  DG_wz_TK_Dachfenster
     all         DG_xx_RS_Markise_Rain  DG_hz_TK_Dachfenster  DG_wz_TK_Dachfenster
   Do:
     0           set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 ''
   Helper:
     last_cond  1
     last_timer 0
     sleeptimer -1
   Readings:
     0          DG_xx_RS_Markise_Rain:state DG_hz_TK_Dachfenster:state DG_wz_TK_Dachfenster:state
Attributes:
   group      doif

Heute morgen hat meine Frau dann mal die Dachfenster geöffnet und schwups, kommen die Meldungen, da der Regensensort auf "rain" steht, wegen Tau.
Dafür habe ich nun mal ein at definiert, welches alle 30 Minuten die Heizung des Sensors anschmeisst.

Aber das ist nicht das Problem.
Kurioserweise kommen nun brav etwa alle 10 Minuten die Pushmeldungen aufs Handy, obwohl sich weder der Regensensor noch die Sensoren am Fenster ändern.
Bisher bin ich davon ausgegangen, dass DOIF bei Änderungen reagiert.

Nur warum passiert das dann so wie bei mir?

Code Auswählen Erweitern


2014.08.19 07:05:52.340 2: di_Rain:  set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 '': OK
2014.08.19 07:05:51.356 2: di_Rain:  set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 '': OK
2014.08.19 07:05:50.451 2: di_Rain:  set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 '': OK
2014.08.19 07:00:00.027 3: CUL_HM set DG_xx_RS_Markise_Heating on-for-timer 500
2014.08.19 06:55:53.602 2: di_Rain:  set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 '': OK
2014.08.19 06:55:52.238 2: di_Rain:  set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 '': OK
2014.08.19 06:55:50.493 2: di_Rain:  set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 '': OK
2014.08.19 06:45:52.288 2: di_Rain:  set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 '': OK
2014.08.19 06:45:51.368 2: di_Rain:  set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 '': OK
2014.08.19 06:45:50.497 2: di_Rain:  set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 '': OK
2014.08.19 06:35:52.235 2: di_Rain:  set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 '': OK
2014.08.19 06:35:51.341 2: di_Rain:  set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 '': OK
2014.08.19 06:35:50.451 2: di_Rain:  set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 '': OK
2014.08.19 06:30:00.027 3: CUL_HM set DG_xx_RS_Markise_Heating on-for-timer 500
2014.08.19 06:25:52.333 2: di_Rain:  set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 '': OK
2014.08.19 06:25:51.373 2: di_Rain:  set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 '': OK
2014.08.19 06:25:50.479 2: di_Rain:  set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 '': OK
2014.08.19 06:21:03.356 2: di_Rain:  set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 '': OK
2014.08.19 06:20:49.135 2: di_Rain:  set myPushover msg 'Regen - Dachfenster' 'Es faengt an zu regnen und ein Dachfenster ist offen.' 'iPhone5S' 0 '': OK


[satprofi]

Auch ich habe

[Damian]

Heute morgen hat meine Frau dann mal die Dachfenster geöffnet und schwups, kommen die Meldungen, da der Regensensort auf "rain" steht, wegen Tau.
Dafür habe ich nun mal ein at definiert, welches alle 30 Minuten die Heizung des Sensors anschmeisst.

Aber das ist nicht das Problem.
Kurioserweise kommen nun brav etwa alle 10 Minuten die Pushmeldungen aufs Handy, obwohl sich weder der Regensensor noch die Sensoren am Fenster ändern.
Bisher bin ich davon ausgegangen, dass DOIF bei Änderungen reagiert.

Nur warum passiert das dann so wie bei mir?

Du arbeitest nicht mit der aktuellen Version von DOIF.

Nimm einfach die aktuelle Version aus dem ersten Post. Das Problem wurde bereits behoben.

Das System herunterfahren, DOIF-Modul ins FHEM-Verzeichnis kopieren, danach auf  DEF bei deinem definierten DOIF-Modul klicken und mit Modify-Button neu definieren.

Gruß

Damian

[maxritti]

Alles klaro.
Das werde ich mal machen.

Danke Dir auf jeden Fall.

[tekki]

Du hast da was vergessen 

Zitat aus der Doku:

"Angaben, bei denen aufgrund der Definition kein Zustandswechsel erfolgen kann z. B.:

Code Auswählen Erweitern

define DI_Licht DOIF ([08:00]) (set Switch on)
attr DI_Licht do always

müssen mit Attribut "do always" definiert werden, damit sie nicht nur einmal, sondern jedes mal (hier jeden Tag) ausgeführt werden."

Gruß

Damian

Hallo Damian,
habe gestern do always hinzugefügt. Nun funktioniert es wie gewünscht. Bzgl. dem Hinweis in der Doku habe ich das nicht auf meine Umsetzung bezogen. Aber im nach hinein ist es logisch, da sich auch in meinem Fall kein Zustand ändert

Danke noch mal
Grüße
Ralph

[Damian]

Das aktuelle Modul wurde eingecheckt. Es ist also ab morgen per Update verfügbar.

Rudi müsste es noch in der Commandref zu den Hilfs (Erweiterungs-) Modulen verschieben.

Gruß

Damian

[Brockmann]

Das aktuelle Modul wurde eingecheckt. Es ist also ab morgen per Update verfügbar.

Na, das sind doch mal gute Nachrichten!
Bei der Gelegenheit nochmal Danke für das tolle Modul und das geduldige Erklären. 
Aus meiner Sicht bringt DOIF FHEM insgesamt ein schönes Stückchen voran.

[TecCheck]

Na, das sind doch mal gute Nachrichten!
Bei der Gelegenheit nochmal Danke für das tolle Modul und das geduldige Erklären. 
Aus meiner Sicht bringt DOIF FHEM insgesamt ein schönes Stückchen voran.

Dem kann ich nur voll und ganz beipflichten! 

Wolfgang

[det.]

Hallo Damian,
vielen Dank für das sehr nützliche Modul. Hat gleich ein paar Altlasten (notify für WW-Zirkulation und Helligkeits- und zeitgesteuerte Außenbeleuchtung ersetzt). Ein kleines Problem habe ich noch - und vielleicht nur zu dumm gewesen, das in Deinem sehr ausführlichen commandref Artikel zu finden: Ich möchte einen Aktor nach 5min wieder ausschalten und der beherrscht kein on-for-timer 300.