neues Modul DOIF

[kumue]

Hallo Igami

Vollkommen zurecht, guckt dir das Reading noch mal genau an
Code: [Auswählen]
'A_geocode_warncellid' ne 'a_geoCode_WARNCELLID'

Habe das DOIF abgeändert..
Jetzt habe ich auch eine FM im logfile...

2014.11.25 19:16:33 2: DO_DWD_ALERT_IK: reading does not exist: [DWD_IK:A_geocode_warncellid]



Hatte statt DOIF mit notify probiert, da wurde das Reading a_geoCode_WARNCELLID korrekt erkannt.
Da ich ein at habe, welches aller 30min nach neuen DWD/GDS-Alarmen ausschau hält, bekomme ich halt aller 30min vom notify die gleich, alte push-message....
Deshalb wollte ich es mit DOIF machen.

Gruß Kai

[igami]

Jetzt habe ich auch eine FM im logfile...

Sorry, habe mich verguckt, das reading heißt ja auch a_geoCode_WARNCELLID.

Dein DOIF list sagt doch aber aus, dass auf cmd_2 gegangen wurde, und das reading 116070000 ist.

Code Auswählen Erweitern


   Readings:
     2014-11-25 18:42:14   cmd_event       DWD_IK
     2014-11-25 18:42:14   cmd_nr          2
     2014-11-25 18:45:00   e_DWD_IK_a_geoCode_WARNCELLID 116070000
     2014-11-25 18:42:14   state           cmd_2

Hast du denn schon einmal eine Nachricht bekommen? Da es keinen ELSE Zweig gibt und kein doalways gesetzt wurde dürfte das doch sonst nicht mehr wahr werden.

Woher dann aber das

Code Auswählen Erweitern


       Error:
         Mydblog:
           TIME       1416936437.76991
           VALUE      reading does not exist

kommt kann ich dir nicht beantworten.

Grüße
Igami

[kumue]

Hallo Igami,

ich habe mal ein anderes Reading probiert: a_areaDesc
...da kam auch die Push-Message an...
Warum nun im list <DOIF> ein error-Reading mit dem eigentlichen Befehl auftaucht.. keine Ahnung...

Code Auswählen Erweitern


fhem> list DO_DWD_ALERT_IK
Internals:
   DEF        ([DWD_IK:a_areaDesc] eq "Ilm-Kreis") (set Pushover msg 'DWD Alarm IK' '[DWD_IK:a_headline] Beginn [DWD_IK:a_onset_local] Ende [DWD_IK:a_expires_local]' '' 1 'siren')
   NAME       DO_DWD_ALERT_IK
   NR         165
   NTFY_ORDER 50-DO_DWD_ALERT_IK
   STATE      cmd_1
   TYPE       DOIF
   CHANGETIME:
   Helper:
     Dblog:
       Cmd_event:
         Mydblog:
           TIME       1416944148.09654
           VALUE      DWD_IK
       Cmd_nr:
         Mydblog:
           TIME       1416944148.09654
           VALUE      1
       Error:
         Mydblog:
           TIME       1416944148.09654
           VALUE      set Pushover msg 'DWD Alarm IK' 'Amtliche WARNUNG vor FROST Beginn 26.11.2014 00:00:00 Ende 26.11.2014 10:00:00' '' 1 'siren'
       State:
         Mydblog:
           TIME       1416944148.09654
           VALUE      cmd_1
       Wait_timer:
         Mydblog:
           TIME       1416944148.11595
           VALUE      no timer
   Readings:
     2014-11-25 20:35:48   cmd_event       DWD_IK
     2014-11-25 20:35:48   cmd_nr          1
     2014-11-25 20:34:17   e_DWD_IK_a_areaDesc Ilm-Kreis
     2014-11-25 20:35:48   error           set Pushover msg 'DWD Alarm IK' 'Amtliche WARNUNG vor FROST Beginn 26.11.2014 00:00:00 Ende 26.11.2014 10:00:00' '' 1 'siren': OK
     2014-11-25 20:35:48   state           cmd_1
     2014-11-25 20:35:48   wait_timer      no timer
   Condition:
     0          ReadingValDoIf('DWD_IK','a_areaDesc','') eq "Ilm-Kreis"
   Devices:
     0           DWD_IK
     all         DWD_IK
   Do:
     0          set Pushover msg 'DWD Alarm IK' '[DWD_IK:a_headline] Beginn [DWD_IK:a_onset_local] Ende [DWD_IK:a_expires_local]' '' 1 'siren'
   Helper:
     last_timer 0
     sleepdevice DWD_IK
     sleeptimer -1
   Internals:
   Readings:
     0           DWD_IK:a_areaDesc
     all         DWD_IK:a_areaDesc
   State:
   Timerfunc:
