FHEM Forum

Hallo zusammen,
habe mal eine Verständnissfrage...
Warum steht bei der VCCU als Reading aesKeyNbr auf 04 ?

Habe drei HMLAN adapter im Einsatz:
attr HMLAN1 hmkey 01:xxxxxx
attr HMLAN2 hmkey 01:xxxxxx
attr HMLAN3 hmkey 01:xxxxxx

Finde es irgendwie irre führend, definiert wird hmkey 01:xxxxxx, als reading sehe ich bei den devicen aeskeynbr 02 und bei der vccu dann 04 ..
Und in der Literatur wird der alte Wert ermittelt indem man den aktuellen durch zwei teilt..
Ich kapiers grad nimmer..
Wäre net, wenn mich jemand abholen könnte..

Nachtrag:
Konkret irretiert mich die Meldung:
CUL_HM devicename trig_aes_vccu: ok:2
CUL_HM vccu aesKeyNbr:04

Muss ich mir deswegen Sorgen machen ? (2015-12-21 19:20:29   aesKeyNbr       04)

Internals:
   DEF        29A083
   HMLAN1_MSGCNT 14
   HMLAN1_RAWMSG E29A083,0000,07A8CB0F,FF,FFB2,02800229A0832C083300A1285C88
   HMLAN1_RSSI -78
   HMLAN1_TIME 2015-12-21 19:20:29
   HMLAN2_MSGCNT 56
   HMLAN2_RAWMSG E29A083,0000,81C24E70,FF,FFB3,99800229A0832EEC7C01010C00
   HMLAN2_RSSI -77
   HMLAN2_TIME 2015-12-21 19:23:31
   HMLAN3_MSGCNT 55
   HMLAN3_RAWMSG E29A083,0000,81C09C56,FF,FFB2,99800229A0832EEC7C01010C00
   HMLAN3_RSSI -78
   HMLAN3_TIME 2015-12-21 19:23:31
   IODev      HMLAN1
   LASTInputDev HMLAN3
   MSGCNT     125
   NAME       vccu
   NR         86
   NTFY_ORDER 50-vccu
   STATE      HMLAN1:ok,HMLAN2:ok,HMLAN3:ok,
   TYPE       CUL_HM
   assignedIOs HMLAN1,HMLAN2,HMLAN3
   lastMsg    No:99 - t:02 s:29A083 d:2EEC7C 01010C00
   protLastRcv 2015-12-21 19:23:31
   rssi_at_HMLAN1 avg:-77.49 min:-78 max:-77 lst:-78 cnt:14
   rssi_at_HMLAN2 avg:-74.69 min:-78 max:-62 lst:-77 cnt:56
   rssi_at_HMLAN3 avg:-76.14 min:-79 max:-63 lst:-78 cnt:55
   Readings:
     2015-12-21 19:23:31   CommandAccepted yes
     2015-12-21 19:20:29   aesKeyNbr       04
     2015-12-21 19:23:31   recentStateType ack
     2015-12-21 19:26:43   state           HMLAN1:ok,HMLAN2:ok,HMLAN3:ok,
   Helper:
     HM_CMDNR   153
     mId        FFF0
     rxType     1
     Expert:
       def        1
       det        1
       raw        1
       tpl        1
     Io:
       nextSend   1450722211.28179
       prefIO
       vccu
       ioList:
         HMLAN1
         HMLAN2
         HMLAN3
     Mrssi:
       mNo        99
       Io:
         HMLAN2     -77
         HMLAN3     -78
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
       vrt        1
     Rssi:
       At_hmlan1:
         avg        -77.5
         cnt        14
         lst        -78
         max        -77
         min        -78
       At_hmlan2:
         avg        -74.6964285714286
         cnt        56
         lst        -77
         max        -62
         min        -78
       At_hmlan3:
         avg        -76.1454545454546
         cnt        55
         lst        -78
         max        -63
         min        -79
     Tmpl:
Attributes:
   IODev      HMLAN1
   IOList     HMLAN1,HMLAN2,HMLAN3
   expert     251_anything
   hmKey      01:xxxxxxxxxxxxxxxxxxxxxxx3DAB6A40
   model      CCU-FHEM
   room       FHEM
   subType    virtual
   webCmd     virtual:update

Hi,

Habe jetzt das gleiche Problem.
Da ich Probleme mit der AES-Signierung habe, hatte ich bei der VCCU zusätzlich den hmkey2 auf den gleichen Wert wie hmkey1 gesetzt.

nun habe ich die gleiche Meldung wie Rampler im Event-Monitor

Zitat von: Rampler am 21 Dezember 2015, 11:19:22
Konkret irretiert mich die Meldung:
CUL_HM devicename trig_aes_vccu: ok:2
CUL_HM vccu aesKeyNbr:04

Hallo,

Zitat von: Rampler am 21 Dezember 2015, 11:19:22
Nachtrag:
Konkret irretiert mich die Meldung:
CUL_HM devicename trig_aes_vccu: ok:2
CUL_HM vccu aesKeyNbr:04

Da Du das reproduzieren kannst: Sniffe bitte mal die Nachrichten mit, die zu diesem Eintrag führen. Es ist höchstwahrscheinlich nur ein Anzeigeproblem.

Viele Grüße
  Michael


