Hallo die Runde
Angeregt durch die Diskussion um die AES-Thematik und den bekannten Standardschlüssel möchte ich mein System auf einen eigenen AES-Key umstellen, habe aber allerdings einige Verständnisprobleme. Das Windows-Konfigurationstool kann ja immer nur einen IO nutzen. In den Anleitungen im Netz steht, daß man mit dem Konfigurator alle Geräte am IO anmelden soll, und dann den neuen Schlüssel setzen soll, der dann wohl automatisch verteilt wird.
Um jetzt einen zweiten IO an der vccu parallel (dieselbe hmID) nutzen zu können, muß man diese Prozedur komplett mit diesem IO wiederholen oder reicht es aus, einem weiteren IO in fhem einfach denselben AES-Key mit attr hmKey zuzuweisen?
Gibt es eine gute Anleitung zu der Thematik?
Viele Grüße
G.
Hallo,
Zitat von: Gernott am 07 Juni 2015, 15:52:15
Angeregt durch die Diskussion um die AES-Thematik und den bekannten Standardschlüssel möchte ich mein System auf einen eigenen AES-Key umstellen
Gute Entscheidung :-)
Zitat
Um jetzt einen zweiten IO an der vccu parallel (dieselbe hmID) nutzen zu können, muß man diese Prozedur komplett mit diesem IO wiederholen oder reicht es aus, einem weiteren IO in fhem einfach denselben AES-Key mit attr hmKey zuzuweisen?
Nachdem der Schluessel einmal an die Geraete uebertragen wurde, koennen sie mit jedem IO kommunizieren, welches auch diesen Schluessel kennt. Also ja, es ist ausreichend einfach nur den Schluessel dem zweiten IO zuzuweisen, er muss nicht erneut an die Geraete uebertragen werden.
Gruss
Michael
Hallo Michael
Danke für die Erklärung. Darf ich gleich mit einem ersten Problem kommen?
Habe mal mit dem Windows-Konfigurator einen neuen Key übertragen. Bei einem optischen Tür/Fenster-Sensor HM-SEC-SCo geht allerdings das Peering dann nicht mehr. Der Sensor ist per Default auf sign on gestellt. In der zugehörigen .dev Datei im Ordner Bidcos-Service\devices wird ein ein aes_key_index="1" angezeigt. Von daher gehe ich davon aus, daß der neue Key korrekt übertragen wurde. In den fhem-Readings steht allerdings dann aesKeyNbr 00. Sollte nicht dort dann 01 stehen? Der Sensor überträgt seinen Status korrekt an den IO, allerdings nicht an den gepeerten Channel des Anzeigeaktors (HM-Dis-TD-T). Ist der Key in dem Fall doch nicht korrekt übertragen worden?
Gruß
G.
Hallo Gernott,
Zitat von: Gernott am 07 Juni 2015, 17:36:38
Habe mal mit dem Windows-Konfigurator einen neuen Key übertragen. Bei einem optischen Tür/Fenster-Sensor HM-SEC-SCo geht allerdings das Peering dann nicht mehr. Der Sensor ist per Default auf sign on gestellt. In der zugehörigen .dev Datei im Ordner Bidcos-Service\devices wird ein ein aes_key_index="1" angezeigt. Von daher gehe ich davon aus, daß der neue Key korrekt übertragen wurde. In den fhem-Readings steht allerdings dann aesKeyNbr 00. Sollte nicht dort dann 01 stehen?
Die aesKeyNbr wird aktualisiert, sobald das Geraet das erste mal von Fhem eine Signatur anfordert. Dies geschieht relativ selten, z.B. aber bei einer Registeraenderung. Setche doch mal testweise cyclicInfoMsg um und schaue, ob der Wert dann auf 02 springt (der Wert ist im Augenblick das doppelte des "echten" (hier kann man geteilter Meinung sein) Schluesselindex). Sollte er auf 00 bleiben, dann hat der Schluesselaustausch nicht funktioniert.
Wahrscheinlich implementiert Martin den Schluesselaustausch in den naechsten Tagen direkt in Fhem, dann muss man nicht mehr mit der Windows-Software rumwerkeln, oder du probierst es mit meinem Perl-Modul aus http://forum.fhem.de/index.php/topic,37787.0.html (einfach nach FHEM/ kopieren, dann sollte das Kommando nach einem restart per Terminal ausfuehrbar sein).
Zitat
Der Sensor überträgt seinen Status korrekt an den IO, allerdings nicht an den gepeerten Channel des Anzeigeaktors (HM-Dis-TD-T). Ist der Key in dem Fall doch nicht korrekt übertragen worden?
Kennt der Anzeigeaktor den neuen Schluessel?
Und keine Sorge, der Schluessel kann nicht falsch uebertragen werden. Entweder er ist korrekt angekommen oder er wurde auf dem Geraet verworfen.
Gruss
Michael
Hallo Michael
Nachdem ich den Sensor im Windows Konfigurationstool ab- und wieder neu angelernt habe, zeigt er nach dem Peering mit der Anzeige nun aesKeyNbr 02. Soweit so gut. Leider funktioniert die Übertragung trotzdem nicht. Bei einer Statusänderung des Sensors leuchtet seine LED eine Weile gelb und dann rot. Der Status wird an fhem trotzdem korrekt übertragen.
Ich hänge mal die list-Ausgaben beider Geräte an:
Sensor:
Internals:
DEF 359A60
HMLAN1_MSGCNT 174
HMLAN1_RAWMSG E359A60,0000,002ED9EC,FF,FFA6,C0A641359A6027375F0120C8
HMLAN1_RSSI -90
HMLAN1_TIME 2015-06-07 23:35:34
IODev HMLAN1
LASTInputDev hmusb
MSGCNT 358
NAME hm.door_Garagentor
NR 219
NTFY_ORDER 50-hm.door_Garagentor
STATE open
TYPE CUL_HM
hmusb_MSGCNT 184
hmusb_RAWMSG E359A60,0000,0101E4B2,FF,FFED,C0A641359A6027375F0120C8
hmusb_RSSI -19
hmusb_TIME 2015-06-07 23:35:34
lastMsg No:C0 - t:41 s:359A60 d:27375F 0120C8
peerList hm.display_switch_Garagentor,
protCmdDel 8
protEvt_AESerrReject 1 last_at:2015-06-07 23:16:07
protEvt_AESok 3 last_at:2015-06-07 23:19:53
protLastRcv 2015-06-07 23:35:34
protResnd 8 last_at:2015-06-07 23:25:07
protResndFail 2 last_at:2015-06-07 23:25:10
protSnd 139 last_at:2015-06-07 23:35:33
protState CMDs_done
rssi_at_HMLAN1 avg:-90.73 min:-102 max:-82 lst:-90 cnt:174
rssi_at_hmusb avg:-22.34 min:-83 max:-18 lst:-19 cnt:184
Readings:
2015-06-07 23:34:46 Activity alive
2015-06-07 23:34:35 CommandAccepted yes
2015-06-07 23:34:46 D-firmware 1.0
2015-06-07 23:34:46 D-serialNr LEQ1509864
2015-06-07 23:34:47 PairedTo 0x1EA24B
2015-06-07 22:48:58 R-cyclicInfoMsg on
2015-06-07 22:48:59 R-eventDlyTime 0 s
2015-06-07 23:34:48 R-hm.display_switch_Garagentor_chn-01-expectAES on
2015-06-07 23:34:48 R-hm.display_switch_Garagentor_chn-01-peerNeedsBurst off
2015-06-07 22:48:59 R-msgScPosA open
2015-06-07 22:48:59 R-msgScPosB closed
2015-06-07 22:48:58 R-pairCentral 0x1EA24B
2015-06-07 22:48:58 R-sabotageMsg on
2015-06-07 23:34:47 R-sign on
2015-06-07 22:48:58 R-transmDevTryMax 6
2015-06-07 22:48:59 R-transmitTryMax 6
2015-06-07 23:34:47 RegL_00: 02:01 09:01 0A:1E 0B:A2 0C:4B 10:01 14:06 00:00
2015-06-07 23:34:47 RegL_01: 08:01 20:9C 21:00 30:06 00:00
2015-06-07 23:34:48 RegL_04:hm.display_switch_Garagentor_chn:01 01:80 00:00
2015-06-07 23:19:52 aesKeyNbr 02
2015-06-07 23:28:51 alive yes
2015-06-07 23:35:34 battery ok
2015-06-07 23:35:34 contact open (to hm.display_switch_Garagentor)
2015-06-07 23:34:48 peerList hm.display_switch_Garagentor,
2015-06-07 23:28:51 recentStateType info
2015-06-07 23:28:51 sabotageError off
2015-06-07 23:35:34 state open
2015-06-07 23:25:11 trigDst_hm.display_switch_Garagentor noConfig
2015-06-07 23:35:33 trigDst_vccu noConfig
2015-06-07 23:35:34 trigger_cnt 32
Helper:
HM_CMDNR 192
cSnd 011EA24B359A600103,011EA24B359A60010427375F0104
mId 00C7
peerIDsRaw ,27375F01,00000000
rxType 28
Io:
newCh 1
newChn +359A60,00,01,1E
nextSend 1433712935.01628
rxt 2
vccu vccu
p:
359A60
00
01
1E
Mrssi:
mNo C0
Io:
HMLAN1 -88
hmusb -19
Prt:
bErr 0
sProc 0
sleeping 0
try 1
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_hmlan1:
avg -90.7356321839081
cnt 174
lst -90
max -82
min -102
At_hmusb:
avg -22.3478260869565
cnt 184
lst -19
max -18
min -83
Shadowreg:
Attributes:
IODev HMLAN1
IOgrp vccu
actCycle 028:00
actStatus alive
autoReadReg 3_onChange
event-min-interval state:1800
event-on-change-reading state,battery
expert 2_full
firmware 1.0
model HM-SEC-SCo
peerIDs 00000000,27375F01,
room AU.Garage,CUL_HM
serialNr LEQ1509864
subType threeStateSensor
verbose 0
Aktor:
Internals:
DEF 27375F
HMLAN1_MSGCNT 22
HMLAN1_RAWMSG E27375F,0000,002B8BD6,FF,FFAD,1BA41027375F1EA24B06010000
HMLAN1_RSSI -83
HMLAN1_TIME 2015-06-07 23:31:58
IODev HMLAN1
LASTInputDev hmusb
MSGCNT 45
NAME hm.display_switch_Garagentor
NR 215
NTFY_ORDER 50-hm.display_switch_Garagentor
STATE off
TYPE CUL_HM
hmusb_MSGCNT 23
hmusb_RAWMSG E27375F,0000,00FE96C2,FF,FFE5,1BA41027375F1EA24B06010000
hmusb_RSSI -27
hmusb_TIME 2015-06-07 23:31:58
lastMsg No:1B - t:10 s:27375F d:1EA24B 06010000
peerList hm.door_Garagentor,
protLastRcv 2015-06-07 23:31:58
protSnd 25 last_at:2015-06-07 23:31:58
protState CMDs_done
rssi_at_HMLAN1 avg:-83.36 min:-92 max:-78 lst:-83 cnt:22
rssi_at_hmusb avg:-29.69 min:-38 max:-23 lst:-27 cnt:23
rssi_hmusb avg:-32.75 min:-35 max:-31 lst:-31 cnt:4
Readings:
2015-06-07 23:22:26 CommandAccepted yes
2015-06-07 23:23:53 PairedTo 0x1EA24B
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-lgActionType jmpToTarget
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-lgCtDlyOff geLo
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-lgCtDlyOn geLo
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-lgCtOff geLo
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-lgCtOn geLo
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-lgCtValHi 100
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-lgCtValLo 50
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-lgMultiExec on
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-lgOffDly 0 s
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-lgOffTime unused
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-lgOffTimeMode absolut
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-lgOnDly 0 s
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-lgOnTime unused
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-lgOnTimeMode absolut
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-lgSwJtDlyOff off
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-lgSwJtDlyOn on
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-lgSwJtOff dlyOn
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-lgSwJtOn dlyOff
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-shActionType jmpToTarget
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-shCtDlyOff geLo
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-shCtDlyOn geLo
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-shCtOff geLo
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-shCtOn geLo
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-shCtValHi 100
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-shCtValLo 50
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-shOffDly 0 s
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-shOffTime unused
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-shOffTimeMode absolut
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-shOnDly 0 s
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-shOnTime unused
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-shOnTimeMode absolut
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-shSwJtDlyOff off
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-shSwJtDlyOn on
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-shSwJtOff dlyOn
2015-06-07 23:23:54 R-hm.door_Garagentor_chn-01-shSwJtOn dlyOff
2015-06-07 22:51:10 R-intKeyVisib invisib
2015-06-07 22:51:10 R-ledMode off
2015-06-07 22:51:10 R-lowBatLimitFS 2.4 V
2015-06-07 22:51:10 R-pairCentral 0x1EA24B
2015-06-07 23:23:53 RegL_00: 02:01 05:00 0A:1E 0B:A2 0C:4B 12:18 00:00
2015-06-07 23:23:54 RegL_03:hm.door_Garagentor_chn:01 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:63 00:00
2015-06-07 23:31:58 deviceMsg off (to vccu)
2015-06-07 23:31:58 level 0
2015-06-07 23:31:58 pct 0
2015-06-07 23:23:53 peerList hm.door_Garagentor,
2015-06-07 23:31:58 recentStateType info
2015-06-07 23:31:58 state off
2015-06-07 23:31:58 timedOn off
Helper:
HM_CMDNR 27
cSnd 011EA24B27375F0103,011EA24B27375F0104359A600103
dlvlCmd ++A0111EA24B27375F0201000000
mId 0078
peerIDsRaw ,359A6001,00000000
rxType 2
Io:
newChn +27375F,00,01,00
nextSend 1433712718.44406
rxt 0
vccu vccu
p:
27375F
00
01
00
Mrssi:
mNo 1B
Io:
HMLAN1 -81
hmusb -27
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
prs 1
Rpt:
IO HMLAN1
flg A
ts 1433712718.36421
ack:
HASH(0x2470200)
1B80021EA24B27375F00
Rssi:
At_hmlan1:
avg -83.3636363636364
cnt 22
lst -83
max -78
min -92
At_hmusb:
avg -29.695652173913
cnt 23
lst -27
max -23
min -38
Hmusb:
avg -32.75
cnt 4
lst -31
max -31
min -35
Shadowreg:
Attributes:
IODev HMLAN1
IOgrp vccu
autoReadReg 3_onChange
devStateIcon off:fts_garage_door_100 on:fts_garage
expert 2_full
firmware 1.1
model HM-Dis-TD-T
msgRepeat 1
peerIDs 00000000,359A6001,
room AU.Garage,CUL_HM
serialNr LEQ0214915
subType switch
webCmd statusRequest:on:off
Vielleicht erkennst Du ja das Problem? Den Aktor hatte ich auch noch einmal ab- und wieder angelernt. HMinfo configCheck zeigt kein Problem bei den Partnern.
Danke und Gruß
G.
Update:
Hurra, es geht doch. Habe gerade noch die Register geprüft und beim Sensor peerNeedsBurst on und beim Aktor chn-01-shCtOn ltLo gesetzt, dann ging es (Gut, daß ich hier noch einen Vergleich für die Register und eine hilfreiche Lösung hatte: http://forum.fhem.de/index.php/topic,31933.msg243806.html#msg243806).
Danke nochmal für die Unterstützung.