Attributes:
   do         always
   group      Services
   icon       cloud102
   room       Wetter
   wait       90


Gruß Kai

[santalaus]

Hallo,

ich habe eine kleine Frage, da ich im Moment unsicher bin.

and {(time_str2num(ReadingsTimestamp( "CUL_HM_HM_LC_Dim1TPBU_FM_1A703C","timedOn",0 ))-time ) > 3600 } and

Es geht dabei um eine BadlüfterSteuerung. Der Lüfter läuft wenn der Actor on ist nach 60 sec mit reduzierter Drehzahl an und nach dem Ausschalten eine Zeit mit erhöhter Drehzahl.
Mit der Abfrage möchte ich nun ein erneutes Antriggern des Actors während der Lüfter noch läuft verhindern. Ich gehe über das Reading da der Actor nicht nur mit dem Doif den Lüfter triggert sondern ggf auch direkt via Schalter.
Da es ja Perl ist, tauchen die Werte nicht im doif auf.
Denke ich prinzipell richtig oder einfach zu kompliziert.

Vielen Dank fürs eindenken

Nico

[Damian]

Hallo,

ich habe eine kleine Frage, da ich im Moment unsicher bin.

and {(time_str2num(ReadingsTimestamp( "CUL_HM_HM_LC_Dim1TPBU_FM_1A703C","timedOn",0 ))-time ) > 3600 } and

Es geht dabei um eine BadlüfterSteuerung. Der Lüfter läuft wenn der Actor on ist nach 60 sec mit reduzierter Drehzahl an und nach dem Ausschalten eine Zeit mit erhöhter Drehzahl.
Mit der Abfrage möchte ich nun ein erneutes Antriggern des Actors während der Lüfter noch läuft verhindern. Ich gehe über das Reading da der Actor nicht nur mit dem Doif den Lüfter triggert sondern ggf auch direkt via Schalter.
Da es ja Perl ist, tauchen die Werte nicht im doif auf.
Denke ich prinzipell richtig oder einfach zu kompliziert.

Vielen Dank fürs eindenken

Nico

Die geschweiften Klammern musst du weglassen. Sonst muss natürlich noch entweder eine Zeitangabe oder ein Reading  bzw. ein  Status irgendwo in eckigen Klammern mit einem Operator (and, or) verknüpft werden, damit dein Modul auch getriggert wird.

Gruß

Damian

[Damian]

Warum nun im list <DOIF> ein error-Reading mit dem eigentlichen Befehl auftaucht.. keine Ahnung...

Das liegt daran, dass set Pushover... einen Returnwert ungleich Null zurückgibt.

Das wird zwar unter Error festgehalten, hat aber sonst keine Bedeutung für das Verhalten des Moduls.

Gruß

Damian

[kumue]

Das liegt daran, dass set Pushover... einen Returnwert ungleich Null zurückgibt.
Das wird zwar unter Error festgehalten, hat aber sonst keine Bedeutung für das Verhalten des Moduls.

Wieder was dazugelernt... Danke Damian !

Gruß Kai

[santalaus]

Hallo Damian,

irgendwie klapp es nicht

Die geschweiften Klammern musst du weglassen. Sonst muss natürlich noch entweder eine Zeitangabe oder ein Reading  bzw. ein  Status irgendwo in eckigen Klammern mit einem Operator (and, or) verknüpft werden, damit dein Modul auch getriggert wird.

Die vollständigt Dev sieht so aus:
([07:30-22:00] and [CUL_HM_HM_LC_Dim1TPBU_FM_1A703C:state] eq "off" and [CUL_HM_HM_LC_Dim1TPBU_FM_1A703C:timedOn] eq "off" and ( (time_str2num(ReadingsTimestamp( "CUL_HM_HM_LC_Dim1TPBU_FM_1A703C","timedOn",0 ))-time ) > 1800 ) and [CUL_HM_HB_UW_Sen_THPL_I_D79284:dewpoint]<[CUL_HM_HB_UW_Sen_THPL_I_CC84F5:dewpoint] and ([CUL_HM_HB_UW_Sen_THPL_I_3E9262:humidity] - [CUL_HM_HB_UW_Sen_THPL_I_CC84F5:humidity]) > 2 ) (set CUL_HM_HM_LC_Dim1TPBU_FM_1A703C on-for-timer 65)

ohne den ReadingsTimestamp Teil funktioniert es halt so das bei jeder Wertänderung erneut getriggert wird. Dann schaltet der Lüfter aber leider auf langsamer also suboptimal.
Nun wird es überhaupt nicht getriggert. Der time Teil wird doch in sec angeben also 1800s= 30min warten. Wie kann ich mir da nochwas zwischenbauen zum prüfen?

Nico

[Damian]

Hallo Damian,

irgendwie klapp es nicht

Die vollständigt Dev sieht so aus:
([07:30-22:00] and [CUL_HM_HM_LC_Dim1TPBU_FM_1A703C:state] eq "off" and [CUL_HM_HM_LC_Dim1TPBU_FM_1A703C:timedOn] eq "off" and ( (time_str2num(ReadingsTimestamp( "CUL_HM_HM_LC_Dim1TPBU_FM_1A703C","timedOn",0 ))-time ) > 1800 ) and [CUL_HM_HB_UW_Sen_THPL_I_D79284:dewpoint]<[CUL_HM_HB_UW_Sen_THPL_I_CC84F5:dewpoint] and ([CUL_HM_HB_UW_Sen_THPL_I_3E9262:humidity] - [CUL_HM_HB_UW_Sen_THPL_I_CC84F5:humidity]) > 2 ) (set CUL_HM_HM_LC_Dim1TPBU_FM_1A703C on-for-timer 65)

ohne den ReadingsTimestamp Teil funktioniert es halt so das bei jeder Wertänderung erneut getriggert wird. Dann schaltet der Lüfter aber leider auf langsamer also suboptimal.
Nun wird es überhaupt nicht getriggert. Der time Teil wird doch in sec angeben also 1800s= 30min warten. Wie kann ich mir da nochwas zwischenbauen zum prüfen?

Nico

Dieser Teil:

(time_str2num(ReadingsTimestamp( "CUL_HM_HM_LC_Dim1TPBU_FM_1A703C","timedOn",0 ))-time ) > 1800

wird nie wahr. Warum? Überlege mal kurz selbst.

Gruß

Damian

[santalaus]

Dieser Teil:

(time_str2num(ReadingsTimestamp( "CUL_HM_HM_LC_Dim1TPBU_FM_1A703C","timedOn",0 ))-time ) > 1800

wird nie wahr. Warum? Überlege mal kurz selbst.

Argl. Brett kopf...

Danke

[Reinerlein]

Hallo Damian,

erstmal Danke für das tolle Modul. Ich finde es sehr hilfreich und richtig übersichtlich...
Aber ich habe ein Problem, welches meiner Meinung nach ein Bug im Modul sein könnte:
Ich habe einen Homematic Bewegungsmelder. Dieser sendet bei Bewegung ein "motion" und in jedem Fall ca. alle 5 Minuten drei Statuswerte (brightness, cover, battery).

Nun habe ich (nach Idee aus der Commandref) einen DOIF-Trigger mit folgender Definition gebaut:
----------------snip---------------
define trigger DOIF ([aussen_Vorgarten_PIR] eq "motion") (set aussen_Vorgarten_PIR_Motion on, set aussen_Vorgarten_PIR_Motion off)
attr trigger do always
----------------snip---------------
Sinn davon ist es, den Dummy bei Auftreten des Motion-Ereignisses des PIR einmal an und gleich wieder auszuschalten (weil darauf dann andere Notifies und/oder DOIFs reagieren).

Ich meine, das hat schon mal gut funktioniert. Mittlerweile wird dieses DOIF aber leider immer getriggert, wenn am PIR *irgendwas* aktualisiert wird (in diesem Fall alle 5 Minuten). Ich habe auch schon mal auf das Reading "motion" geprüft - mit demselben Ergebnis...
Das kann man gut an den Timestamps ablesen.

Hat sich in den letzten beiden Tagen etwas am Modul verändert, womit dieses Verhalten erklärbar wird? Oder habe ich doch noch irgendwo einen Denkfehler?

Danke schon mal für deine Hilfe...

Nachtrag:
Ich habe natürlich noch ein paar andere DOIFs, die tatsächlich auch auf die brightness prüfen sollen. Kann es sein, dass die im Hintergrund irgendwie zusammenhängen. Gibt es da vielleicht eine Namensgleicheit bei der internen Auflistung der Events, oder Modul-statische Variablen o.ä.?
Ich habe jetzt noch nicht in den Code reingeschaut...

Grüße
Reinerlein

[Damian]

Hallo Damian,

erstmal Danke für das tolle Modul. Ich finde es sehr hilfreich und richtig übersichtlich...
Aber ich habe ein Problem, welches meiner Meinung nach ein Bug im Modul sein könnte:
Ich habe einen Homematic Bewegungsmelder. Dieser sendet bei Bewegung ein "motion" und in jedem Fall ca. alle 5 Minuten drei Statuswerte (brightness, cover, battery).

Nun habe ich (nach Idee aus der Commandref) einen DOIF-Trigger mit folgender Definition gebaut:
----------------snip---------------
define trigger DOIF ([aussen_Vorgarten_PIR] eq "motion") (set aussen_Vorgarten_PIR_Motion on, set aussen_Vorgarten_PIR_Motion off)
attr trigger do always
----------------snip---------------
Sinn davon ist es, den Dummy bei Auftreten des Motion-Ereignisses des PIR einmal an und gleich wieder auszuschalten (weil darauf dann andere Notifies und/oder DOIFs reagieren).

Ich meine, das hat schon mal gut funktioniert. Mittlerweile wird dieses DOIF aber leider immer getriggert, wenn am PIR *irgendwas* aktualisiert wird (in diesem Fall alle 5 Minuten). Ich habe auch schon mal auf das Reading "motion" geprüft - mit demselben Ergebnis...
Das kann man gut an den Timestamps ablesen.

Hat sich in den letzten beiden Tagen etwas am Modul verändert, womit dieses Verhalten erklärbar wird? Oder habe ich doch noch irgendwo einen Denkfehler?

Danke schon mal für deine Hilfe...

Nachtrag:
Ich habe natürlich noch ein paar andere DOIFs, die tatsächlich auch auf die brightness prüfen sollen. Kann es sein, dass die im Hintergrund irgendwie zusammenhängen. Gibt es da vielleicht eine Namensgleicheit bei der internen Auflistung der Events, oder Modul-statische Variablen o.ä.?
Ich habe jetzt noch nicht in den Code reingeschaut...

Grüße
Reinerlein

Ich glaube so etwas hatten wir schon. Ich glaube bei hm ist der Status regelmäßig "motion" und die "echte" Bewegung wird irgendwo im Reading angezeigt, was man auf "on" abfragen müsste.

Gruß

Damian

[Reinerlein]

Hi Damian,

das ist richtig. Nur ist der Timestamp der letzten Bewegung (und auch des entsprechenden state-Readings) älter als der Triggerzeitpunkt dieses DOIFs.
Dieses DOIF hätte gar nicht reagieren sollen, da der Zustand nicht neu gesetzt worden ist (sieht man ja auch im Event-Monitor).

