"undefinedTrigger" bei HM-Sen-MDIR-O nach configCheck in HMInfo

[scooty]

Hallo zusammen,

nach einem configCheck in HMInfo wird für meine beiden HM-Sen-MDIR-O-2 (BKOG_SEN/SZOG_SEN) folgende Ausgabe erzeugt:

Code Auswählen Erweitern

configCheck done:

peer unknown trigger
    undefinedTrigger: BKOG_SEN:F10000
    undefinedTrigger: SZOG_SEN:F10000

Eine Suche nach "undefinedTrigger" hier im Forum brachte mich nur zu diesem Thema, Google den Verweis auf diesen Code-Change.

Gebe ehrlich zu, dass ich nicht so tief in der Materie drin bin, um die Suchergebnisse interpretieren zu können, daher meine Frage hier:
Was ist die Bedeutung o.a. Meldungen?

Keiner der HM-Sen-MDIR-O-2 ist mit anderen Devices gepeert.

Hier noch ein list auf einen der HM-Sen-MDIR-O-2:

Code Auswählen Erweitern

Internals:
   CUL_HM_MSGCNT 634
   CUL_HM_RAWMSG A0D85841027DDA1F100000601DF00::-51.5:CUL_HM
   CUL_HM_RSSI -51.5
   CUL_HM_TIME 2014-07-23 13:18:04
   DEF        27DDA1
   IODev      CUL_HM
   LASTInputDev CUL_HM
   MSGCNT     634
   NAME       BKOG_SEN
   NR         194
   STATE      motion
   TYPE       CUL_HM
   lastMsg    No:85 - t:10 s:27DDA1 d:F10000 0601DF00
   protLastRcv 2014-07-23 13:18:04
   protSnd    372 last_at:2014-07-23 12:07:04
   protState  CMDs_done
   rssi_at_CUL_HM avg:-50 min:-61.5 max:-46 lst:-51.5 cnt:634
   Readings:
     2014-07-21 21:41:02   Activity        alive
     2014-07-21 21:37:49   CommandAccepted yes
     2014-07-21 21:37:48   D-firmware      1.6
     2014-07-21 21:37:48   D-serialNr      LEQ0161148
     2014-07-21 21:37:49   PairedTo        0xF10000
     2014-07-21 21:37:49   R-brightFilter  2
     2014-07-21 21:37:49   R-captInInterval off
     2014-07-21 21:37:49   R-evtFltrNum    1
     2014-06-06 21:19:03   R-evtFltrPeriod 3 s
     2014-06-06 21:04:54   R-ledOnTime     0 s
     2014-07-21 21:37:49   R-minInterval   30
     2014-07-21 21:37:49   R-pairCentral   0xF10000
     2014-07-21 21:37:49   RegL_00:        02:01 0A:F1 0B:00 0C:00 00:00
     2014-07-21 21:37:49   RegL_01:        01:16 02:21 08:00 22:00 00:00
     2014-07-23 13:18:04   battery         ok
     2014-07-23 13:18:04   brightness      223
     2014-07-23 13:18:04   cover           closed
     2014-07-23 12:07:04   motion          on (to CUL_HM)
     2014-07-23 12:07:04   motionCount     55_next:14s
     2014-07-23 13:18:04   recentStateType info
     2014-07-23 12:07:04   state           motion
     2014-07-23 12:07:04   trigDst_F10000  noConfig
   Helper:
     mId        00C1
     rxType     28
     Io:
       newChn     +27DDA1,00,01,1E
       nextSend   1406114284.24228
       prefIO
       rxt        2
       vccu
       p:
         27DDA1
         00
         01
         1E
     Mrssi:
       mNo        85
       Io:
         CUL_HM     -49.5
     Prt:
       bErr       0
       sProc      0
       sleeping   1
       Rspwait:
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_cul_hm:
         avg        -50.0078864353312
         cnt        634
         lst        -51.5
         max        -46
         min        -61.5
     Shadowreg:
Attributes:
   IODev      CUL_HM
   actCycle   000:10
   actStatus  alive
   autoReadReg 5_readMissing
   event-on-change-reading battery,motionCount,cover,state
   event-on-update-reading motion,brightness
   expert     2_full
   firmware   1.6
   fp_Rosi2_OG 140,850,6,brightness
   group      OG
   icon       motion_detector
   model      HM-Sen-MDIR-O-2
   peerIDs    00000000
   room       BKOG
   serialNr   LEQ0161148
   subType    motionDetector

Vielen Dank und Grüße,
Andreas

[martinp876]

hatte den Text gerade geändert:
" trigger sent to undefined device"
dein BKOG_SEN hat zumindest einen trigger an die ID F10000 gesendet. FHEM kennt diese nicht als CUL_HM device.

der BKOG_SEN sollte einen entsprechenden Reading-eintrag haben.
Ist das sie ID deines IO? Dann definieren doch eine vccu.

[geek]

Hi Martin,

habe eine VCCU definiert und bekomme beim HMinfo configCheck auch alle devices reported, die nicht gepeert sind:

peer unknown trigger
    undefinedTrigger: eg_bd_fenster_riegel:83D2E0

Kommt auch wieder, wenn ich das trigDst reading im device lösche:
deletereading eg_bd_fenster_riegel trigDst_VCCU

Erst wenn die devices mit irgendwas (zb. auch einem Channel der Vccu) gepeered sind, bleibt die Meldung bei mir aus.

Rane

[martinp876]

Hi Rane,

kannst du einmal rohmessages schicken, wenn der trigger kommt?
Ich denke es hat etwas mit mehrfach gepeerten Kanälen undlong-press zu tun

Gruss Martin

[geek]

Hi Martin,

das sind die raw messages vom Fensterkontakt (267F84). Der ist nicht gepeered. Schickt nur an die Zentrale (83D2E0).

Das sehe ich bei HM-SEC-RHS, HM-SEC-SC-2, HM-SCI-3-FM, HM-Sen-MDIR-O wenn sie keinen peer haben. Wenn ein peer definiert ist (echtes device oder button der vccu) tauchen die nicht als unknown trigger auf.

Code Auswählen Erweitern

2014.07.23 16:59:58.772 0: HMLAN_Parse: HMEG R:E267F84   stat:0000 t:2F22F16F d:FF r:FFCC     m:A4 A641 267F84 83D2E0 019D64
2014.07.23 16:59:58.781 3: rollo eg_bd_rollo=beschattung: gap
2014.07.23 16:59:58.817 3: CUL_HM set eg_f_display_riegel led red
2014.07.23 16:59:58.817 0: HMLAN_Send:  HMEG S:S63BC6E28 stat:  00 t:00000000 d:01 r:63BC6E28 m:53 A011 83D2E0 1D4547 800A01
2014.07.23 16:59:58.829 0: HMLAN_Parse: HMUG R:E267F84   stat:0000 t:20A603F5 d:FF r:FF98     m:A4 A641 267F84 83D2E0 019D64
2014.07.23 16:59:58.849 0: HMLAN_Parse: HMUG R:E83D2E0   stat:0000 t:20A6043F d:FF r:FFB2     m:53 A011 83D2E0 1D4547 800A01
2014.07.23 16:59:58.897 0: HMLAN_Parse: HMUG R:E83D2E0   stat:0000 t:20A6046F d:FF r:FFB2     m:A4 8002 83D2E0 267F84 00
2014.07.23 16:59:58.976 0: HMLAN_Parse: HMEG R:R63BC6E28 stat:0001 t:2F22F240 d:FF r:FFE4     m:53 8002 1D4547 83D2E0 010A01001FBFF40012
2014.07.23 16:59:58.998 0: HMLAN_Parse: HMUG R:E1D4547   stat:0000 t:20A604C0 d:FF r:FFAD     m:53 8002 1D4547 83D2E0 010A01001FBFF40012
2014.07.23 17:00:00.170 0: HMLAN_Parse: HMEG R:E221330   stat:0000 t:2F22F6E5 d:FF r:FFD3     m:20 8610 221330 000000 0AF4F60C6458
2014.07.23 17:00:00.187 0: HMLAN_Parse: HMUG R:E221330   stat:0000 t:20A6096A d:FF r:FFB3     m:20 8610 221330 000000 0AF4F60C6458
2014.07.23 17:00:02.772 0: HMLAN_Parse: HMEG R:E267F84   stat:0000 t:2F230110 d:FF r:FFD0     m:A5 A641 267F84 83D2E0 019E00
2014.07.23 17:00:02.776 3: rollo eg_bd_rollo=beschattung: gap
2014.07.23 17:00:02.847 3: CUL_HM set eg_f_display_riegel led off


Code Auswählen Erweitern

