[CUL_HM] problem mit attr actAutoTry beim ActionDetector

[frank]

moin,

attr actAutoTry ist nach einem fhem restart "wirkungslos", so dass nicht sendende devices nach ablauf von actCycle auf dead gesetzt werden.

erst nach der ersten message vom device nach restart startet actAutoTry seine aufgabe.
auch eine änderung von attr actCycle kann actAutoTry "starten".

[frank]

ganz genau genommen funktioniert attr actAutoTry nach jedem zweiten fhem restart nicht.

1. ist ein device vor restart dead, funktioniert actAutoTry nach dem restart für dieses device.

2. ist ein device alive vor dem restart, funktioniert actAutoTry nach restart nicht für dieses device.

[martinp876]

Kann ich so noch nicht nachvollziehen.
Bitte
attr global shoInternalValues 1
list <device>

set actionDetector update
list <device>

- also 2-mal list mit einmal Update dazwischen

[frank]

Code Auswählen Erweitern

Internals:
   DEF        285A54
   FUUID      5c4ce2ea-f33f-09c4-b956-ce3893a0bd2297d1
   IODev      hmlan1
   NAME       SwitchUP01
   NOTIFYDEV  global
   NR         424
   NTFY_ORDER 50-SwitchUP01
   STATE      off
   TYPE       CUL_HM
   chanNo     01
   peerList   self01,
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   READINGS:
     2020-08-02 17:16:23   .associatedWith SwitchUP01,SwitchUP01
     2020-02-27 10:10:35   .peerListRDate  2020-02-27 10:10:35
     2020-08-02 16:52:46   .protLastRcv    2020-08-02 16:52:46
     2020-08-02 18:20:55   Activity        dead
     2020-07-01 13:10:31   CommandAccepted yes
     from archivexx        D-firmware      1.12
     from archivexx        D-serialNr      LEQ0130409
     2020-02-27 10:10:34   PairedTo        0x1ACE1F
     2016-07-17 23:25:08   R-intKeyVisib   visib
     2016-07-17 23:25:08   R-pairCentral   0x1ACE1F
     2016-07-17 23:25:11   R-self01-lgActionType jmpToTarget
     2020-02-25 17:40:34   R-self01-lgCtDlyOff between
     2020-02-25 17:40:34   R-self01-lgCtDlyOn between
     2020-02-25 17:40:34   R-self01-lgCtOff between
     2020-02-25 17:40:34   R-self01-lgCtOn between
     2016-07-17 23:25:11   R-self01-lgCtValHi 100
     2020-02-27 10:10:36   R-self01-lgCtValLo 50
     2016-07-17 23:25:11   R-self01-lgMultiExec off
     2016-07-17 23:25:11   R-self01-lgOffDly 0 s
     2016-07-17 23:25:11   R-self01-lgOffTime unused
     2016-07-17 23:25:11   R-self01-lgOffTimeMode absolut
     2016-07-17 23:25:11   R-self01-lgOnDly 0 s
     2020-02-25 17:40:34   R-self01-lgOnTime 5 s
     2016-07-17 23:25:11   R-self01-lgOnTimeMode absolut
     2016-07-17 23:25:11   R-self01-lgSwJtDlyOff off
     2016-07-17 23:25:11   R-self01-lgSwJtDlyOn on
     2016-07-17 23:25:11   R-self01-lgSwJtOff dlyOn
     2016-07-17 23:25:11   R-self01-lgSwJtOn dlyOff
     2016-07-17 23:25:11   R-self01-shActionType jmpToTarget
     2016-07-17 23:25:11   R-self01-shCtDlyOff geLo
     2016-07-17 23:25:11   R-self01-shCtDlyOn geLo
     2016-07-17 23:25:11   R-self01-shCtOff geLo
     2016-07-17 23:25:11   R-self01-shCtOn geLo
     2016-07-17 23:25:11   R-self01-shCtValHi 100
     2016-07-17 23:25:11   R-self01-shCtValLo 50
     2016-07-17 23:25:11   R-self01-shMultiExec off
     2016-07-17 23:25:11   R-self01-shOffDly 0 s
     2016-07-17 23:25:11   R-self01-shOffTime unused
     2016-07-17 23:25:11   R-self01-shOffTimeMode absolut
     2016-07-17 23:25:11   R-self01-shOnDly 0 s
     2019-04-14 01:25:53   R-self01-shOnTime unused
     2016-07-17 23:25:11   R-self01-shOnTimeMode absolut
     2016-07-17 23:25:11   R-self01-shSwJtDlyOff off
     2016-07-17 23:25:11   R-self01-shSwJtDlyOn on
     2016-07-17 23:25:11   R-self01-shSwJtOff dlyOn
     2016-07-17 23:25:11   R-self01-shSwJtOn dlyOff
     2016-07-17 23:25:09   R-sign          off
     2020-02-27 10:10:34   RegL_00.        00:00 02:81 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1A 0B:CE 0C:1F
     2020-02-27 10:10:35   RegL_01.        00:00 08:00
     2020-02-27 10:10:36   RegL_03.self01  00:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:44 83:44 84:32 85:64 86:00 87:25 88:00 89:FF 8A:01 8B:14 8C:63
     2020-08-02 17:16:43   cfgState        ok
     2020-08-02 16:52:46   commState       CMDs_done
     2020-08-02 16:52:46   deviceMsg       off (to ccu)
     2020-08-02 16:52:46   level           0
     2020-08-02 16:52:46   pct             0
     2020-08-02 17:16:23   peerList        self01,
     2016-12-02 13:45:45   powerOn         2016-12-02 13:45:45
     2020-08-02 16:52:46   recentStateType info
     2020-08-02 16:52:46   state           off
     2020-08-02 16:52:46   timedOn         off
   helper:
     HM_CMDNR   115
     mId        0002
     peerFriend peerSens,peerVirt
     peerOpt    3:switch
     regLst     0,1,3p
     rxType     1
     tmplChg    0
     cmds:
       TmplKey    self01,:1596381400.884:1596381400.8987
       TmplTs     1596381400.8987
       cmdKey     1:1:0::SwitchUP01:0002:01:self01,
       cmdLst:
         assignHmKey noArg
         clear      [readings|trigger|register|oldRegs|rssi|msgEvents|msgErrors|attack|all]
         deviceRename newName
         eventL     -peer- -cond-
         eventS     -peer- -cond-
         fwUpdate   -filename- -bootTime- ...
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  [List0|List1|List2|List3|List4|List5|List6] ... [-PeerChannel-]
         getSerial  noArg
         getVersion noArg
         inhibit    [on|off]
         off        noArg
         on         noArg
         on-for-timer -ontime-
         on-till    -time-
         pair       noArg
         peerBulk   -peer1,peer2,...- [set|unset]
         peerIODev  [IO] -btn- [set|unset]... not for future use
         peerSmart  -peerOpt-
         press      [long|short] -peer- [-repCount(long only)-] [-repDelay-] ...
         pressL     -peer-
         pressS     -peer-
         raw        data ...
         regBulk    -list-.-peerChn- -addr1:data1- -addr2:data2- ...
         regSet     [prep|exec] -regName- -value- ... [-peerChannel-]
         reset      noArg
         sign       [on|off]
         statusRequest noArg
         toggle     noArg
         tplDel     tmplt
         tplSet_0   -tplChan-
         tplSet_self01 -tplPeer-
         unpair     noArg
       lst:
         peer       self01
         peerOpt    Fenster.Bad,SDTeam_Btn1,SwitchES01_SenF,SwitchES01_SenI,SwitchES01_SenPwr,SwitchES01_SenU,SwitchPBU01_Btn_01,SwitchPBU01_Btn_02,SwitchPBU02_Btn_01,SwitchPBU02_Btn_02,Tuer.SZ,Tuer.WZ.Terrasse,VentilControler.AZ.Nord_Btn1,VentilControler.AZ.West_Btn1,VentilControler.Bad_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,ccu_Btn2,ccu_Btn3,ccu_Btn4,ccu_Btn5,virtAktorAlarmOff_Btn1
         tplChan   
         tplDel     
         tplPeer    toggleOn-for-timerOff_switch_long,SwOff_short,SwOnCond_long,motionOnSw_short,SwToggle_long,SwOnCond_short,ignore_short,SwCondBelow_short,SwCondAbove_short,SwToggleIgnore,SwOn_long,autoOff_short,SwOff_long,SwToggle_short,ignore_long,motionOnSw_long,toggleOn-for-timerOff_switch_short,SwOn_short,SwCondBelow_long,SwCondAbove_long,autoOff_long
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     io:
       newChn     +285A54,00,00,00
       rxt        0
       vccu       ccu
       p:
         285A54
         00
         00
         00
       prefIO:
         cul868
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rssi:
     shadowReg:
     tmpl:
Attributes:
   .mId       0004
   IODev      hmlan1
   IOgrp      ccu:cul868
   actCycle   001:00
   actStatus  dead
   autoReadReg 5_readMissing
   devStateIcon on:on:off off:off:on timedOn:on-for-timer:off
   event-on-change-reading .*
   expert     defReg,allReg,rawReg,templ
   firmware   1.12
   group      Beleuchtung
   model      HM-LC-SW1-FM
   peerIDs    00000000,285A5401,
   room       65_Flur.OG
   serialNr   LEQ0130409
   stateFormat {if(ReadingsVal($name,"timedOn","off")eq"running"){return "timedOn";}else{return ReadingsVal($name,"state","off");}}
   subType    switch
   webCmd     statusRequest:toggle:on:off

Code Auswählen Erweitern

Internals:
   DEF        285A54
   FUUID      5c4ce2ea-f33f-09c4-b956-ce3893a0bd2297d1
   IODev      cul868
   LASTInputDev hmlan1
   MSGCNT     2
   NAME       SwitchUP01
   NOTIFYDEV  global
   NR         424
   NTFY_ORDER 50-SwitchUP01
   STATE      off
   TYPE       CUL_HM
   chanNo     01
   cul868_MSGCNT 1
   cul868_RAWMSG A0E74A410285A541ACE1F0601000049::-72:cul868
   cul868_RSSI -72
   cul868_TIME 2020-08-02 23:21:03
   hmlan1_MSGCNT 1
   hmlan1_RAWMSG E285A54,0000,51A2F6FD,FF,FFC0,74A410285A541ACE1F0601000049
   hmlan1_RSSI -64
   hmlan1_TIME 2020-08-02 23:21:03
   lastMsg    No:74 - t:10 s:285A54 d:1ACE1F 0601000049
   peerList   self01,
   protLastRcv 2020-08-02 23:21:03
   protRcv    1 last_at:2020-08-02 23:21:03
   protSnd    2 last_at:2020-08-02 23:21:03
   protState  CMDs_done
   rssi_at_cul868 cnt:1 min:-72 max:-72 avg:-72 lst:-72
   rssi_at_hmlan1 cnt:1 min:-64 max:-64 avg:-64 lst:-64
   rssi_cul868 cnt:1 min:-73 max:-73 avg:-73 lst:-73
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   READINGS:
     2020-08-02 17:16:23   .associatedWith SwitchUP01,SwitchUP01
     2020-02-27 10:10:35   .peerListRDate  2020-02-27 10:10:35
     2020-08-02 23:21:03   .protLastRcv    2020-08-02 23:21:03
     2020-08-02 23:22:48   Activity        alive
     2020-07-01 13:10:31   CommandAccepted yes
     from archivexx        D-firmware      1.12
     from archivexx        D-serialNr      LEQ0130409
     2020-02-27 10:10:34   PairedTo        0x1ACE1F
     2016-07-17 23:25:08   R-intKeyVisib   visib
     2016-07-17 23:25:08   R-pairCentral   0x1ACE1F
     2016-07-17 23:25:11   R-self01-lgActionType jmpToTarget
     2020-02-25 17:40:34   R-self01-lgCtDlyOff between
     2020-02-25 17:40:34   R-self01-lgCtDlyOn between
     2020-02-25 17:40:34   R-self01-lgCtOff between
     2020-02-25 17:40:34   R-self01-lgCtOn between
     2016-07-17 23:25:11   R-self01-lgCtValHi 100
     2020-02-27 10:10:36   R-self01-lgCtValLo 50
     2016-07-17 23:25:11   R-self01-lgMultiExec off
     2016-07-17 23:25:11   R-self01-lgOffDly 0 s
     2016-07-17 23:25:11   R-self01-lgOffTime unused
     2016-07-17 23:25:11   R-self01-lgOffTimeMode absolut
     2016-07-17 23:25:11   R-self01-lgOnDly 0 s
     2020-02-25 17:40:34   R-self01-lgOnTime 5 s
     2016-07-17 23:25:11   R-self01-lgOnTimeMode absolut
     2016-07-17 23:25:11   R-self01-lgSwJtDlyOff off
     2016-07-17 23:25:11   R-self01-lgSwJtDlyOn on
     2016-07-17 23:25:11   R-self01-lgSwJtOff dlyOn
     2016-07-17 23:25:11   R-self01-lgSwJtOn dlyOff
     2016-07-17 23:25:11   R-self01-shActionType jmpToTarget
     2016-07-17 23:25:11   R-self01-shCtDlyOff geLo
     2016-07-17 23:25:11   R-self01-shCtDlyOn geLo
     2016-07-17 23:25:11   R-self01-shCtOff geLo
     2016-07-17 23:25:11   R-self01-shCtOn geLo
     2016-07-17 23:25:11   R-self01-shCtValHi 100
     2016-07-17 23:25:11   R-self01-shCtValLo 50
     2016-07-17 23:25:11   R-self01-shMultiExec off
     2016-07-17 23:25:11   R-self01-shOffDly 0 s
     2016-07-17 23:25:11   R-self01-shOffTime unused
     2016-07-17 23:25:11   R-self01-shOffTimeMode absolut
     2016-07-17 23:25:11   R-self01-shOnDly 0 s
     2019-04-14 01:25:53   R-self01-shOnTime unused
     2016-07-17 23:25:11   R-self01-shOnTimeMode absolut
     2016-07-17 23:25:11   R-self01-shSwJtDlyOff off
     2016-07-17 23:25:11   R-self01-shSwJtDlyOn on
     2016-07-17 23:25:11   R-self01-shSwJtOff dlyOn
     2016-07-17 23:25:11   R-self01-shSwJtOn dlyOff
     2016-07-17 23:25:09   R-sign          off
     2020-02-27 10:10:34   RegL_00.        00:00 02:81 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1A 0B:CE 0C:1F
     2020-02-27 10:10:35   RegL_01.        00:00 08:00
     2020-02-27 10:10:36   RegL_03.self01  00:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:44 83:44 84:32 85:64 86:00 87:25 88:00 89:FF 8A:01 8B:14 8C:63
     2020-08-02 17:16:43   cfgState        ok
     2020-08-02 23:21:03   commState       CMDs_done
     2020-08-02 23:21:03   deviceMsg       off (to ccu)
     2020-08-02 23:21:03   level           0
     2020-08-02 23:21:03   pct             0
     2020-08-02 17:16:23   peerList        self01,
     2016-12-02 13:45:45   powerOn         2016-12-02 13:45:45
     2020-08-02 23:21:03   recentStateType info
     2020-08-02 23:21:03   state           off
     2020-08-02 23:21:03   timedOn         off
   helper:
     HM_CMDNR   116
     cSnd       ,011ACE1F285A54010E
     mId        0002
     peerFriend peerSens,peerVirt
     peerOpt    3:switch
     regLst     0,1,3p
     rxType     1
     supp_Pair_Rep 0
     tmplChg    0
     ack:
     cmds:
       TmplKey    self01,:1596381400.884:1596381400.8987
       TmplTs     1596381400.8987
       cmdKey     1:1:0::SwitchUP01:0002:01:self01,
       cmdLst:
         assignHmKey noArg
         clear      [readings|trigger|register|oldRegs|rssi|msgEvents|msgErrors|attack|all]
         deviceRename newName
         eventL     -peer- -cond-
         eventS     -peer- -cond-
         fwUpdate   -filename- -bootTime- ...
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  [List0|List1|List2|List3|List4|List5|List6] ... [-PeerChannel-]
         getSerial  noArg
         getVersion noArg
         inhibit    [on|off]
         off        noArg
         on         noArg
         on-for-timer -ontime-
         on-till    -time-
         pair       noArg
         peerBulk   -peer1,peer2,...- [set|unset]
         peerIODev  [IO] -btn- [set|unset]... not for future use
         peerSmart  -peerOpt-
         press      [long|short] -peer- [-repCount(long only)-] [-repDelay-] ...
         pressL     -peer-
         pressS     -peer-
         raw        data ...
         regBulk    -list-.-peerChn- -addr1:data1- -addr2:data2- ...
         regSet     [prep|exec] -regName- -value- ... [-peerChannel-]
         reset      noArg
         sign       [on|off]
         statusRequest noArg
         toggle     noArg
         tplDel     tmplt
         tplSet_0   -tplChan-
         tplSet_self01 -tplPeer-
         unpair     noArg
       lst:
         peer       self01
         peerOpt    Fenster.Bad,SDTeam_Btn1,SwitchES01_SenF,SwitchES01_SenI,SwitchES01_SenPwr,SwitchES01_SenU,SwitchPBU01_Btn_01,SwitchPBU01_Btn_02,SwitchPBU02_Btn_01,SwitchPBU02_Btn_02,Tuer.SZ,Tuer.WZ.Terrasse,VentilControler.AZ.Nord_Btn1,VentilControler.AZ.West_Btn1,VentilControler.Bad_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,ccu_Btn2,ccu_Btn3,ccu_Btn4,ccu_Btn5,virtAktorAlarmOff_Btn1
         tplChan   
         tplDel     
         tplPeer    toggleOn-for-timerOff_switch_long,SwOff_short,SwOnCond_long,motionOnSw_short,SwToggle_long,SwOnCond_short,ignore_short,SwCondBelow_short,SwCondAbove_short,SwToggleIgnore,SwOn_long,autoOff_short,SwOff_long,SwToggle_short,ignore_long,motionOnSw_long,toggleOn-for-timerOff_switch_short,SwOn_short,SwCondBelow_long,SwCondAbove_long,autoOff_long
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     io:
       newChn     +285A54,00,00,00
       nextSend   1596403263.5618
       rxt        0
       vccu       ccu
       p:
         285A54
         00
         00
         00
       prefIO:
         cul868
     mRssi:
       mNo        74
       io:
         cul868:
           -70
           -70
         hmlan1:
           -64
           -64
         hmuart1:
         hmusb1:
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         cul868
       flg        A
       ts         1596403263.46248
       ack:
         HASH(0x43e59c8)
         7480021ACE1F285A5400
     rssi:
       at_cul868:
         avg        -72
         cnt        1
         lst        -72
         max        -72
         min        -72
       at_hmlan1:
         avg        -64
         cnt        1
         lst        -64
         max        -64
         min        -64
       cul868:
         avg        -73
         cnt        1
         lst        -73
         max        -73
         min        -73
     shadowReg:
     tmpl:
Attributes:
   .mId       0004
   IODev      hmlan1
   IOgrp      ccu:cul868
   actCycle   001:00
   actStatus  alive
   autoReadReg 5_readMissing
   devStateIcon on:on:off off:off:on timedOn:on-for-timer:off
   event-on-change-reading .*
   expert     defReg,allReg,rawReg,templ
   firmware   1.12
   group      Beleuchtung
   model      HM-LC-SW1-FM
   peerIDs    00000000,285A5401,
   room       65_Flur.OG
   serialNr   LEQ0130409
   stateFormat {if(ReadingsVal($name,"timedOn","off")eq"running"){return "timedOn";}else{return ReadingsVal($name,"state","off");}}
   subType    switch
   webCmd     statusRequest:toggle:on:off

der manuelle update hat den switch wiederbelebt.

vorher war der switch ca 1 std nach dem letzten restart heute nachmittag ununterbrochen dead.
da hätten also ca 6 statusrequest kommen müssen, die ich im log aber nicht sehen kann, obwohl der switch gesnifft wird.

Code Auswählen Erweitern

2020.08.02 17:16:21.663 3: Device SwitchUP01 added to ActionDetector with 001:00 time
2020-08-02 18:20:55   Activity        dead


dieser fehler ist eventuell auch schon uralt und fällt jetzt nur auf, da ich seit 20.06.2020 nach fhem restart keine statusrequests mehr sehen kann. wie gesagt, "belebt" ja eine aktion den actAutoTry mechanismus.

vor dem 20.06. wurden alle devices nach restart regelmässig abgefragt.
ich vermute mal, das war der zeitpunkt, als du das startverhalten von cul_hm "optimiert / beschleunigt" hast.

[martinp876]

Damit ich es verstehe:
1) das Device war "dead"
2) ActionDetector: Update
3) Das Device "lebt"

=> Ich sehe, dass eine Msg gesendet wurde, Das dürfte der Statusrequest gewesen sein. Wenn es sonst keiner war wäre es auch durch den normalen Zyklus passiert.

Action-detector ist "performance-schonend" implementiert. Es pollt/prüft den Status der Devices entsprechend den Einstellungen "attr ActionDetector actCycle" im Format sss. Default ist 600 (10 min)

Ein Status-Request wird bei Ausfall getriggert - und dann 4mal bei jeden Actiondetectro update. Danach wird nur noch bei jedem 4. Aufruf geprüft. Also per default alle 40min.

Kann das sein= Hast du gewartet?

[frank]

Damit ich es verstehe:
1) das Device war "dead"
2) ActionDetector: Update
3) Das Device "lebt"

richtig.

=> Ich sehe, dass eine Msg gesendet wurde, Das dürfte der Statusrequest gewesen sein. Wenn es sonst keiner war wäre es auch durch den normalen Zyklus passiert.

falsch!

das ist doch das problem.
manchmal nach restart gibt es keinen "normalen" zyklus.
überhaupt nicht, nie, nicht einen einzigen request.

der zyklus startet dann erst:
1. wenn irgend eine message vom device empfangen wird.
2. wie gezeigt durch einen manuellen update vom actiondetector.
3. durch ändern des attributes actCycle.
4. oder mit etwas glück durch einen weiteren fhem restart. 

wenn der zyklus nicht direkt nach fhem restart startet, dann startet er niemals automatisch.
beim fhem restart entscheidet sich, ob autoTry funktioniert, oder nicht.



hier mal die events von Activity zu dem switsch.  die einträge mit den minuszeichen sind fhem restarts:

Code Auswählen Erweitern

03-Aug 13:12:46  ----------
03-Aug 11:49:19  SwitchUP01 Activity: alive
03-Aug 11:39:19  SwitchUP01 Activity: unknown
03-Aug 11:10:12  ----------
02-Aug 23:22:48  SwitchUP01 Activity: alive (manueller ad-update)
02-Aug 18:20:55  SwitchUP01 Activity: dead
02-Aug 17:55:55  SwitchUP01 Activity: unknown
02-Aug 17:16:45  ----------
02-Aug 09:32:33  SwitchUP01 Activity: alive
01-Aug 13:56:46  SwitchUP01 Activity: dead
01-Aug 13:51:46  SwitchUP01 Activity: unknown
01-Aug 12:52:38  ----------


vom restart bis zum manuellen update (ca 7 stunden) gab es keinen request.
wie im list zu sehen, war actCycle=001:00.
anschliessend, nach dem update, kamen die requests sauber bis zum nächsten restart (ca 12 stunden).
wenn die requests kommen, sind die intervalle immer ein paar minuten länger, als actCycle.
es gibt auch nie aussetzer oder wiederholungen. wenn sie kommen, dann sind sie einwandfrei.



hier ein beispiel;
hmlan lauscht, ein cul sendet. das letzte ack kommt eventuell etwas zu schnell, aber egal.

Code Auswählen Erweitern

2020.08.03 12:42:09.579 3: CUL_HM set SwitchUP01 statusRequest
2020.08.03 12:42:09.620 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:54807E5E d:FF r:FFCD     m:6D A001 1ACE1F 285A54 010E
2020.08.03 12:42:09.859 0: HMLAN_Parse: hmlan1 R:E285A54   stat:0000 t:54807EDE d:FF r:FFC0     m:6D A410 285A54 1ACE1F 060100004C
2020.08.03 12:42:09.876 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:54807F5E d:FF r:FFCC     m:6D 8002 1ACE1F 285A54 00



ich habe leider noch keinen weg gefunden, den fehler 100-prozentig zu reproduzieren.
das angesprochene und vermutete toggeln nach jedem restart, hat sich leider nicht auf dauer bestätigt.
bei längeren zeiten von actCycle kommt das problem scheinbar häufiger vor.


am besten du testest es mal selber.
nimm einen switch mit actCycle=1std und mach hin und wieder einen fhem restart.

[martinp876]

Natürlich teste ich selbst. Was meinst du wie viele restarts mein komplettes System am Wochenende macht 

Deine logs sind hilfreich.

[frank]

eventuell wieder nur zufall.
aber mit folgender aktion war die "statusRequest-blockade" jetzt gleich bei 3 switch-devices gleichzeitig nach restart.

bei einem festerkontakt:
1. getconfig (nur abfeuern für pending cmds, nicht abarbeiten)
2. clear msgEvents
3. restart

so bleibt cfgState ewig auf updating.

Code Auswählen Erweitern

Internals:
   DEF        1DE620
   FUUID      5c4ce2e9-f33f-09c4-0cb4-ff17181d27954a49
   IODev      hmlan1
   NAME       Tuer.SZ
   NOTIFYDEV  global
   NR         297
   NTFY_ORDER 50-Tuer.SZ
   STATE      Tuer:closed (to ccu), Status:closed, Sabotage:on, Bat:ok
   TYPE       CUL_HM
   chanNo     01
   peerList   SwitchPBU03,SwitchPBU06,
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   .attrtocr:
     .*
   READINGS:
     from archivexx        .D-devInfo      810101
     from archivexx        .D-stc          80
     2020-08-08 16:30:27   .associatedWith Tuer.SZ,Tuer.SZ,SwitchPBU03,SwitchPBU06
     2020-08-07 14:40:04   .peerListRDate  2020-08-07 14:40:04
     2020-08-08 14:33:57   .protLastRcv    2020-08-08 14:33:57
     2020-06-27 15:54:23   Activity        alive
     2020-04-14 15:41:35   CommandAccepted yes
     from archivexx        D-firmware      2.0
     from archivexx        D-serialNr      JEQ0644828
     2020-04-14 14:15:00   PairedTo        0x1ACE1F
     2020-08-08 16:30:43   R-cyclicInfoMsg on
     2020-08-08 16:30:44   R-eventDlyTime  0 s
     2020-08-08 16:30:44   R-ledOnTime     0.5 s
     2020-08-08 16:30:44   R-msgScPosA     closed
     2020-08-08 16:30:44   R-msgScPosB     open
     2020-08-08 16:30:43   R-pairCentral   0x1ACE1F
     2020-08-08 16:30:43   R-sabotageMsg   on
     2020-08-08 16:30:44   R-sign          off
     2020-08-08 16:30:43   R-transmDevTryMax 6
     2020-08-08 16:30:44   R-transmitTryMax 6
     2019-11-10 15:11:06   RegL_00.        00:00 02:01 09:01 0A:1A 0B:CE 0C:1F 10:01 14:06
     2019-11-10 15:11:07   RegL_01.        00:00 08:00 20:60 21:00 22:64 30:06
     2020-04-14 14:15:01   aesReqTo        ccu
     2020-04-14 14:14:50   alive           yes
     2020-06-08 13:09:37   battery         ok
     2020-08-08 16:26:03   cfgState        updating
     2020-08-08 16:27:03   commState       Info_Cleared
     2020-08-08 14:33:57   contact         closed (to ccu)
     2020-08-08 16:30:27   peerList        SwitchPBU03,SwitchPBU06,
     2020-08-07 14:37:26   powerOn         2020-08-07 14:37:26
     2020-05-10 10:50:17   recentStateType info
     2020-08-06 17:52:27   sabotageError   on
     2020-08-07 14:42:43   state           closed
     2020-08-07 14:42:43   trigger_cnt     4
   helper:
     HM_CMDNR   206
     mId        002F
     peerFriend peerAct,peerVirt
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     4
     tmplChg    0
     cfgChk:
       idRc01     RegL_04.SwitchPBU03_chn-01,RegL_04.SwitchPBU06_chn-01
     cmds:
       TmplKey    SwitchPBU03,SwitchPBU06,:1596897044.14558:1596897044.16368
       TmplTs     1596897044.16368
       cmdKey     1:1:0::Tuer.SZ:002F:01:SwitchPBU03,SwitchPBU06,
       cmdLst:
         assignHmKey noArg
         clear      [readings|trigger|register|oldRegs|rssi|msgEvents|msgErrors|attack|all]
         deviceRename newName
         fwUpdate   -filename- -bootTime- ...
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  [List0|List1|List2|List3|List4|List5|List6] ... [-PeerChannel-]
         peerBulk   -peer1,peer2,...- [set|unset]
         peerChan   -btnNumber- -actChn- ... single [set|unset] [actor|remote|both]
         peerSmart  -peerOpt-
         raw        data ...
         regBulk    -list-.-peerChn- -addr1:data1- -addr2:data2- ...
         regSet     [prep|exec] -regName- -value- ... [-peerChannel-]
         reset      noArg
         sign       [on|off]
         tplDel     tmplt
         tplSet_0   -tplChan-
         tplSet_SwitchPBU03 -tplPeer-
         tplSet_SwitchPBU06 -tplPeer-
         trgEventL  [-peer-] -condition-
         trgEventS  [-peer-] -condition-
         trgPressL  [-peer-]
         trgPressS  [-peer-]
         unpair     noArg
       lst:
         peer       SwitchPBU03,SwitchPBU06
         peerOpt    remove_SwitchPBU03,remove_SwitchPBU06,DimPBU01_Sw1_V01,DimPBU01_Sw1_V02,DimPBU01_chn01,DimUP01,HM_114B05,SDTeam_Btn1,SwitchES01_Sw,SwitchPBU01_Sw_01,SwitchPBU01_Sw_02,SwitchPBU02_Sw_01,SwitchPBU02_Sw_02,SwitchPBU04,SwitchPBU05,SwitchPBU07,SwitchPBU08,SwitchPBU09,SwitchUP01,SwitchUP02,VentilControler.AZ.Nord_Btn1,VentilControler.AZ.West_Btn1,VentilControler.Bad_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,ccu_Btn2,ccu_Btn3,ccu_Btn4,ccu_Btn5,virtAktorAlarmOff_Btn1
         tplChan    single-chn-sensor-device
         tplDel     
         tplPeer   
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     io:
       newChn     +1DE620,00,00,00
       rxt        0
       vccu       ccu
       p:
         1DE620
         00
         00
         00
       prefIO:
         hmlan1
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   00
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
     shadowReg:
     tmpl:
Attributes:
   .mId       002F
   IODev      hmlan1
   IOgrp      ccu:hmlan1
   actCycle   028:00
   actStatus  alive
   autoReadReg 5_readMissing
   comment    Lueftung
   event-on-change-reading .*
   expert     defReg,allReg,rawReg,templ
   firmware   2.0
   group      Alarmmelder
   model      HM-SEC-SC
   peerIDs    00000000,25E38E01,3913D301,
   room       01_ALARM,50_SZ
   serialNr   JEQ0644828
   stateFormat Tuer:contact, Status:state, Sabotage:sabotageError, Bat:battery
   subType    threeStateSensor
   timestamp-on-change-reading .*
   webCmd     getConfig:clear msgEvents

[martinp876]

nun - in der Abfrage kann  ich immer noch keine Lücke entdecken. Möglich, dass der timer nicht gestartet wird..... Damit wäre der gesamte Action-Detector abgeschaltet.

Wenn es hängt könntest du einmal

Code Auswählen Erweitern

{join("\n",grep /Action/,sort map{sprintf("%8d",int($intAt{$_}{TRIGGERTIME}-gettimeofday())).":$intAt{$_}{FN}\t$intAt{$_}{ARG}"} (keys %intAt))}

ausführen. Hier solltest du den nächsten Ausführungszeitpunkt des ActionDetectors sehen. Wenn nichts kommt haben wir das Problem gefunden.

[frank]

von den besagten 3 switches, die nach dem letzten restart dead waren, sind augenblicklich noch 2 dead.

Code Auswählen Erweitern

419:CUL_HM_ActCheck ActionDetector
die zeit zählt runter, der actiondetector lebt.


das dritte device wurde gegen 01 uhr 11 wiederbelebt, da zu dieser zeit ein tägliches at den switch immer ausschaltet.
anschliessend kommen die statusRequests regelmässig (actCycle=000:30). vorher bis 01 uhr 11 keine statusRequests.

Code Auswählen Erweitern

2020-08-08_16:30:23 global INITIALIZED
2020-08-08_16:30:24 SwitchPBU03 Activity: alive
2020-08-08_16:30:29 SwitchPBU03 cfgState: ok
2020-08-08_16:44:58 SwitchPBU03 Activity: unknown
2020-08-08_17:04:58 SwitchPBU03 Activity: dead
2020-08-09_01:11:14 SwitchPBU03 commState: CMDs_pending
2020-08-09_01:11:14 SwitchPBU03 set_off
2020-08-09_01:11:14 SwitchPBU03 commState: CMDs_processing...
2020-08-09_01:11:14 SwitchPBU03 commState: CMDs_done
2020-08-09_01:11:14 SwitchPBU03 off
2020-08-09_01:15:09 SwitchPBU03 Activity: alive
2020-08-09_01:45:11 SwitchPBU03 commState: CMDs_pending
2020-08-09_01:45:11 SwitchPBU03 commState: CMDs_processing...
2020-08-09_01:45:11 SwitchPBU03 commState: CMDs_done
2020-08-09_02:20:12 SwitchPBU03 commState: CMDs_pending
2020-08-09_02:20:12 SwitchPBU03 commState: CMDs_processing...
2020-08-09_02:20:12 SwitchPBU03 commState: CMDs_done
2020-08-09_02:55:13 SwitchPBU03 commState: CMDs_pending
2020-08-09_02:55:13 SwitchPBU03 commState: CMDs_processing...
2020-08-09_02:55:13 SwitchPBU03 commState: CMDs_done
2020-08-09_03:30:13 SwitchPBU03 commState: CMDs_pending
2020-08-09_03:30:14 SwitchPBU03 commState: CMDs_processing...
2020-08-09_03:30:14 SwitchPBU03 commState: CMDs_done
2020-08-09_04:05:14 SwitchPBU03 commState: CMDs_pending
2020-08-09_04:05:14 SwitchPBU03 commState: CMDs_processing...
2020-08-09_04:05:14 SwitchPBU03 commState: CMDs_done
2020-08-09_04:40:15 SwitchPBU03 commState: CMDs_pending
2020-08-09_04:40:15 SwitchPBU03 commState: CMDs_processing...
2020-08-09_04:40:15 SwitchPBU03 commState: CMDs_done
2020-08-09_05:15:16 SwitchPBU03 commState: CMDs_pending
2020-08-09_05:15:16 SwitchPBU03 commState: CMDs_processing...
2020-08-09_05:15:16 SwitchPBU03 commState: CMDs_done
2020-08-09_05:50:17 SwitchPBU03 commState: CMDs_pending
2020-08-09_05:50:17 SwitchPBU03 commState: CMDs_processing...
2020-08-09_05:50:17 SwitchPBU03 commState: CMDs_done
2020-08-09_06:25:18 SwitchPBU03 commState: CMDs_pending
2020-08-09_06:25:18 SwitchPBU03 commState: CMDs_processing...
2020-08-09_06:25:18 SwitchPBU03 commState: CMDs_done
2020-08-09_07:00:18 SwitchPBU03 commState: CMDs_pending
2020-08-09_07:00:18 SwitchPBU03 commState: CMDs_processing...
2020-08-09_07:00:18 SwitchPBU03 commState: CMDs_done
2020-08-09_07:35:19 SwitchPBU03 commState: CMDs_pending
2020-08-09_07:35:19 SwitchPBU03 commState: CMDs_processing...
2020-08-09_07:35:19 SwitchPBU03 commState: CMDs_done
2020-08-09_08:10:20 SwitchPBU03 commState: CMDs_pending
2020-08-09_08:10:20 SwitchPBU03 commState: CMDs_processing...
2020-08-09_08:10:20 SwitchPBU03 commState: CMDs_done
2020-08-09_08:45:21 SwitchPBU03 commState: CMDs_pending
2020-08-09_08:45:21 SwitchPBU03 commState: CMDs_processing...
2020-08-09_08:45:21 SwitchPBU03 commState: CMDs_done
2020-08-09_09:20:22 SwitchPBU03 commState: CMDs_pending
2020-08-09_09:20:22 SwitchPBU03 commState: CMDs_processing...
2020-08-09_09:20:22 SwitchPBU03 commState: CMDs_done
2020-08-09_09:55:22 SwitchPBU03 commState: CMDs_pending
2020-08-09_09:55:22 SwitchPBU03 commState: CMDs_processing...
2020-08-09_09:55:23 SwitchPBU03 commState: CMDs_done
2020-08-09_10:30:23 SwitchPBU03 commState: CMDs_pending
2020-08-09_10:30:23 SwitchPBU03 commState: CMDs_processing...
2020-08-09_10:30:23 SwitchPBU03 commState: CMDs_done
2020-08-09_11:05:24 SwitchPBU03 commState: CMDs_pending
2020-08-09_11:05:24 SwitchPBU03 commState: CMDs_processing...
2020-08-09_11:05:24 SwitchPBU03 commState: CMDs_done
2020-08-09_11:40:25 SwitchPBU03 commState: CMDs_pending
2020-08-09_11:40:25 SwitchPBU03 commState: CMDs_processing...
2020-08-09_11:40:25 SwitchPBU03 commState: CMDs_done


[noansi]

Hallo Frank,

bist Du bei der Version 10_CUL_HM.pm aktuell?

.protLastRcv hat in Deinen lists nicht das aktuelle Format. Aktuell sind darin die -, ,: entfernt und der code macht damit einen Vergleich auf gt zum erwarteten Eventeintritt.

Zeile 9476ff:

Code Auswählen Erweitern

      my $tLast = ReadingsVal($devName,".protLastRcv",0);
      my @t = localtime($tod - $tSec); #time since when a trigger is expected
      my $tSince = sprintf("%04d%02d%02d%02d%02d%02d",
                             $t[5]+1900, $t[4]+1, $t[3], $t[2], $t[1], $t[0]);
      if (!$tLast                  #cannot determine time
          || $tSince gt $tLast){   #no message received in window

Mit altem Readingsformat klappt das nicht sinnvoll.
Alte Readings müssen durch Protkollaktivität auf neuen Stand gebracht werden.

Gruß, Ansgar.

[frank]

.protLastRcv hat in Deinen lists nicht das aktuelle Format. Aktuell sind darin die -, ,: entfernt und der code macht damit einen Vergleich auf gt zum erwarteten Eventeintritt.

danke für den hinweis noansi.

top aktuell war mein cul_hm bis eben nicht. meine 22516 vom 02.08. hatte noch durchgehend das alte reading format, aber trotzdem den "gt" vergleich.

das update hat aber keine verbesserung bezüglich der ausbleibenden requests gebracht.
daher vermute ich immer noch eine "blockade" in der statusRequest queue.


bei zwei switches mit actcycle=000:30 starteten die requests zwar relativ zügig nach restart, aber eigentlich auch zu spät, da erst dead gemeldet wurde, bevor 10 min später der erste request kam.

eigentlich müsste schon das erste "unknown" entfallen, meine ich.
das device war gerade noch vor dem restart alive und alle daten sollten vorhanden sein, so dass ein einfacher restart "geräuschlos" durchgeführt werden könnte.

Code Auswählen Erweitern

2020-08-09_17:03:09 global INITIALIZED
2020-08-09_17:14:57 SwitchPBU03 commState: CMDs_pending
2020-08-09_17:14:57 SwitchPBU03 commState: CMDs_processing...
2020-08-09_17:14:57 SwitchPBU03 commState: CMDs_done
2020-08-09_17:17:05 global INITIALIZED
2020-08-09_17:46:40 SwitchPBU03 Activity: unknown
2020-08-09_17:46:40 ActionDetector status_SwitchPBU03: unknown
2020-08-09_17:51:40 SwitchPBU03 Activity: dead
2020-08-09_17:51:40 ActionDetector status_SwitchPBU03: dead
2020-08-09_18:01:42 SwitchPBU03 commState: CMDs_pending
2020-08-09_18:01:42 SwitchPBU03 commState: CMDs_processing...
2020-08-09_18:01:42 SwitchPBU03 commState: CMDs_done
2020-08-09_18:06:41 SwitchPBU03 Activity: alive
2020-08-09_18:06:41 ActionDetector status_SwitchPBU03: alive
2020-08-09_18:36:43 SwitchPBU03 commState: CMDs_pending
2020-08-09_18:36:43 SwitchPBU03 commState: CMDs_processing...
2020-08-09_18:36:43 SwitchPBU03 commState: CMDs_done
2020-08-09_19:11:44 SwitchPBU03 commState: CMDs_pending
2020-08-09_19:11:44 SwitchPBU03 commState: CMDs_processing...
2020-08-09_19:11:44 SwitchPBU03 commState: CMDs_done




der dritte "tote" switch hat nach über 2 stunden noch keinen request bekommen.

Code Auswählen Erweitern

2020-08-09_17:03:09 global INITIALIZED
2020-08-09_17:13:54 SwitchUP01 commState: CMDs_pending
2020-08-09_17:13:54 SwitchUP01 commState: CMDs_processing...
2020-08-09_17:13:54 SwitchUP01 commState: CMDs_done
2020-08-09_17:17:05 global INITIALIZED
2020-08-09_18:16:41 SwitchUP01 Activity: unknown
2020-08-09_18:16:41 ActionDetector status_SwitchUP01: unknown
2020-08-09_18:21:41 SwitchUP01 Activity: dead
2020-08-09_18:21:41 ActionDetector status_SwitchUP01: dead


[frank]

moin,
hier nochmal 2 auffälligkeiten, die eventuell einen hinweis liefern können.


1. für mich unerklärliches zeitraster beim actiondetector für die erste dead meldung

vorweg: mein actiondetector hat kein attr actCycle und sollte somit im 10 min raster aktiv sein.

Activity-events der 3 switches zwischen 2 restarts:

Code Auswählen Erweitern

10-Aug 07:35:24  ----------
09-Aug 23:47:58  SwitchUP01 Activity: alive
09-Aug 23:32:57  SwitchUP01 Activity: dead
09-Aug 23:17:57  SwitchPBU06 Activity: alive
09-Aug 23:17:57  SwitchUP01 Activity: unknown
09-Aug 23:17:57  SwitchPBU03 Activity: alive
09-Aug 23:02:56  SwitchPBU06 Activity: dead
09-Aug 23:02:56  SwitchPBU03 Activity: dead
09-Aug 22:37:56  SwitchPBU06 Activity: unknown
09-Aug 22:37:56  SwitchPBU03 Activity: unknown
09-Aug 22:28:48  ----------

wenn ich nun die minuten im timestamp der ersten meldung nach restart als "raster" für den actiondetector annehme, müssten doch bei allen meldungen die minuten der timestamps in dieses raster passen.

also in diesem beispiel:
erster timestamp zeigt 37 minuten => folglich sollten ja alle weiteren minutenangaben aus dieser menge sein (07, 17, 27, 37, 47, 57).
komischerweise passt das immer bis auf die dead meldungen. die dead meldungen sind immer exakt 5 minuten zum actiondetector raster "verschoben/verzögert".

wo kommt dieser delay her?



2. autoReadTest anzeige aus "get hminfo protoEvents"

nach restart stehen hier zunächst alle parent devices. auch alle ignored devices.

a. es hat eben sicherlich über eine halbe stunde gedauert, bis "bewegung" in diese liste kam. plötzlich war sie leer.
ist es richtig, dass das so lange dauert?
wenn ich mich nicht täusche, war die liste neulich noch innerhalb kürzester zeit (ein paar sekunden?) nach restart leer.

b. sollten ignored devices in dieser liste besser gar nicht erscheinen?
könnten diese devices hier zu einer verzögerung beitragen?

[martinp876]

1. Der actiondetector startet sich 10min nach dem finish. Sollte der start durch andere Prozesse verzögert werden verschiebt sich alles. Weiter wird die dauer addiert. Mehr kann ich mir nicht erklären.
Ach: wird ein update manuell gestartet werden die 10min ab hier gezählt.

2 ob die Status queue hängen kann prüfe ich. Ignore devices werden jedoch sowieso nicht gesendet

[frank]

hallo martin,

die requests werden in der funktion CUL_HM_qStateUpdatIfEnab($@) durch "next if(...);" aussortiert.
ich habe mal ein paar logmeldungen eingebaut:

Code Auswählen Erweitern

sub CUL_HM_qStateUpdatIfEnab($@){#in:name or id, queue stat-request
  my ($name,$force) = @_;
  Log(1,"----- request0 ----- => $name - ".($force?$force:"no_force"));
  $name = substr($name,6) if ($name =~ m/^sUpdt:/);
  $name = CUL_HM_id2Name($name) if ($name =~ m/^[A-F0-9]{6,8}$/i);
  $name =~ s/_chn-\d\d$//;
  Log(1,"----- request1 ----- => $name - ".($force?$force:"no_force"));
  my $ret = 0;
  foreach my $chNm(CUL_HM_getAssChnNames($name)){
    Log(1,"----- request2 ----- => $name - $chNm");
    next if (  !$defs{$chNm}                  #device unknown, ignore
               || 0 == CUL_HM_SearchCmd($chNm,"statusRequest"));
    Log(1,"----- request3 ----- => $name - $chNm");
    if ($force || ((CUL_HM_getAttrInt($chNm,"autoReadReg") & 0x0f) > 3)){
      Log(1,"----- request4 ----- => $name - $chNm");
      CUL_HM_qEntity($chNm,"qReqStat");
      $ret = 1;
      Log(1,"----- request5 ----- => $name - $chNm");
    }
  }
  return $ret;
}


log, wenn alle requests der 3 switche verworfen werden (1. versuch nach restart):

Code Auswählen Erweitern

2020.08.10 17:49:15.939 1: ----- request0 ----- => SwitchPBU03 - 1
2020.08.10 17:49:15.940 1: ----- request1 ----- => SwitchPBU03 - 1
2020.08.10 17:49:15.941 1: ----- request2 ----- => SwitchPBU03 - SwitchPBU03
2020.08.10 17:49:15.959 1: ----- request0 ----- => SwitchUP01 - 1
2020.08.10 17:49:15.959 1: ----- request1 ----- => SwitchUP01 - 1
2020.08.10 17:49:15.960 1: ----- request2 ----- => SwitchUP01 - SwitchUP01
2020.08.10 17:49:15.977 1: ----- request0 ----- => SwitchPBU06 - 1
2020.08.10 17:49:15.978 1: ----- request1 ----- => SwitchPBU06 - 1
2020.08.10 17:49:15.978 1: ----- request2 ----- => SwitchPBU06 - SwitchPBU06



ab hier kommt der request für SwitchUP01 ans ziel:

Code Auswählen Erweitern

2020.08.10 18:29:16.973 1: ----- request0 ----- => SwitchPBU03 - 1
2020.08.10 18:29:16.974 1: ----- request1 ----- => SwitchPBU03 - 1
2020.08.10 18:29:16.975 1: ----- request2 ----- => SwitchPBU03 - SwitchPBU03
2020.08.10 18:29:16.976 1: ----- request0 ----- => SwitchUP01 - 1
2020.08.10 18:29:16.976 1: ----- request1 ----- => SwitchUP01 - 1
2020.08.10 18:29:16.977 1: ----- request2 ----- => SwitchUP01 - SwitchUP01
2020.08.10 18:29:16.977 1: ----- request3 ----- => SwitchUP01 - SwitchUP01
2020.08.10 18:29:16.977 1: ----- request4 ----- => SwitchUP01 - SwitchUP01
2020.08.10 18:29:16.979 1: ----- request5 ----- => SwitchUP01 - SwitchUP01
2020.08.10 18:29:16.979 1: ----- request0 ----- => SwitchPBU06 - 1
2020.08.10 18:29:16.980 1: ----- request1 ----- => SwitchPBU06 - 1
2020.08.10 18:29:16.980 1: ----- request2 ----- => SwitchPBU06 - SwitchPBU06
2020.08.10 18:29:17.998 3: CUL_HM set SwitchUP01 statusRequest
2020.08.10 18:29:18.039 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:79CC1810 d:FF r:FFC8     m:01 A001 1ACE1F 285A54 010E
2020.08.10 18:29:18.276 0: HMLAN_Parse: hmlan1 R:E285A54   stat:0000 t:79CC1890 d:FF r:FFC0     m:01 A410 285A54 1ACE1F 060100004D
2020.08.10 18:29:18.294 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:79CC1910 d:FF r:FFC8     m:01 8002 1ACE1F 285A54 00


ansonnsten versucht der actiondetector regelmässig alle 10 min einen neuen request für die devices, die noch nicht durchgekommen sind.


hier noch der eventlog dazu:

Code Auswählen Erweitern

10-Aug 18:34:17  SwitchUP01 Activity: alive
10-Aug 17:49:15  SwitchPBU06 Activity: dead
10-Aug 17:49:15  SwitchUP01 Activity: dead
10-Aug 17:49:15  SwitchPBU03 Activity: dead
10-Aug 17:44:15  SwitchPBU06 Activity: unknown
10-Aug 17:44:15  SwitchUP01 Activity: unknown
10-Aug 17:44:15  SwitchPBU03 Activity: unknown
10-Aug 17:15:03  ----------