Das DOIF reagiert aber.

Hier mal ein List vom DOIF:

Code Auswählen Erweitern


Internals:
   DEF        ([aussen_Vorgarten_PIR] eq "motion") (set aussen_Vorgarten_PIR_Motion on, set aussen_Vorgarten_PIR_Motion off)
   NAME       aussen_Vorgarten_PIR_Motion_Trigger
   NR         1458
   NTFY_ORDER 50-aussen_Vorgarten_PIR_Motion_Trigger
   STATE      Triggered
   TYPE       DOIF
   Readings:
     2014-11-27 12:22:33   cmd_event       aussen_Vorgarten_PIR
     2014-11-27 12:22:33   cmd_nr          1
     2014-11-27 12:22:32   e_aussen_Vorgarten_PIR_STATE motion
     2014-11-27 12:22:33   state           Triggered
   Condition:
     0          InternalDoIf('aussen_Vorgarten_PIR','STATE','') eq "motion"
   Devices:
     0           aussen_Vorgarten_PIR
     all         aussen_Vorgarten_PIR
   Do:
     0          set aussen_Vorgarten_PIR_Motion on, set aussen_Vorgarten_PIR_Motion off
   Helper:
     last_timer 0
     sleeptimer -1
   Internals:
     0           aussen_Vorgarten_PIR:STATE
     all         aussen_Vorgarten_PIR:STATE
   Readings:
   State:
Attributes:
   cmdState   Triggered
   do         always
   group      PIR
   room       _Sensoren


Hier das List vom Motion-Detektor:

Code Auswählen Erweitern


Internals:
   DEF        342A4B
   HMLAN_MSGCNT 180
   HMLAN_RAWMSG E342A4B,0000,C8F72AA2,FF,FFA7,F78410342A4BAF410D0601D400
   HMLAN_RSSI -89
   HMLAN_TIME 2014-11-27 12:22:32
   IODev      HMLAN
   LASTInputDev HMLAN
   MSGCNT     180
   NAME       aussen_Vorgarten_PIR
   NR         1442
   STATE      motion
   TYPE       CUL_HM
   lastMsg    No:F7 - t:10 s:342A4B d:AF410D 0601D400
   protLastRcv 2014-11-27 12:22:32
   protSnd    30 last_at:2014-11-27 11:37:57
   protState  CMDs_done
   rssi_at_HMLAN avg:-82.27 min:-95 max:-76 lst:-89 cnt:180
   Readings:
     2014-11-26 21:55:06   Activity        alive
     2014-11-23 17:14:55   CommandAccepted yes
     2014-11-20 20:32:40   D-firmware      1.6
     2014-11-20 20:32:40   D-serialNr      LEQ1278807
     2014-11-23 17:14:55   PairedTo        0xAF410D
     2014-11-23 17:13:53   R-brightFilter  4
     2014-11-23 17:13:53   R-captInInterval on
     2014-11-23 17:13:53   R-evtFltrNum    1
     2014-11-19 17:58:59   R-evtFltrPeriod 1 s
     2014-11-23 17:14:56   R-ledOnTime     0 s
     2014-11-23 17:13:53   R-minInterval   30
     2014-11-23 17:14:55   R-pairCentral   0xAF410D
     2014-11-23 17:14:55   RegL_00:        02:01 0A:AF 0B:41 0C:0D 00:00
     2014-11-23 17:14:56   RegL_01:        01:12 02:49 08:00 22:00 00:00
     2014-11-27 12:22:32   battery         ok
     2014-11-27 12:22:32   brightness      212
     2014-11-27 12:22:32   cover           closed
     2014-11-27 11:37:57   motion          on (to vccu)
     2014-11-27 11:37:57   motionCount     140_next:14s
     2014-11-27 12:22:32   recentStateType info
     2014-11-27 11:37:57   state           motion
     2014-11-25 15:04:37   trigDst_AF410D  noConfig
     2014-11-27 11:37:57   trigDst_vccu    noConfig
   Helper:
     mId        005D
     rxType     28
     Io:
       newChn     +342A4B,00,01,1E
       nextSend   1417087352.87598
       prefIO
       rxt        2
       vccu
       p:
         342A4B
         00
         01
         1E
     Mrssi:
       mNo        F7
       Io:
         HMLAN      -87
     Prt:
       bErr       0
       sProc      0
       sleeping   0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_hmlan:
         avg        -82.2777777777777
         cnt        180
         lst        -89
         max        -76
         min        -95
Attributes:
   IODev      HMLAN
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.6
   group      PIR
   model      HM-Sen-MDIR-O
   peerIDs    00000000,
   room       _Sensoren
   serialNr   LEQ1278807
   showtime   1
   subType    motionDetector


Und hier noch das List vom Dummy:

Code Auswählen Erweitern


Internals:
   NAME       aussen_Vorgarten_PIR_Motion
   NR         1457
   STATE      2014-11-27 12:22:32
   TYPE       dummy
   Readings:
     2014-11-27 12:22:32   state           off
Attributes:
   group      PIR
   room       _Sensoren
   setList    on off
   stateFormat { ReadingsTimestamp('aussen_Vorgarten_PIR_Motion', 'state', '-') }
   webCmd     on:off


Wie man an den Zeitstempeln sieht, hat das DOIF irgendwie auf das falsche reagiert. Und im Falle eines Motiondetektors erhält man somit bei jeder Statusmeldung eine Bewegung, was ja so nicht richtig ist.
Über ein normales Notify geht es (so habe ich es ja erstmal umgestellt, da ich kein Dauerlicht draussen haben wollte

Ich habe auch schon mal direkt auf das Reading "motion" geprüft (was bei mir auf "on (to vccu)" steht)... dasselbe Verhalten...

Grüße
Reinerlein

[Damian]

Hi Damian,

das ist richtig. Nur ist der Timestamp der letzten Bewegung (und auch des entsprechenden state-Readings) älter als der Triggerzeitpunkt dieses DOIFs.
Dieses DOIF hätte gar nicht reagieren sollen, da der Zustand nicht neu gesetzt worden ist (sieht man ja auch im Event-Monitor).

Das DOIF reagiert aber.

Das ist ein Missverständnis. DOIF reagiert immer, sobald irgendein Event des angegebenen Devices kommt. Es wird gar nicht überprüft, ob sich das angegebene Reading geändert hat oder nicht. Daher verhält sich das Modul wie programmiert. Wie gesagt, du solltest das Reading abfragen, welches bei Bewegung wirklich den Zustand ändert.

Edit: Vielleicht kannst du das Reading: recentStateType abfragen. Dort Steht jetzt "Info". Vermutlich steht dort etwas anderes bei Bewegung.

Gruß

Damian

[Reinerlein]

Hallo Damian,

ok, ich dachte das Modul würde sich dabei genauso verhalten wie ein Notify, und nur die Events auswerten, die für das geforderte Reading auftreten...

Es gäbe noch ein Reading, welches einen aufsteigenden Zähler bzgl. der Motion-Detektion enthält. Aber das verursacht das gleiche Problem. Entweder es wird verändert (weil sich etwas bewegt hat), oder eben nicht. Die anderen Readings weden trotzdem aktualisiert, sodass das DOIF trotzdem wieder reagiert (ich kann da ja keine sinnvolle Bedingung setzen, oder geht sowas wie "ist anders als beim letzten Prüfen"?).
Es gibt kein Reading, welches nach einer kurzen Zeit wieder zurückfällt, und bei Bewegung entsprechend neu gesetzt wird. Das sollte ja das DOIF zusammen mit dem Dummy machen...

Na, dann bleibt halt mein Notify dort, ist ja schließlich nicht schlimm. Du solltest das nur in deiner Doku erwähnen, da es dann keine Lösung für einen Motiondetektor (oder ähnlich arbeitende Komponenten) gibt, bzw. dass auf jede Änderung am Device reagiert wird. Damit wird es ja für manche auch u.U. ineffizient in der Nutzung...

Danke trotzdem für deine Unterstützung...

Grüße
Reinerlein