fhem> list eg_bd_fenster_riegel
Internals:
   CFGFN      ./cfg/eg_bd.cfg
   DEF        267F84
   HMEG_MSGCNT 23
   HMEG_RAWMSG E267F84,0000,2F230110,FF,FFD0,A5A641267F8483D2E0019E00
   HMEG_RSSI  -48
   HMEG_TIME  2014-07-23 17:00:02
   HMUG_MSGCNT 1
   HMUG_RAWMSG E267F84,0000,20A603F5,FF,FF98,A4A641267F8483D2E0019D64
   HMUG_RSSI  -104
   HMUG_TIME  2014-07-23 16:59:58
   IODev      HMEG
   LASTInputDev HMEG
   MSGCNT     24
   NAME       eg_bd_fenster_riegel
   NR         700
   STATE      closed
   TYPE       CUL_HM
   lastMsg    No:A5 - t:41 s:267F84 d:83D2E0 019E00
   protLastRcv 2014-07-23 17:00:02
   protSnd    23 last_at:2014-07-23 17:00:02
   protState  CMDs_done
   rssi_at_HMEG avg:-61.04 min:-76 max:-48 lst:-48 cnt:23
   rssi_at_HMUG avg:-104 min:-104 max:-104 lst:-104 cnt:1
   Readings:
     2014-07-20 17:56:53   Activity        alive
     2014-06-20 17:57:23   CommandAccepted yes
     2014-06-20 17:57:23   D-firmware      2.4
     2014-06-20 17:57:23   D-serialNr      KEQ1096095
     2014-06-20 17:42:52   PairedTo        0x83D2E0
     2014-06-20 17:57:09   R-cyclicInfoMsg set_on
     2014-06-20 17:42:53   R-eventDlyTime  1 s
     2014-06-20 17:42:53   R-ledOnTime     0.1 s
     2014-06-20 17:31:07   R-msgRhsPosA    closed
     2014-06-20 17:31:07   R-msgRhsPosB    open
     2014-06-20 17:31:07   R-msgRhsPosC    tilted
     2014-06-20 17:31:07   R-pairCentral   0x83D2E0
     2014-06-20 17:31:07   R-transmDevTryMax 6
     2014-06-20 17:31:07   R-transmitTryMax 6
     2014-06-20 17:42:52   RegL_00:        02:01 09:00 0A:83 0B:D2 0C:E0 10:01 14:06 00:00
     2014-06-20 17:42:53   RegL_01:        08:00 20:6C 21:01 22:14 30:06 00:00
     2014-07-14 07:29:28   alive           yes
     2014-07-23 17:00:02   battery         ok
     2014-07-23 17:00:02   contact         closed (to VCCU)
     2014-07-14 07:29:28   cover           closed
     2014-07-14 07:29:28   recentStateType info
     2014-06-20 17:40:07   sabotageAttack  ErrIoAttack cnt:2
     2014-06-20 17:40:07   sabotageAttackId ErrIoId_267F11 cnt:2
     2014-07-23 17:00:02   state           closed
     2014-07-23 17:00:02   trigDst_VCCU    noConfig
   Helper:
     mId        0030
     rxType     4
     Io:
       newChn     +267F84,00,01,FE1F
       nextSend   1406127602.87008
       prefIO     HMEG
       rxt        0
       vccu       VCCU
       p:
         267F84
         00
         01
         FE1F
     Mrssi:
       mNo        A5
       Io:
         HMEG       -46
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf   
       qReqStat   
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMEG
       flg        A
       ts         1406127602.77354
       ack:
         HASH(0xacb8f50)
         A5800283D2E0267F8400
     Rssi:
       At_hmeg:
         avg        -61.0434782608696
         cnt        23
         lst        -48
         max        -48
         min        -76
       At_hmug:
         avg        -104
         cnt        1
         lst        -104
         max        -104
         min        -104
Attributes:
   IODev      HMEG
   IOgrp      VCCU:HMEG
   actCycle   028:00
   actStatus  alive
   autoReadReg 0
   devStateIcon closed:fts_window_1w open:fts_window_1w_open@red tilted:fts_window_1w_tilt@red
   event-on-change-reading .*
   expert     2_full
   firmware   2.4
   group      Riegel
   icon       fts_window_1w
   model      HM-SEC-RHS
   peerIDs    00000000,
   room       eg_bd,eg,D_fenster
   serialNr   KEQ1096095
   structexclude .*:.*
   subType    threeStateSensor


Rainer

[martinp876]

Hallo Rainer

Das sehe ich bei HM-SEC-RHS, HM-SEC-SC-2, HM-SCI-3-FM, HM-Sen-MDIR-O wenn sie keinen peer haben. Wenn ein peer definiert ist (echtes device oder button der vccu) tauchen die nicht als unknown trigger auf.

wenn 83D2E0 die ID des IO ist und nicht als vccu definiert ist, ist es eigentlich keine CUL_HM entity.
wenn du eine vccu mit 83D2E0 definierst sollte es zugewiesen werden können.
Der Trigger geht an die Zentrale und diese ist nicht angelegt.

Gruss Martin

[geek]

Hi Martin,

die VCCU hat 83D2E0 als ID - genauso wie beide HMLAN:

Code Auswählen Erweitern

attr HMEG hmId 83D2E0
attr HMUG hmId 83D2E0

define VCCU CUL_HM 83D2E0
attr VCCU IODev HMEG
attr VCCU IOList HMEG,HMUG
attr VCCU autoReadReg 4_reqStatus
attr VCCU expert 2_full
attr VCCU model CCU-FHEM
attr VCCU room Unsorted
attr VCCU subType virtual



Ich meine - ist eh nur kosmetisch. Und großzügig ausgelegt ist die Aussage "trigger an nicht definiertes Ziel" ja auch nicht wirklich falsch: Die sind halt nicht gepeered.

Rainer

[martinp876]

ist eh nur kosmetisch

"nur"... da ist einiges geschmackssache. Inhaltlich muss es aber passen.

Und da hast du recht. Ich werden 2 Dinge prüfen:
- peering - das Device sendet trigger an nicht in der peerlist existente peers
- undefined - das Device sendet trigger an Peers, die nicht definiert sind.

trigger sent to unpeered device
  triggerUnpeered:....

trigger sent to undefined device
  triggerUndefined: