Zitat von: Ralli am 06 November 2023, 15:39:13Zitat von: Torben am 06 November 2023, 15:04:40Es kann sein, dass die eine oder andere Komponente nicht richtig abgelernt ist. Das kann durch einen Reset normalerweise problemlos nachgeholt werden.
Vorsicht: das stimmt nur für die Geräte, bei denen kein AES aktiviert wurde/ist bzw. wenn kein eigener Systemschlüssel sondern der Standard-Systemschlüssel verwendet wurde und auch zukünftig verwendet werden wird.
Nicht ordnungsgemäß abgelernte Geräte bergen immer die Gefahr, dass sie beim nächsten Besitzer nicht angelernt und eingebunden werden können.
Zitat von: Ralf9 am 06 November 2023, 20:17:22Ich habe gerade bei meinen HM-Sec-Sco die readings angeschaut, bis auf meine 2 ältesten gibts bei allen die readings "aesCommToDev ok".
Bei allen gibts das reading "aesKeyNbr 00"
Ich habe bei keinem das AES aktiviert. War demnach bei den älteren das AES per default nicht aktiv und bei den später gekauften dann per default das AES aktiv?
Müssen die HM-Sec-Sco mit aktivem AES bei wechsel der Zentrale abgelernt werden? Auch bei "aesKeyNbr 00"?
Gruß Ralf
Zitat von: Ralli am 06 November 2023, 20:26:07Alle HM-Geräte mit "Sec" in der Produktbezeichnung verwenden AES per Default.
Und ja, auch diese Geräte müssen ordnungsgemäß von der Alt-Zentrale abgelernt werden, da sie von der Zentrale mit der bisherigen HM-ID ja nun mal ein "ordentliches" Challenge-Response für das Ablernen erwarten, bevor sie eine Zentrale mit einer anderen HM-ID zum Pairen zulassen.
Zitat von: Ralf9 am 06 November 2023, 20:53:26Ist das AES auch aktiv, wenn bei meinen 2 ältesten es ein reading "aesKeyNbr 00", aber kein reading "aesCommToDev ok" gibt?
Zitat von: Ralli am 07 November 2023, 05:27:22Wahrscheinlich ist es dann nicht (mehr) aktiv. Überprüfen kannst du es durch Mitsniffen bzw. über die RAW-Messages:
1. A 11 7E A0 02 001122 334455 04 xxxxxxxxxxxx 00
2. A 19 7E A0 03 334455 001122 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
1. Ist eine Empfangsbestätigung ("02") mit einem Signing-Request ("04") mit Key 00
2. Ist eine Signing-Response ("03")
"Sec" in den Produktnamen heißt, dass AES per Default aktiv ist - man kann es m.W. aber deaktivieren.
Ich habs mal getestet.
Ich hab ein z.Zt. nicht verwendetes HM-SEC-SCO mit dem HM-CFG-USB (424242) von meinem produktiv FHEM gepairt.
Danach habe ich das HM-SEC-SCO geresetet ohne es vorher abzulernen und dann problemlos mit einem HM-MOD-UART (424244) auf einem FHEM Testsystem gepairt.
Obwohl es die readings "aesKeyNbr 00", und "aesCommToDev ok" gibt, kann ich in den raw Nachrichten kein AES erkennen:
myHmUARTLGW send: 01 02 00 00 00 msg: 08 80 02 424244 690962 0101C800
myHmUARTLGW recv: 01 05 01 00 34 msg: 09 A6 41 690962 424244 0199C8
Gruß Ralf
aes macht die fw des hmuart autonom.
das kann nur ein 2. io monitoren.
wenn die io vom "produktiv FHEM" im funkbereich vom "test fhem" sind, kannst du die kommunikation vom testsystem einfach mit diesen "produktiven" io monitoren.
übrigens: falls die erworbene ware nicht richtig abgelernt wurde, kannst du diese notfalls auch mit deinem testsystem ablernen, wenn dir der verkäufer den selbst erstellten aes key verrät.
Wenn vom Verkäufer der AES Key nicht geändert wurde, müsste es doch eigentlich egal sein ob der HM-SEC-SCO sauber abgelernt wurde, wenn vor dem anlernen ein Reset gemacht wird?
Zitatwenn die io vom "produktiv FHEM" im funkbereich vom "test fhem" sind, kannst du die kommunikation vom testsystem einfach mit diesen "produktiven" io monitoren.
Habe ich gemacht, es sind auch da keine AES Nachrichten dabei.
Zitat von: Ralf9 am 09 November 2023, 13:50:47Wenn vom Verkäufer der AES Key nicht geändert wurde, müsste es doch eigentlich egal sein ob der HM-SEC-SCO sauber abgelernt wurde, wenn ich vor dem anlernen ein Reset gemacht wird?
grundsätzlich ist der
reset über die tasten am device gesperrt, wenn dem device ein selbstdefinierter aes-key zugewiesen wurde.
ausnahmen bestätigen die regel. ist dann halt ein fw bug.
Zitat von: Ralf9 am 09 November 2023, 13:50:47Habe ich gemacht, es sind auch da keine AES Nachrichten dabei.
zeig mal ein "get <name> list full" vom sco.
Mir gehts nur um HM-SEC-SCO bei denen kein selbstdefinierter aes-key zugewiesen wurde.
Da es die Aussage gibt, daß bei allen HM-SEC-SCO per Default das AES aktiv ist, wollte ich mal sehen, ob ich das durch durch Mitsniffen oder über die RAW-Messages erkennen kann.
Evtl ist dies nur mit einem Cul möglich.
Laut dem log und dem reading "aesCommToDev ok" müsste AES aktiv sein:
2023.11.07 12:34:44.339 4: HMUARTLGW myHmUARTLGW UpdatePeerReq: 690962, state 90
2023.11.07 12:34:44.347 4: HMUARTLGW myHmUARTLGW added peer: 690962, aesChannels: FFFFFFFFFFFFFFFF
2023.11.07 12:34:44.347 4: HMUARTLGW myHmUARTLGW UpdatePeerReq: 690962, state 91
2023.11.07 12:34:44.347 4: HMUARTLGW myHmUARTLGW UpdatePeerReq: 690962, state 92
2023.11.07 12:34:44.347 4: HMUARTLGW myHmUARTLGW AESchannels: 00
Den Test HM-SEC-SCO habe ich in fhem inzwischen wieder gelöscht.
Zitat von: Ralf9 am 09 November 2023, 18:53:37Evtl ist dies nur mit einem Cul möglich.
nö.
vermutlich hast du aes nicht komplett eingeschaltet.
der
empfänger einer msg muss für aes aktiviert sein, damit er den signing request beim sender anfordert.
wenn du nur mit den open/close triggern, die der sco an fhem sendet, getestet hast, muss aes bei fhem für dieses device aktiviert sein, damit fhem den signing request anfordert.
das wird mit dem attribut aesCommReq am sco aktiviert.
ein sniff mit hmuart (nur monitor) für ein close bei einem sec-sc sieht dann so aus:
2023.11.09 16:37:40.144 0: HMUARTLGW hmuart1 recv: 01 05 00 00 4B msg: 52 A4 41 1DE620 1ACE1F 010C00
2023.11.09 16:37:40.222 0: HMUARTLGW hmuart1 recv: 01 05 00 00 2D msg: 52 A0 02 1ACE1F 1DE620 04C355F3BDDCE100
2023.11.09 16:37:40.287 0: HMUARTLGW hmuart1 recv: 01 05 00 00 44 msg: 52 A0 03 1DE620 1ACE1F 023D498D7207287D90ECEFD682CB253D
2023.11.09 16:37:40.383 0: HMUARTLGW hmuart1 recv: 01 05 00 00 2D msg: 52 80 02 1ACE1F 1DE620 0013753B84
für die andere richtung der signale, muss das register sign im fk gesetzt sein.
hier der anfang vom setzen eines registers:
2023.11.09 21:02:03.327 0: HMUARTLGW hmuart1 recv: 01 05 00 00 1D msg: 39 A0 01 1ACE1F 1DE620 01050000000001
2023.11.09 21:02:03.574 0: HMUARTLGW hmuart1 recv: 01 05 00 00 33 msg: 39 A0 02 1DE620 1ACE1F 04C3A50981C3A500
2023.11.09 21:02:03.579 0: HMUARTLGW hmuart1 recv: 01 05 00 00 1D msg: 39 A0 03 1ACE1F 1DE620 E9454926E7FF6D0E23F4FB4C9CDB7B58
2023.11.09 21:02:03.837 0: HMUARTLGW hmuart1 recv: 01 05 00 00 33 msg: 39 80 02 1DE620 1ACE1F 006A98929D
Ich habs mal getestet.
Zuerst habe ich am test fhem am HmUARTLGW den HM-SEC-SCO angelernt und dann "attr aesCommReq 1" und "set sign on"
und dann am produktiv fhem am HM-CFG-USB gemonitort, dort habe ich keine signing request gesehen, nur diese: "?? 8002 424244 690962 00"
an den events bei open/close war das aes zu erkennen:
2023-11-10 12:03:06.047 CUL_HM HM_690962 aesCommToDev: ok
2023-11-10 12:03:06.047 CUL_HM HM_690962 trig_aes_myHmUARTLGW: ok:55
dann habe ich den HM-SEC-SCO wieder abgelernt und gelöscht
dann habe ich im produktiv fhem am HM-CFG-USB den HM-SEC-SCO angelernt und dann "attr aesCommReq 1" und "set sign on"
hier habe ich bei den open/close events kein aes gesehen, liegt das evtl am HM-CFG-USB (D-firmware 0.967)
und dann am test fhem am HmUARTLGW gemonitort, dort habe ich keine signing request gesehen, nur diese: "?? 8002 424242 690962 00"
Hier ist das List vom HM-SEC-SCO
Internals:
.AttrList .devInfo .mId .stc IODev IOgrp actCycle actStatus aesCommReq:1,0 aesKey:5,4,3,2,1,0 autoReadReg:0_off,1_restart,2_pon-restart,3_onChange,4_reqStatus,5_readMissing,8_stateOnly burstAccess:0_off,1_auto commStInCh:on,off do_not_notify:1,0 dummy:1,0 event-aggregator event-min-interval event-on-change-reading event-on-update-reading expert:multiple,defReg,allReg,rawReg,templ,none firmware hmKey hmKey2 hmKey3 hmProtocolEvents:0_off,1_dump,2_dumpFull,3_dumpTrigger ignore:1,0 levelMap levelRange model modelForce:ACTIONDETECTOR,ACTIONDETECTOR,ASH550,ASH550I,CCU-FHEM,CMM,DORMA_ATENT,DORMA_BRC-H,DORMA_RC-H,HM-CC-RT-DN,HM-CC-RT-DN-BOM,HM-CC-SCD,HM-CC-TC,HM-CC-VD,HM-DIS-EP-WM55,HM-DIS-TD-T,HM-DIS-WM55,HM-DW-WM,HM-ES-PMSW1-DR,HM-ES-PMSW1-PL,HM-ES-PMSW1-PL-DN-R1,HM-ES-PMSW1-PL-DN-R2,HM-ES-PMSW1-PL-DN-R3,HM-ES-PMSW1-PL-DN-R4,HM-ES-PMSW1-PL-DN-R5,HM-ES-PMSW1-SM,HM-ES-TX-WM,HM-HM-LC-DW-WM,HM-LC-AO-SM,HM-LC-BL1-FM,HM-LC-BL1-FM-2,HM-LC-BL1-PB-FM,HM-LC-BL1-SM,HM-LC-BL1-SM-2,HM-LC-BL1PBU-FM,HM-LC-DDC1-PCB,HM-LC-DIM1L-CV,HM-LC-DIM1L-CV-2,HM-LC-DIM1L-CV-644,HM-LC-DIM1L-PL,HM-LC-DIM1L-PL-2,HM-LC-DIM1L-PL-3,HM-LC-DIM1L-PL-644,HM-LC-DIM1PWM-CV,HM-LC-DIM1PWM-CV-2,HM-LC-DIM1T-CV,HM-LC-DIM1T-CV-2,HM-LC-DIM1T-CV-644,HM-LC-DIM1T-DR,HM-LC-DIM1T-FM,HM-LC-DIM1T-FM-2,HM-LC-DIM1T-FM-644,HM-LC-DIM1T-FM-LF,HM-LC-DIM1T-PL,HM-LC-DIM1T-PL-2,HM-LC-DIM1T-PL-3,HM-LC-DIM1T-PL-644,HM-LC-DIM1TPBU-FM,HM-LC-DIM1TPBU-FM-2,HM-LC-DIM2L-CV,HM-LC-DIM2L-SM,HM-LC-DIM2L-SM-2,HM-LC-DIM2L-SM-644,HM-LC-DIM2T-SM,HM-LC-DIM2T-SM,HM-LC-DIM2T-SM-2,HM-LC-JA1PBU-FM,HM-LC-RGBW-WM,HM-LC-SW1-BA-PCB,HM-LC-SW1-DR,HM-LC-SW1-FM,HM-LC-SW1-FM-2,HM-LC-SW1-PB-FM,HM-LC-SW1-PCB,HM-LC-SW1-PL,HM-LC-SW1-PL-3,HM-LC-SW1-PL-CT-R1,HM-LC-SW1-PL-CT-R2,HM-LC-SW1-PL-CT-R3,HM-LC-SW1-PL-CT-R4,HM-LC-SW1-PL-CT-R5,HM-LC-SW1-PL-DN-R1,HM-LC-SW1-PL-DN-R2,HM-LC-SW1-PL-DN-R3,HM-LC-SW1-PL-DN-R4,HM-LC-SW1-PL-DN-R5,HM-LC-SW1-PL-OM54,HM-LC-SW1-PL2,HM-LC-SW1-SM,HM-LC-SW1-SM-2,HM-LC-SW1-SM-ATMEGA168,HM-LC-SW1PBU-FM,HM-LC-SW2-DR,HM-LC-SW2-DR-2,HM-LC-SW2-FM,HM-LC-SW2-FM-2,HM-LC-SW2-PB-FM,HM-LC-SW2-SM,HM-LC-SW2PBU-FM,HM-LC-SW4-BA-PCB,HM-LC-SW4-DR,HM-LC-SW4-DR-2,HM-LC-SW4-PCB,HM-LC-SW4-PCB-2,HM-LC-SW4-SM,HM-LC-SW4-SM-2,HM-LC-SW4-SM-ATMEGA168,HM-LC-SW4-WM,HM-LC-SW4-WM-2,HM-MOD-EM-8,HM-MOD-EM-8BIT,HM-MOD-RE-8,HM-OU-CF-PL,HM-OU-CFM-PL,HM-OU-CFM-TW,HM-OU-CM-PCB,HM-OU-LED16,HM-PB-2-FM,HM-PB-2-WM,HM-PB-2-WM55,HM-PB-2-WM55-2,HM-PB-4-WM,HM-PB-4DIS-WM,HM-PB-4DIS-WM-2,HM-PB-6-WM55,HM-PBI-4-FM,HM-RC-12,HM-RC-12-B,HM-RC-12-SW,HM-RC-19,HM-RC-19-B,HM-RC-19-SW,HM-RC-2-PBU-FM,HM-RC-2-PBU-FM-2,HM-RC-4,HM-RC-4-2,HM-RC-4-3,HM-RC-4-3-D,HM-RC-4-B,HM-RC-8,HM-RC-DIS-H-X-EU,HM-RC-KEY3,HM-RC-KEY3-B,HM-RC-KEY4-2,HM-RC-KEY4-3,HM-RC-P1,HM-RC-SEC3,HM-RC-SEC3-B,HM-RC-SEC4-2,HM-RC-SEC4-3,HM-SCI-3-FM,HM-SEC-CEN,HM-SEC-KEY,HM-SEC-KEY-O,HM-SEC-KEY-S,HM-SEC-MDIR,HM-SEC-MDIR-2,HM-SEC-MDIR-3,HM-SEC-RHS,HM-SEC-RHS-2,HM-SEC-SC,HM-SEC-SC-2,HM-SEC-SCO,HM-SEC-SD,HM-SEC-SD-2,HM-SEC-SFA-SM,HM-SEC-SIR-WM,HM-SEC-TIS,HM-SEC-WDS,HM-SEC-WDS-2,HM-SEC-WIN,HM-SEN-DB-PCB,HM-SEN-EP,HM-SEN-LI-O,HM-SEN-MDIR-O,HM-SEN-MDIR-O-2,HM-SEN-MDIR-O-3,HM-SEN-MDIR-SM,HM-SEN-MDIR-WM55,HM-SEN-RD-O,HM-SEN-WA-OD,HM-SWI-3-FM,HM-SYS-SRP-PL,HM-TC-IT-WM-W-EU,HM-WDC7000,HM-WDS10-TH-O,HM-WDS100-C6-O,HM-WDS100-C6-O-2,HM-WDS20-TH-O,HM-WDS30-OT2-SM,HM-WDS30-OT2-SM-2,HM-WDS30-T-O,HM-WDS40-TH-I,HM-WDS40-TH-I-2,HM-WS550,HM-WS550LCB,HM-WS550LCW,HM-WS550TECH,IS-WDS-TH-OD-S-R3,KFM-DISPLAY,KFM-SENSOR,KS550,KS550LC,KS550TECH,KS888,OLIGO-SMART-IQ-HM,PS-SWITCH,PS-TH-SENS,ROTO_ZEL-STG-RM-DWT-10,ROTO_ZEL-STG-RM-FDK,ROTO_ZEL-STG-RM-FEP-230V,ROTO_ZEL-STG-RM-FFK,ROTO_ZEL-STG-RM-FSA,ROTO_ZEL-STG-RM-FSS-UP3,ROTO_ZEL-STG-RM-FST-UP4,ROTO_ZEL-STG-RM-FWT,ROTO_ZEL-STG-RM-FZS,ROTO_ZEL-STG-RM-FZS-2,ROTO_ZEL-STG-RM-HS-4,ROTO_ZEL-STG-RM-WT-2,S550IA,SCHUECO_263-130,SCHUECO_263-131,SCHUECO_263-132,SCHUECO_263-133,SCHUECO_263-134,SCHUECO_263-135,SCHUECO_263-144,SCHUECO_263-145,SCHUECO_263-146,SCHUECO_263-147,SCHUECO_263-155,SCHUECO_263-157,SCHUECO_263-158,SCHUECO_263-160,SCHUECO_263-162,SCHUECO_263-167,SCHUECO_263-XXX,SENSOTIMER-ST-6,VIRTUAL,WDF-SOLAR,WS888 msgRepeat oldreadings param peerIDs readOnly:0,1 readingOnDead:multiple,noChange,state,periodValues,periodString,channels rssiLog:1,0 serialNr showtime:1,0 stateFormat:textField-long subType:AlarmControl,KFM100,THSensor,blindActuator,blindActuatorSol,dimmer,display,keyMatic,motionAndBtn,motionDetector,no,outputUnit,powerMeter,powerSensor,pushButton,remote,repeater,rgb,senBright,sensRain,sensor,singleButton,siren,smokeDetector,swi,switch,thermostat,threeStateSensor,timer,tipTronic,virtual,winMatic timestamp-on-change-reading
.triggerUsed 1
CFGFN
DEF 690962
FUUID 654e16f0-f33f-94f7-e403-6a2ea2489e6cf3e4
IODev hmusb
LASTInputDev hmusb
MSGCNT 147
NAME HM_690962
NR 2457
NTFY_ORDER 48-HM_690962
STATE open
TYPE CUL_HM
chanNo 01
disableNotifyFn 1
hmusb_MSGCNT 147
hmusb_RAWMSG E690962,0000,6B09A673,FF,FFC8,E8A6416909624242420157C8
hmusb_RSSI -56
hmusb_TIME 2023-11-10 12:53:21
lastMsg No:E8 - t:41 s:690962 d:424242 0157C8
protEvt_AESCom-ok 3 last_at:2023-11-10 12:45:09
protLastRcv 2023-11-10 12:53:21
protRcv 132 last_at:2023-11-10 12:53:21
protResnd 4 last_at:2023-11-10 12:44:27
protSnd 102 last_at:2023-11-10 12:53:21
protState CMDs_done
rssi_at_hmusb cnt:145 min:-66 max:-50 avg:-58.77 lst:-56
.attraggr:
.attrminint:
CL:
Authenticated 0
BUF
FD 87
FW_ID 2466
LASTACCESS 1699617272
NAME WEB_192.168.0.4_58242
NR 2471
PEER 192.168.0.4
PORT 58242
SNAME WEB
SSL 1
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
.attraggr:
.attrminint:
READINGS:
2023-11-10 12:54:29 state Connected
READINGS:
2023-11-10 12:47:59 .D-devInfo 810101
2023-11-10 12:47:59 .D-stc 80
2023-11-10 12:45:10 .R-cyclicInfoMsg on
2023-11-10 12:45:10 .R-eventDlyTime 0 s
2023-11-10 12:45:10 .R-msgScPosA open
2023-11-10 12:45:10 .R-msgScPosB closed
2023-11-10 12:45:10 .R-pairCentral 0x424242
2023-11-10 12:45:10 .R-sabotageMsg on
2023-11-10 12:45:10 .R-sign on
2023-11-10 12:45:10 .R-transmDevTryMax 6
2023-11-10 12:45:10 .R-transmitTryMax 6
2023-11-10 12:45:34 .associatedWith HM_690962,HM_690962
2023-11-10 12:45:34 .peerListRDate 2023-11-10 12:45:34
2023-11-10 12:53:21 .protLastRcv 20231110125321
2023-11-10 12:45:09 CommandAccepted yes
2023-11-10 12:47:59 D-firmware 1.0
2023-11-10 12:47:59 D-serialNr PEQ0567826
2023-11-10 12:53:21 IODev hmusb
2023-11-10 12:45:32 PairedTo 0x424242
2023-11-10 12:45:32 RegL_00. 00:00 02:01 09:01 0A:42 0B:42 0C:42 10:01 14:06
2023-11-10 12:45:33 RegL_01. 00:00 08:01 20:9C 21:00 30:06
2023-11-10 12:45:09 aesCommToDev ok
2023-11-10 12:45:09 aesKeyNbr 00
2023-11-10 12:45:07 alive yes
2023-11-10 12:53:21 battery ok
2023-11-10 12:47:54 cfgState RegPend,TrigUndef
2023-11-10 12:53:21 commState CMDs_done
2023-11-10 12:53:21 contact open (to hmusb)
2023-11-10 12:45:07 powerOn 2023-11-10 12:45:07
2023-11-10 12:45:07 recentStateType info
2023-11-10 12:45:07 sabotageError on
2023-11-10 12:53:21 state open
2023-11-10 12:53:21 trigDst_424242 noConfig
2023-11-10 12:44:17 trigDst_424244 noConfig
2023-11-10 12:53:21 trigger_cnt 87
helper:
HM_CMDNR 232
PONtest 0
cSnd 0142424269096201040000000001,014242426909620103
cfgStateUpdt 0
lastMsgTm 1699617201.84305
mId 00C7
peerFriend peerAct,peerVirt
peerIDsRaw ,00000000
peerIDsState complete
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 28
supp_Pair_Rep 0
cfgChk:
idPz05 424242
424244
idRc03 fail
cmds:
TmplKey :no:1699616542.60095
TmplTs 1699616542.60095
cmdKey 1:1:0::HM_690962:00C7:01:
cmdLst:
assignHmKey noArg
clear [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
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- [-peerChn-]
reset noArg
sign [(on|{off})]
tplDel -tplDel-
tplSet_0 -tplChan-
trgEventL -peer- -condition-
trgEventS -peer- -condition-
trgPressL [(-peer-|{all})]
trgPressS [(-peer-|{all})]
unpair noArg
lst:
condition closed,open,tilted
peer
peerOpt CUL_HM_HM_CC_RT_DN_2B3773_remote,CUL_HM_HM_CC_RT_DN_2C8D42_WindowRec,CUL_HM_HM_CC_RT_DN_2C8D42_remote,CUL_HM_HM_MOD_Re_8_2C0622_Sw_03,CUL_HM_HM_MOD_Re_8_2C0622_Sw_04,CUL_HM_HM_MOD_Re_8_2C0622_Sw_05,CUL_HM_HM_MOD_Re_8_2C0622_Sw_06,CUL_HM_HM_MOD_Re_8_2C0622_Sw_07,CUL_HM_HM_MOD_Re_8_2C0622_Sw_08,GarageAlt_Re8_01_Licht_u,GarageAlt_Re8_02_TorMotor_u,HM_354639_WindowRec,HM_354639_remote,HM_4DA3EC_WindowRec,HM_4DA3EC_remote,HM_4DA84C_WindowRec,HM_4DA84C_remote,HM_569B61_WindowRec,HM_569B61_remote,HM_588315_WindowRec,HM_588315_remote,HM_5A40CA_WindowRec,HM_5A40CA_remote,HM_6870BB_WindowRec,HM_6870BB_remote,HM_6A27A4,HM_727DE3_WindowRec,HM_727DE3_remote,H_Wz1_UG_3W,JalousieEG1,JalousieUG1,virt_Btn_1
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 0
det 0
raw 1
tpl 0
io:
flgs 1
newChn +690962,01,00,02
nextSend 1699617201.91509
rxt 2
vccu
p:
690962
01
00
02
prefIO:
mRssi:
mNo E8
io:
hmusb:
-50
-50
peerIDsH:
00000000 broadcast
prt:
bErr 0
sProc 0
sleeping 1
rspWait:
tryMsg:
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
rpt:
IO hmusb
flg A
ts 1699617201.84305
ack:
HASH(0xbbdf7358)
E880024242426909620101C800
rssi:
at_hmusb:
avg -58.7793103448276
cnt 145
lst -56
max -50
min -66
shadowReg:
RegL_01. 00:00 08:01 20:9C 21:00 30:06
tmpl:
role:
Attributes:
.mId 00C7
IODev hmusb
aesCommReq 1
autoReadReg 4_reqStatus
expert rawReg
firmware 1.0
model HM-SEC-SCO
peerIDs 00000000
serialNr PEQ0567826
subType threeStateSensor
hmusb als monitorZitat von: Ralf9 am 10 November 2023, 13:34:11am produktiv fhem am HM-CFG-USB gemonitort, dort habe ich keine signing request gesehen,
hier müsstest du eigentlich A002 msgs sehen können, die der hmusb empfängt.
die A003 msgs werden wohl bei hmlan und hmusb irgendwo gefiltert, eventuell in der fw.
mögliche fehler:
1. schaust du an der falschen stelle?
sniffen: am besten am io "attr logIDs all" setzen und im eventmonitor mit eingeschalteter logoption live beobachten. wenn du dann im browser noch "seite durchsuchen" nach der hmid des sco (690962) einschaltest, werden alle relevanten messages des sco markiert.
2. eventuell ist auf beiden systemen der sco gleichzeitig beiden io zugewiesen?
kontrolliere jeweils "get assignIDs" bei den io.
in 00_hmlan.pm gibt es zb ein bug, der das verursachen könnte. siehe https://forum.fhem.de/index.php?topic=134541.0 (https://forum.fhem.de/index.php?topic=134541.0)
falls falsch zugewiesen am besten fhem restarten.
3. oder werden messages gefiltert, weil du keine vccu nutzt?
vermutlich nicht, aber wer weiss.
hmuart als monitordas list zeigt probleme:
2023-11-10 12:47:54 cfgState RegPend,TrigUndef
2023-11-10 12:53:21 trigDst_424242 noConfig
2023-11-10 12:44:17 trigDst_424244 noConfig
TrigUndef kommt wegen ohne vccu.
besonders seltsam finde ich "trigDst_424244". da müsste ja der sco einen trigger an das testsystem gesendet haben. also noch mit dem testsystem gepairt gewesen sein.
beide fhem sind up-to-date?
Ich habe nun auf dem Testsystem am HmUARTLGW den HM-SEC-SCO angelernt und dann "attr aesCommReq 1" und "set sign on"
Hab dann mit einem nanocul monitort, damit habe ich nun die A002 und A603 msg empfangen
2023.11.11 16:53:55.921 4: CUL_Parse: CULnano A 0C 81 A641 690962 424244 0112002D -51.5
2023.11.11 16:53:56.049 4: CUL_Parse: CULnano A 11 81 A002 424244 690962 042E6B00006B1A0071 -17.5
2023.11.11 16:53:56.053 3: CULnano: Unknown code A1181A002424244690962042E6B00006B1A00::-17.5:CULnano, help me!
2023-11-11 16:53:56.053 CUL CULnano UNKNOWNCODE A1181A002424244690962042E6B00006B1A00::-17.5:CULnano
2023.11.11 16:53:56.169 0: HMUARTLGW myHmUARTLGW recv: 01 05 02 00 23 msg: 81 A6 41 690962 424244 011200
2023.11.11 16:53:56.176 4: CUL_Parse: CULnano A 19 81 A603 690962 424244 BD3C5470F2B867AED7C1AEAA2FD69C692D -51.5
2023.11.11 16:53:56.221 0: HMUARTLGW myHmUARTLGW send: 01 02 00 00 00 msg: 81 80 02 424244 690962 0101C800
2023-11-11 16:53:56.173 CUL_HM HM_690962 aesCommToDev: pending
2023-11-11 16:53:56.175 CUL_HM HM_690962 aesCommToDev: ok
2023-11-11 16:53:56.175 CUL_HM HM_690962 battery: ok
2023-11-11 16:53:56.175 CUL_HM HM_690962 commState: CMDs_done
2023-11-11 16:53:56.175 CUL_HM HM_690962 contact: closed (to myHmUARTLGW)
2023-11-11 16:53:56.175 CUL_HM HM_690962 closed
2023-11-11 16:53:56.175 CUL_HM HM_690962 trigDst_424244: noConfig
2023-11-11 16:53:56.175 CUL_HM HM_690962 trig_aes_myHmUARTLGW: ok:18
2023-11-11 16:53:56.175 CUL_HM HM_690962 trigger_cnt: 18
2023.11.11 16:53:56.234 0: HMUARTLGW myHmUARTLGW recv: 01 0408, state 101
2023.11.11 16:53:56.234 0: HMUARTLGW myHmUARTLGW IO currently busy, trying again in a bit
2023.11.11 16:53:56.285 0: HMUARTLGW myHmUARTLGW send: 01 02 00 00 00 msg: 81 80 02 424244 690962 0101C800
2023.11.11 16:53:56.288 4: CUL_Parse: CULnano A 0E 81 8002 424244 690962 006DFA368F71 -17.5
2023.11.11 16:53:56.290 3: CULnano: Unknown code A0E818002424244690962006DFA368F::-17.5:CULnano, help me!
2023-11-11 16:53:56.290 CUL CULnano UNKNOWNCODE A0E818002424244690962006DFA368F::-17.5:CULnano
2023.11.11 16:53:56.432 4: CUL_Parse: CULnano A 0D 81 8002 424244 690962 0101C80071 -17.5
2023.11.11 16:53:56.434 3: CULnano: Unknown code A0D8180024242446909620101C800::-17.5:CULnano, help me!
2023-11-11 16:53:56.434 CUL CULnano UNKNOWNCODE A0D8180024242446909620101C800::-17.5:CULnano
Zitat2. eventuell ist auf beiden systemen der sco gleichzeitig beiden io zugewiesen?
kontrolliere jeweils "get assignIDs" bei den io.
Ja, beim HM-CFG-USB steht nach unpair und delete bei assignIDs:
690962 : 690962
Da hätte ich dann ein fhem restart machen müssen
Beim myHmUARTLGW passt es da steht dann bei assignIDs 0
Zitatbesonders seltsam finde ich "trigDst_424244". da müsste ja der sco einen trigger an das testsystem gesendet haben. also noch mit dem testsystem gepairt gewesen sein.
Da hat beim ersten Versuch das anlernen beim HM-CFG-USB nicht geklappt, da war wahrscheinlich der HM-SEC-SCO nicht sauber vom Testsystem abgelernt.
Nach einem Reset am HM-SEC-SCO hat das Anlernen dann geklappt.
Sollten bei aktiven AES auch beim HM-CFG-USB die events "aesCommToDev" und "trig_aes_..." kommen?
Dann habe ich ein Problem beim HM-CFG-USB, ist mir aber nicht so wichtig, da ich AES nicht benötige.
Danke für Deine Geduld und Hilfe, nun ist mir das mit dem AES klarer geworden.