? zu HM-SEC-SCO und AES

Begonnen von Ralf9, 07 November 2023, 14:19:15

Vorheriges Thema - Nächstes Thema

Ralf9

Zitat von: Ralli am 06 November 2023, 15:39:13
Zitat 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

FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

frank

aes macht die fw des hmuart autonom.
das kann nur ein 2. io monitoren.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Ralf9

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.
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

frank

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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Ralf9

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.
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

frank

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
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Ralf9

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
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

frank

hmusb als monitor

Zitat 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
falls falsch zugewiesen am besten fhem restarten.

3. oder werden messages gefiltert, weil du keine vccu nutzt?
vermutlich nicht, aber wer weiss.


hmuart als monitor

das 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?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Ralf9

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.

FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7