Hallo zusammen,
ich bin mal wieder mit AES am Kämpfen:
nachdem es mir gelungen war, AES auf meinen beiden Remotes zu aktivieren ("aesKeyNbr 02", alle Buttons "R-sign on") habe ich nun ein anderes Problem. Die Tastendrücke kommen zwar im Event Monitor an, allerdings bleibt "aesCommToDev" auf "pending" stehen. Was hat es genau zu bedeuten? Ist AES nun aktiv oder nicht? Hier die lists von einem Remote und exemplarisch von einem Button:
Internals:
DEF 202C70
IODev nanoCUL
LASTInputDev nanoCUL
MSGCNT 12
NAME HM_202C70
NOTIFYDEV global
NR 73
NTFY_ORDER 50-HM_202C70
STATE HM_202C70_Btn_01 Short
TYPE CUL_HM
channel_01 HM_202C70_Btn_01
channel_02 HM_202C70_Btn_02
channel_03 HM_202C70_Btn_03
lastMsg No:22 - t:40 s:202C70 d:000000 8106
nanoCUL_MSGCNT 12
nanoCUL_RAWMSG A0B228440202C700000008106::-83:nanoCUL
nanoCUL_RSSI -83
nanoCUL_TIME 2016-11-04 23:15:46
protLastRcv 2016-11-04 23:15:46
protSnd 4 last_at:2016-11-04 23:12:41
protState CMDs_done
rssi_at_nanoCUL avg:-78.25 lst:-83 max:-71.5 cnt:12 min:-84.5
Readings:
2016-10-29 00:01:47 CommandAccepted yes
2016-11-04 23:12:40 D-firmware 1.3
2016-11-04 23:12:40 D-serialNr XXXXXXXXXX
2016-11-04 22:55:19 PairedTo 0x000000
2016-10-29 00:01:47 R-pairCentral 0x000000
2016-11-04 22:55:19 RegL_00. 02:00 0A:00 0B:00 0C:00 00:00
2016-11-04 22:55:56 aesCommToDev pending
2016-11-04 22:55:56 aesKeyNbr 02
2016-10-25 20:58:57 alive yes
2016-11-04 23:15:46 battery low
2016-10-25 20:58:57 powerOn 2016-10-25 20:58:57
2016-10-25 20:58:57 recentStateType info
2016-10-29 00:00:39 sabotageAttackId_ErrIoId_F3A461 cnt:2
2016-10-29 00:00:39 sabotageAttack_ErrIoAttack cnt 2
2016-11-04 23:15:46 state HM_202C70_Btn_01 Short
Helper:
HM_CMDNR 34
cSnd 01F3A460202C7001040000000001,01F3A460202C700103
mId 001C
rxType 4
Ack:
Expert:
def 1
det 1
raw 1
tpl 1
Io:
newChn +202C70,00,00,00
nextSend 1478297746.84169
prefIO
rxt 0
vccu
p:
202C70
00
00
00
Mrssi:
mNo 22
Io:
nanoCUL -81
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Rssi:
At_nanocul:
avg -78.25
cnt 12
lst -83
max -71.5
min -84.5
Tmpl:
Attributes:
IODev nanoCUL
autoReadReg 4_reqStatus
expert 251_anything
firmware 1.3
model HM-RC-SEC3-B
room CUL_HM
serialNr XXXXXXXXXX
subType remote
webCmd getConfig:clear msgEvents
Internals:
DEF 202C7001
NAME HM_202C70_Btn_01
NOTIFYDEV global
NR 77
NTFY_ORDER 50-HM_202C70_Btn_01
STATE Short (to broadcast)
TYPE CUL_HM
chanNo 01
device HM_202C70
Readings:
2016-11-04 23:12:40 R-dblPress 0 s
2016-11-04 23:12:40 R-longPress 0.4 s
2016-11-04 23:12:40 R-sign on
2016-11-04 23:12:40 RegL_01. 04:10 08:01 09:00 00:00
2016-11-04 23:15:46 state Short (to broadcast)
2016-11-04 23:15:46 trigger Short_6
2016-11-04 23:15:46 trigger_cnt 6
Helper:
BNO 6
BNOCNT 1
peerIDsRaw ,00000000
Expert:
def 1
det 1
raw 1
tpl 1
Role:
chn 1
Shadowreg:
Tmpl:
Attributes:
expert 251_anything
model HM-RC-SEC3-B
peerIDs 00000000,
Ach ja, das Verhalten tritt sowohl mit einem nanoCUL als auch mit einem HM-MOD-UART auf...
hm..... nicht gepairt, batterie leer und schlechter funk. 8)
Verdammt, wieso ist das blöde Ding schon wieder nicht gepairt? Sorry, ist mir nicht aufgefallen, da es schon gepairt war...
Das mit dem Funk und Batterie ist mir klar, aber hoffentlich nebensächlich. Ich muss morgen wohl noch mal von vorne anfangen :(
Danke für den Hinweis :)
Das mit dem fehlenden Pairing scheint aber nicht der einzige Grund zu sein, denn die Andere Fernbedienung ist gepairt, trotzdem identisches Verhalten:
Internals:
DEF 400FE5
IODev myHmUART
NAME HM_400FE5
NOTIFYDEV global
NR 128
STATE HM_400FE5_lock LongRelease
TYPE CUL_HM
channel_01 HM_400FE5_unlock
channel_02 HM_400FE5_lock
channel_03 HM_400FE5_light
channel_04 HM_400FE5_open
Readings:
2016-10-28 23:45:39 CommandAccepted yes
2016-11-04 22:43:25 D-firmware 1.2
2016-11-04 22:43:25 D-serialNr XXXXXXXXXX
2016-11-04 22:41:34 PairedTo 0xF3A460
2016-11-04 22:31:33 R-pairCentral 0xF3A460
2016-11-04 22:41:34 RegL_00. 02:01 0A:F3 0B:A4 0C:60 18:00 00:00
2016-11-04 22:41:16 aesCommToDev pending
2016-11-04 22:41:16 aesKeyNbr 02
2016-10-28 23:45:43 alive yes
2016-11-04 22:53:12 battery ok
2016-10-28 23:45:43 powerOn 2016-10-28 23:45:43
2016-10-28 23:45:43 recentStateType info
2016-10-28 23:58:05 sabotageAttackId_ErrIoId_F3A461 cnt:25
2016-10-28 23:58:05 sabotageAttack_ErrIoAttack cnt 25
2016-11-04 22:53:12 state HM_400FE5_lock LongRelease
Helper:
HM_CMDNR 1
mId 00A6
rxType 20
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +400FE5,01,00,00
prefIO
rxt 2
vccu
p:
400FE5
01
00
00
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
dev 1
Role:
Attributes:
IODev myHmUART
aesCommReq 1
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.2
model HM-RC-Key4-2
room CUL_HM
serialNr XXXXXXXXXX
subType remote
webCmd getConfig:clear msgEvents
2016-10-28 23:58:05 sabotageAttackId_ErrIoId_F3A461 cnt:25
2016-10-28 23:58:05 sabotageAttack_ErrIoAttack cnt 25
wer ist denn F3A461?
gibt es vielleicht kollisionen im funk? sniffe mal.
Hallo Frank,
ich hatte mal mit 2 FHEM-Instanzen rumgespielt, die Einträge stammen aus dieser Zeit. Aktuell sind Kollisionen auf dieser Basis ausgeschlossen.
Die 2. Fernbedienung (HM-RC-Key4-2) konnte ich mittlerweile zurücksetzen und wieder neu einrichten. Die besagte HM-RC-Sec3-B verhält sich aber komisch. Wie Dir schon aufgefallen ist, ist die nicht gepairt. Ich kriege sie jetzt weder gepairt noch zurückgesetzt, obwohl mir der hinterlegte AES-Schlüssel eigentlich bekannt ist. Es kommen Fehler wie "aesCommToDev fail" und "NACK".
Irgendeine Idee, was das Problem sein könnte?