2016.12.23 12:35:29.287 0: HMUARTLGW meinLGW:keepAlive send (3): K26
2016.12.23 12:35:29.295 0: HMUARTLGW meinLGW:keepAlive read (4): >K26
2016.12.23 12:35:29.640 0: HMUARTLGW meinLGW recv: 01 05 00 00 26 msg: C1 A2 40 39776C F0815F 033D
2016.12.23 12:35:29.765 0: HMUARTLGW meinLGW recv: 01 05 00 00 2E msg: C1 A0 02 F0815F 39776C 042D16BCCC108004
2016.12.23 12:35:30.144 0: HMUARTLGW meinLGW recv: 01 05 00 00 26 msg: C2 A2 40 39776C F0815F 033D
2016.12.23 12:35:30.272 0: HMUARTLGW meinLGW recv: 01 05 00 00 2E msg: C2 A0 02 F0815F 39776C 042D16BCCC108004
2016.12.23 12:35:30.297 0: HMUARTLGW meinLGW recv: 01 05 00 00 27 msg: C2 A0 03 39776C F0815F 5E61C6E04014A4CCB906F22FE1AD9EB2
2016.12.23 12:35:30.522 0: HMUARTLGW meinLGW recv: 01 05 00 00 2E msg: C2 80 02 F0815F 39776C 0096C1C7B6
2016.12.23 12:35:34.803 0: HMUARTLGW meinLGW recv: 01 05 00 00 2F msg: F7 86 10 42B35F 000000 0A88D68B0000


und der passende Event-Monitor:
2016-12-23 12:35:29.636 CUL_HM FB_Thomas aesCommToDev: pending
2016-12-23 12:35:29.760 CUL_HM FB_Thomas aesCommToDev: pending
2016-12-23 12:35:29.777 CUL_HM vccu aesKeyNbr: 04
2016-12-23 12:35:30.140 CUL_HM FB_Thomas aesCommToDev: pending
2016-12-23 12:35:30.265 CUL_HM FB_Thomas aesCommToDev: pending
2016-12-23 12:35:30.283 CUL_HM vccu aesKeyNbr: 04
2016-12-23 12:35:30.449 CUL_HM FB_Thomas aesCommToDev: ok
2016-12-23 12:35:30.449 CUL_HM FB_Thomas battery: ok
2016-12-23 12:35:30.449 CUL_HM FB_Thomas CMDs_done
2016-12-23 12:35:30.449 CUL_HM FB_Thomas FB_Thomas_light Short
2016-12-23 12:35:30.518 CUL_HM FB_Thomas_light Short (to vccu)
2016-12-23 12:35:30.518 CUL_HM FB_Thomas_light trig_aes_vccu: ok:61
2016-12-23 12:35:30.518 CUL_HM FB_Thomas_light trigger: Short_61
2016-12-23 12:35:30.518 CUL_HM FB_Thomas_light triggerTo_vccu: Short_61
2016-12-23 12:35:30.518 CUL_HM FB_Thomas_light trigger_cnt: 61
2016-12-23 12:35:30.553 CUL_HM FB_Thomas_light triggerTo_vccu: Short_61_ack

Hallo,

Zitat von: Klinki am 23 Dezember 2016, 12:36:58

Code Auswählen Erweitern


2016.12.23 12:35:30.272 0: HMUARTLGW meinLGW recv: 01 05 00 00 2E msg: C2 A0 02 F0815F 39776C 042D16BCCC108004
2016.12.23 12:35:30.297 0: HMUARTLGW meinLGW recv: 01 05 00 00 27 msg: C2 A0 03 39776C F0815F 5E61C6E04014A4CCB906F22FE1AD9EB2
2016.12.23 12:35:30.522 0: HMUARTLGW meinLGW recv: 01 05 00 00 2E msg: C2 80 02 F0815F 39776C 0096C1C7B6


F0815F (HMID Deiner VCCU?) fragt hier tatsächlich das Gerät 39776C (FB_Thomas) nach einer Challenge mit Key 04 (bzw. 2) (letztes Byte der ersten Nachricht). Und die Challenge wird anscheinend korrekt beantwortet, d.h. die FB kennt den Key mit diesem Index. Hat evtl. eines Deiner IOs noch einen hmKey mit 02:... eingetragen?

Zumindest HMUARTLGW schickt bei gleichem Keyindex in hmKey/hmKey2/... nur einen Key an das Gateway, wenn doppelte Indizes vergeben sind und erhöht den Index nicht einfach. Bei HMLAN bin ich mir nicht sicher.

Viele Grüße
  Michael

Hallo Michael,

Zitat von: mgernoth am 23 Dezember 2016, 12:47:40
Hat evtl. eines Deiner IOs noch einen hmKey mit 02:... eingetragen?

Ja, so war es. Hat sich mir nur nicht direkt erschlossen, da Key 04 angezeigt wurde (der ja nicht vergeben wurde). Aber ein Blick in´s Wiki offenbarte den Grund:
https://wiki.fhem.de/wiki/AES_Encryption#Zentrale (https://wiki.fhem.de/wiki/AES_Encryption#Zentrale): [..]wobei das Reading den im Funkprotokoll angeforderten Schlüssel wiederspiegelt, welcher den doppelten Wert des eigentlichen Schlüsselindex hat.

Ich habe meine beiden IOs und die virtuelle Zentrale noch mal komplett neu angelegt. Anschließend war der Fehler weg. Er lässt sich aber reproduzieren, wenn man im LANGW noch einmal den gleichen Key als hmkey2 hinterlegt. Dieser liest sich im Event-Monitor als Key Nr. 4 - wie von Dir schon vermutet.

...ein wenig mehr Licht in´s Dunkle gebracht...

gruß
klinki