Autor Thema: neues Modul DOIF  (Gelesen 458340 mal)

Offline Damian

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 9593
Antw:neues Modul DOIF
« Antwort #390 am: 18 August 2014, 08:09:20 »
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.:
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
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

tekki

  • Gast
Antw:neues Modul DOIF
« Antwort #391 am: 18 August 2014, 09:13:10 »
Danke, werde ich am Abend testen.


Grüße
Ralph

Offline Brockmann

  • Sr. Member
  • ****
  • Beiträge: 917
Antw:neues Modul DOIF
« Antwort #392 am: 18 August 2014, 10:13:38 »
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
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:
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.

Offline Damian

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 9593
Antw:neues Modul DOIF
« Antwort #393 am: 18 August 2014, 10:49:24 »

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:

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:

([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

« Letzte Änderung: 18 August 2014, 10:53:17 von Damian »
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Offline Damian

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 9593
Antw:neues Modul DOIF
« Antwort #394 am: 18 August 2014, 11:59:25 »

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
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Offline satprofi

  • Hero Member
  • *****
  • Beiträge: 1604
Antw:neues Modul DOIF
« Antwort #395 am: 18 August 2014, 17:14:58 »
Hallo.
Leider klappt es nur bedingt.

([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?
gruss
-----------------------------------------------------------------------
Raspberry - Fhem 5.7 CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

Offline maxritti

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 857
Antw:neues Modul DOIF
« Antwort #396 am: 19 August 2014, 07:18:29 »
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.

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?

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

Offline satprofi

  • Hero Member
  • *****
  • Beiträge: 1604
Antw:neues Modul DOIF
« Antwort #397 am: 19 August 2014, 07:56:50 »
Auch ich habe
gruss
-----------------------------------------------------------------------
Raspberry - Fhem 5.7 CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

Offline Damian

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 9593
Antw:neues Modul DOIF
« Antwort #398 am: 19 August 2014, 08:19:29 »

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
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Offline maxritti

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 857
Antw:neues Modul DOIF
« Antwort #399 am: 19 August 2014, 08:28:56 »
Alles klaro.
Das werde ich mal machen.

Danke Dir auf jeden Fall.

tekki

  • Gast
Antw:neues Modul DOIF
« Antwort #400 am: 19 August 2014, 09:07:41 »
Du hast da was vergessen  ;)

Zitat aus der Doku:

"Angaben, bei denen aufgrund der Definition kein Zustandswechsel erfolgen kann z. B.:
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

Offline Damian

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 9593
Antw:neues Modul DOIF
« Antwort #401 am: 19 August 2014, 17:48:39 »
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


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

Offline Brockmann

  • Sr. Member
  • ****
  • Beiträge: 917
Antw:neues Modul DOIF
« Antwort #402 am: 20 August 2014, 07:30:48 »
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.

Offline TecCheck

  • Full Member
  • ***
  • Beiträge: 127
Antw:neues Modul DOIF
« Antwort #403 am: 20 August 2014, 19:22:18 »
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
Intel NUC mit Ubuntu als FHEM-Server,
CUL  868, RFXTRX 433, Jeelink-PCA,ZWDongle, HMLan
Aktivlautsprecher über LineIn und Display per HDMI am NUC,
diverse FS20 und Intertechno - Komponenten, Oregon Temp-Hum-Sensoren, HomeMatic, PCA301, KS300,Sonos, ZWave, Alexa,Echo's

Offline det.

  • Hero Member
  • *****
  • Beiträge: 1357
Antw:neues Modul DOIF
« Antwort #404 am: 21 August 2014, 22:18:26 »
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.
LG
det.

 

decade-submarginal