Betreibe FHEM mit CUL am Raspberry PI. Benötige aber jetzt AES-Verschlüsselung!

Begonnen von pitman, 08 Dezember 2015, 16:02:17

Vorheriges Thema - Nächstes Thema

pitman

Hallo zusammen,

ich habe FHEM auf meinem Raspberry Pi laufen. Habe mir damals einen CUL geholt, da ich vorhatte FS20 und HM-Produkte zu verwenden.
Habe bisher allerdings nur HM-Produkte im Einsatz, weswegen ich damals wohl auch einfach einen HM-USB-CFG hätte bestellen können.

Bisher funktionierte alles mit dem CUL, allerdings möchte ich jetzt eine HM-Lichtschranke (HM-Sec-Sco) verwenden, die mit AES-Verschlüsselung arbeitet.

Da das mit meinem CUL nicht funktioniert, benötige ich jetzt wohl eine dieser beiden Lösungen: HM-LAN-CFG, HM-USB-CFG

Könnt ihr mir bitte kurz auf die Sprünge helfen, wie ich z.B. den HM-USB-Stick einbinden würde?
Macht es Sinn den HM-USB-Stick neben dem CUL am RaspberryPi laufen zu lassen? (Die AES-Geräte dann über den HM-USB-Stick, den Rest weiter über den CUL.)
Macht es Sinn nur noch den HM-USB-Stick zu verwenden und den CUL aus der Konfiguration zu nehmen?
Macht es Sinn den HM-USB-Stick statt am Raspberry Pi an meiner Synology Diskstation zu verwenden?

Was müsste ich noch wissen?

Würde mich freuen, wenn ihr mir ein wenig helfen könntet.
Vielen Dank vorab!

frank

auch aes geht mit dem cul.
eventuell brauchst du noch das perl modul Crypt::Rijndael.
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

pitman

Ach so. Hatte im Wiki gelesen, dass AES seit Juli 2015 mit einem CUL möglich ist.
Aber ich hatte angenommen, dass damit eine neue Hardware-Version des CUL gemeint war.

Danke für den Hinweis. Ich versuche mich mal daran...

pitman

Ist es auch möglich beim HM-Sec-Sco die AES-Verschlüsselung auszuschalten?
Wenn ja, geht das auch über die FHEM-Oberfläche?

pitman

Will noch einmal konkretisieren:
Habe gefunden, dass es bei den meisten HM-Produkten funktioniert.

Frage daher, ob jemand weiß, ob ich auch bei HM-Sec-Sco AES ausschalten kann?
Wäre interessant das zu wissen, bevor ich den Sensor bestelle.

frank

ZitatFrage daher, ob jemand weiß, ob ich auch bei HM-Sec-Sco AES ausschalten kann?
na klar. zum umstellen ist aber zunächst aes nötig. sollte aber mit deinem cul und aktuellem fhem funktionieren.
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

chris1284

ZitatKönnt ihr mir bitte kurz auf die Sprünge helfen, wie ich z.B. den HM-USB-Stick einbinden würde?
http://www.fhemwiki.de/wiki/HM-CFG-USB_USB_Konfigurations-Adapter
ZitatMacht es Sinn den HM-USB-Stick neben dem CUL am RaspberryPi laufen zu lassen? (Die AES-Geräte dann über den HM-USB-Stick, den Rest weiter über den CUL.)
jain. ich würde den cfg usb kaufen und den zu teuren cul verkaufen ( dann haste den stick locker wieder drin)
beachte die aes cul nachteile http://www.fhemwiki.de/wiki/AES_Encryption#Nachteile.2C_Einschr.C3.A4nkungen
mit vccu kannst du ohne aufwand auch mehrer ios nutzen.
ZitatMacht es Sinn nur noch den HM-USB-Stick zu verwenden und den CUL aus der Konfiguration zu nehmen?
wenn du beides hast schadet es nicht beide ios der vccu zur verfügung zu stellen. die vccu wählt dann das empfangstechnisch bessere io für die devices aus.
ZitatMacht es Sinn den HM-USB-Stick statt am Raspberry Pi an meiner Synology Diskstation zu verwenden?
absolut nicht! fhem auf nas ist eine krücke. das fängt bei fehlenden treibern für stick und cul an und hört bei nicht mehr schlafenden platten auf.
ZitatIst es auch möglich beim HM-Sec-Sco die AES-Verschlüsselung auszuschalten?
wieso auf sicherheit verzichten?

pitman

Vielen, vielen Dank für die ganzen Informationen. Ich gebe mich dann mal drann und versuche Eure Tipps umzusetzen...

Alcamar

schade, dass zur Ausschlaltung von AES nichts mehr geschrieben wurde.
ich habe das Problem, dass sich HM-SEC-SCo nicht richtig pairen lassen. In den Readings heißt es zwar PairedTo .... aber irgendwann ist der Eintrag weg und es steht da nur noch PairedTo 0x000000.
Ich habe gelesen, dass das eingeschlatete AES am Sensor das Problem ist. Also wäre Auschalten eine Option.

Ich verwende ein CUL und ein hmusb mit einer vccu. Auch da habe ich gelesen, dass es mit CUL und AES mit dem Crypt-Paket rijndael gehen sollte. Kann ich leider noch nicht bestätigen.
Mit dem hmusb müsste es allemal gehen. Leider aber auch das negativ. Kurzum, ich bekomme HM-SEC-SCo nicht stabil gepaired. :-( Alle Sensoren funktionieren allerdings und zeigen den jeweligen Status offen/geschlossen richtig an.

Und AES-Abschaltung am Fenstersensor habe ich mit set devicename sign off versucht. Klappt auch nicht. :(

frank

ZitatUnd AES-Abschaltung am Fenstersensor habe ich mit set devicename sign off versucht. Klappt auch nicht.
wenn kein pairing, dann auch kein setzen.

im wiki pairen siehst du, woran man ein korrektes pairing erkennt.
poste mal je ein list von vccu, hmusb, cul und 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

Alcamar

List von VCCU
Internals:
   CUL_0_MSGCNT 1002
   CUL_0_RAWMSG A1470845E330FE3000000843BBE00007D00320910FC::-105.5:CUL_0
   CUL_0_RSSI -105.5
   CUL_0_TIME 2016-03-03 15:48:41
   DEF        8F55B3
   IODev      CUL_0
   LASTInputDev hmusb
   MSGCNT     2068
   NAME       myVCCU
   NR         42
   NTFY_ORDER 50-myVCCU
   STATE      hmusb:ok,CUL_0:ok,
   TYPE       CUL_HM
   assignedIOs CUL_0,hmusb
   hmusb_MSGCNT 1066
   hmusb_RAWMSG E330FE3,0000,0A9281D0,FF,FFA4,70845E330FE3000000843BBE00007D00320910FC
   hmusb_RSSI -92
   hmusb_TIME 2016-03-03 15:48:41
   lastMsg    No:08 - t:02 s:8F55B3 d:1E5FB2 00
   protLastRcv 2016-03-03 13:32:49
   protSnd    2 last_at:2016-03-03 15:44:10
   protState  CMDs_done
   rssi_at_CUL_0 avg:-24.5 min:-25 max:-24 lst:-24 cnt:2
   Readings:
     2016-03-03 13:32:49   CommandAccepted yes
     2015-08-05 11:50:08   aesReqTo        TH_FensterTuer
     2016-02-23 19:53:50   recentStateType ack
     2016-03-03 11:02:00   state           hmusb:ok,CUL_0:ok,
[...]
     2015-06-21 12:00:41   unknown_387E0E  received
     2015-06-20 09:04:06   unknown_387E37  received
     2015-06-20 10:03:04   unknown_387E40  received
     2015-06-21 11:26:01   unknown_387E49  received
     2015-06-21 12:13:22   unknown_387E5F  received
     2015-07-15 17:28:37   unknown_387E76  received
     2015-07-12 23:34:14   unknown_387E78  received
     2015-06-21 12:40:26   unknown_387EB5  received
     2015-07-15 14:23:51   unknown_387EBE  received
     2015-06-21 10:12:03   unknown_387EEA  received
     2015-07-05 14:13:41   unknown_387EF2  received
[...]
     2016-02-22 20:55:02   unknown_999999  received
   Helper:
     HM_CMDNR   10
     mId        FFF0
     rxType     1
     Expert:
       def        1
       det        0
       raw        0
       tpl        0
     Io:
       nextSend   1457008369.98294
       prefIO
       vccu
       ioList:
         hmusb
         CUL_0
     Mrssi:
       mNo        08
       Io:
         CUL_0      -22
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
       vrt        1
     Rssi:
       At_cul_0:
         avg        -24.5
         cnt        2
         lst        -24
         max        -24
         min        -25
Attributes:
   IODev      CUL_0
   IOList     hmusb,CUL_0
   comment    Virtueller Controller
   model      CCU-FHEM
   room       Server
   subType    virtual
   webCmd     virtual:update


List hmusb:
Internals:
   DEF        192.168.178.43:1234
   DeviceName 192.168.178.43:1234
   FD         7
   IFmodel    LAN
   NAME       hmusb
   NR         9
   NTFY_ORDER 50-hmusb
   PARTIAL
   RAWMSG     E1E9823,0000,0A96FC57,FF,FFBA,CF84101E98238F55B30601C800
   RSSI       -70
   STATE      opened
   TYPE       HMLAN
   XmitOpen   1
   assignedIDsCnt 11 report:10
   hmusb_MSGCNT 2840
   hmusb_TIME 2016-03-03 15:53:35
   msgKeepAlive dlyMax:9.654 bufferMin:-4
   msgLoadCurrent 0
   msgLoadHistory 5min steps: 0/0/0/0/0/0/0/0/0/0/0/0
   msgParseDly min:-709 max:5108 last:249 cnt:2703
   owner      8F55B3
   owner_CCU  myVCCU
   uptime     002 49:21:07.159
   Readings:
     2016-03-03 11:02:00   D-HMIdAssigned  8F55B3
     2016-03-03 11:02:00   D-HMIdOriginal  2CC7A3
     2016-03-03 11:02:00   D-firmware      0.964
     2016-03-03 11:02:00   D-serialNr      LEQ0658848
     2016-03-03 11:02:00   Xmit-Events     ok:1 disconnected:1 init:1
     2016-03-03 11:02:00   cond            ok
     2016-03-03 15:53:18   loadLvl         low
     2016-03-03 11:01:24   prot_disconnected last
     2016-03-03 11:01:24   prot_init       last
     2016-03-03 11:02:00   prot_ok         last
     2016-02-24 20:48:50   prot_timeout    last
     2016-03-03 11:01:24   state           opened
   Helper:
     assIdCnt   11
     assIdRep   10
     info       03C4,LEQ0658848,2CC7A3,8F55B3
     setTime    44464
     Cnd:
       0          1
       253        1
       255        1
     Dly:
       cnt        2703
       lst        249
       max        5108
       min        -709
     Ids:
       1dae5d:
         cfg        +1DAE5D,00,00,00
         chn        06
         flg        0
         msg
         name       HMRemote01
         to         1457009342.41755
       1e5fb2:
         cfg        +1E5FB2,00,00,00
         chn        01
         flg        0
         msg
         name       WZ_DimmerTV
         to         1457008374.18863
       1e7906:
         cfg        +1E7906,00,00,00
         chn        01
         flg        0
         msg
         name       Garagentor
         to         1457011696.28854
       1e8ae2:
         cfg        +1E8AE2,00,00,00
         chn        00
         flg        0
         msg
         name       SD_Studio
         to         1457003204.22215
       1eb6b6:
         cfg        +1EB6B6,00,00,00
         chn        80
         flg        0
         msg
         name       StatusMonitor
         to         1457011910.10902
       2076bb:
         cfg        +2076BB,00,00,00
         chn        01
         flg        0
         msg
         name       SteckdoseMultimedia
         to         1457008290.66756
       249f03:
         cfg        +249F03,00,00,00
         chn        01
         flg        0
         msg
         name       Haus_Bewegungsmelder_1
         to         1457016434.75725
       2919d1:
         cfg        +2919D1,00,00,00
         chn        02
         flg        0
         msg
         name       GarageSwitch
         to         1457012050.32023
       33752b:
         cfg        +33752B,00,00,00
         chn        08
         flg        0
         msg
         name       HMRemote03
         to         1457009054.41307
       387eea:
         cfg        +387EEA,00,00,00
         chn        01
         flg        0
         msg
         name       KE_Fenster_2
         to         1457016351.27992
       39796b:
         flg        0
     K:
       BufMin     -4
       DlyMax     9.654
       Next       1457016823.05737
       Start      1457016798.05737
     Loadlvl:
       bl         40
       a:
         99
         90
         40
         0
       H:
         0          low
         40         batchLevel
         90         high
         99         suspended
     Log:
       all        0
       sys        0
       ids:
         ARRAY(0xeee350)
     Q:
       HMcndN     0
       answerPend 0
       hmLanQlen  1
       keepAliveRec 1
       keepAliveRpt 0
       loadLast   0
       loadNo     10
       scnt       3
       apIDs:
     Ref:
       drft       -2.99961005069341e-05
       hmtL       177649992
       kTs        0
       offL       1456839148078
       sysL       1457016773066
Attributes:
   hmId       8F55B3
   hmLanQlen  1_min
   loadLevel  0:low,40:batchLevel,90:high,99:suspended
   room       Server


List CUL:
Internals:
   CMDS       BbCFiAZEGMKUYRTVWXefmltux
   CUL_0_MSGCNT 2669
   CUL_0_TIME 2016-03-03 15:55:03
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
   DEF        /dev/ttyACM0@9600 1034
   DeviceName /dev/ttyACM0@9600
   FD         6
   FHTID      1034
   NAME       CUL_0
   NR         7
   NR_CMD_LAST_H 94
   PARTIAL
   RAWMSG     A0C75867020695800000000B82C23
   RSSI       -56.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.61 CUL868
   initString X21
Ar
   owner_CCU  myVCCU
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
   Readings:
     2016-03-03 11:01:23   cmds             B b C F i A Z E G M K U Y R T V W X e f m l t u x
     2016-03-02 15:58:27   raw             V 1.61 CUL868
     2016-03-03 15:55:03   state           Initialized
   XMIT_TIME:
     1457012852.74671
     1457012879.99449
     1457012911.1417
     1457012911.65444
     1457012911.74224
     1457012912.5056
     1457012956.54792
     1457012957.40378
     1457012957.49428
     1457012958.00518
     1457012958.11384
     1457012976.16725
     1457012976.26858
     1457013030.43718
     1457013258.80547
     1457013258.90701
     1457013671.60998
     1457013804.67323
     1457013981.26492
     1457014030.78814
     1457014030.89054
     1457014033.99201
     1457014172.81201
     1457014223.41942
     1457014224.3265
     1457014224.77546
     1457014225.20459
     1457014308.48429
     1457014315.40932
     1457014350.40298
     1457014379.06409
     1457014417.7201
     1457014454.83114
     1457014455.3426
     1457014455.43126
     1457014456.19173
     1457014456.24571
     1457014456.26128
     1457014456.4479
     1457014581.86987
     1457014582.3989
     1457014582.48711
     1457014582.99686
     1457014601.59556
     1457014602.32652
     1457014602.41766
     1457014602.94152
     1457014633.0473
     1457014633.56137
     1457014687.52349
     1457014688.06983
     1457014688.69543
     1457014757.7893
     1457014758.28439
     1457014758.7336
     1457014759.16178
     1457014795.90823
     1457014826.82179
     1457014858.73971
     1457014902.78257
     1457014948.74551
     1457014949.25989
     1457014949.34761
     1457014950.15903
     1457015080.08797
     1457015080.80959
     1457015080.90046
     1457015081.69429
     1457015107.79637
     1457015108.31256
     1457015108.88732
     1457015319.23422
     1457015319.96226
     1457015320.05006
     1457015320.55902
     1457015449.24538
     1457015450.50554
     1457015450.59531
     1457015451.12812
     1457015451.25578
     1457015499.32653
     1457015499.87473
     1457015500.41
     1457015611.75332
     1457015612.2513
     1457015612.6834
     1457015613.1154
     1457015716.70803
     1457015853.39847
     1457015901.74688
     1457015937.56963
     1457015937.73929
     1457016250.54843
     1457016445.37806
   Helper:
     000000:
       QUEUE:
     1b51cb:
       QUEUE:
     1c78e2:
       QUEUE:
     206a75:
       QUEUE:
     2da5b1:
       QUEUE:
     33752b:
       QUEUE:
     34623b:
       QUEUE:
     3822a4:
       QUEUE:
     387e37:
       QUEUE:
     387e40:
       QUEUE:
     387e49:
       QUEUE:
     387e5f:
       QUEUE:
     387e76:
       QUEUE:
     387e78:
       QUEUE:
     387eb5:
       QUEUE:
     387ebe:
       QUEUE:
     387eea:
       QUEUE:
     387ef2:
       QUEUE:
     39796b:
       QUEUE:
Attributes:
   hmId       8F55B3
   icon       icoSYSTEM
   rfmode     HomeMatic
   room       Server
   verbose    3


und List von dem sco, das offensichtlich nicht gepaired ist(, aber siehe unten weitere sco):
Internals:
   CUL_0_MSGCNT 175
   CUL_0_RAWMSG A0D1F8610387EEA00000006010000::-47:CUL_0
   CUL_0_RSSI -47
   CUL_0_TIME 2016-03-03 15:46:55
   DEF        387EEA
   IODev      hmusb
   LASTInputDev hmusb
   MSGCNT     359
   NAME       KE_Fenster_2
   NR         1298
   NTFY_ORDER 50-KE_Fenster_2
   STATE      closed
   TYPE       CUL_HM
   hmusb_MSGCNT 184
   hmusb_RAWMSG E387EEA,0000,0A90E209,FF,FFC9,1F8610387EEA00000006010000
   hmusb_RSSI -55
   hmusb_TIME 2016-03-03 15:46:55
   lastMsg    No:1F - t:10 s:387EEA d:000000 06010000
   protCmdDel 15
   protLastRcv 2016-03-03 15:46:55
   protNack   3 last_at:2016-03-03 15:42:07
   protResnd  5 last_at:2016-03-03 15:40:50
   protResndFail 1 last_at:2016-03-03 15:37:49
   protSnd    35 last_at:2016-03-03 15:45:49
   protState  CMDs_done
   rssi_at_CUL_0 avg:-43.13 min:-47 max:-41 lst:-47 cnt:175
   rssi_at_hmusb avg:-50.99 min:-57 max:-49 lst:-55 cnt:184
   Readings:
     2016-03-03 15:45:48   Activity        alive
     2016-03-03 15:42:07   CommandAccepted no
     2016-03-03 15:45:48   D-firmware      1.0
     2016-03-03 15:45:48   D-serialNr      MEQ0183971
     2016-03-03 15:45:48   PairedTo        0x000000
     2016-03-03 15:39:20   R-cyclicInfoMsg on
     2016-03-03 15:40:45   R-eventDlyTime  0 s
     2016-03-03 15:39:20   R-pairCentral   0x000000
     2016-03-03 15:39:20   R-sabotageMsg   on
     2016-03-03 15:40:45   R-sign          on
     2016-03-03 15:45:48   RegL_00.          02:00 09:01 0A:00 0B:00 0C:00 10:01 14:06 00:00
     2016-03-03 15:45:49   RegL_01.          08:01 20:9C 21:00 30:06 00:00
     2016-03-03 15:38:43   aesCommToDev    fail
     2016-03-03 15:33:33   aesKeyNbr       00
     2016-03-03 15:46:55   alive           yes
     2016-03-03 15:46:55   battery         ok
     2016-03-03 15:46:55   contact         closed (to broadcast)
     2016-03-03 15:46:55   recentStateType info
     2016-03-03 15:46:55   sabotageError   off
     2016-03-03 15:46:55   state           closed
     2016-03-03 15:46:51   trigger_cnt     7
   Helper:
     HM_CMDNR   31
     PONtest    0
     cSnd       018F55B3387EEA01040000000001,018F55B3387EEA0103
     mId        00C7
     peerIDsRaw ,00000000
     rxType     28
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +387EEA,00,00,00
       nextSend   1457016415.37583
       rxt        2
       vccu       myVCCU
       p:
         387EEA
         00
         00
         00
       prefIO:
         hmusb
     Mrssi:
       mNo        1F
       Io:
         CUL_0      -47
         hmusb      -53
     Prt:
       bErr       0
       sProc      0
       sleeping   0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_cul_0:
         avg        -43.1314285714286
         cnt        175
         lst        -47
         max        -41
         min        -47
       At_hmusb:
         avg        -50.9945652173913
         cnt        184
         lst        -55
         max        -49
         min        -57
     Shadowreg:
Attributes:
   IODev      CUL_0
   IOgrp      myVCCU:hmusb
   actCycle   000:50
   actStatus  alive
   autoReadReg 5_readMissing
   devStateIcon .*open:fts_window_2w_open .*closed:fts_window_2w
   expert     2_full
   firmware   1.0
   group      Fenstersensor
   icon       fts_window_2w
   model      HM-SEC-SCo
   peerIDs    00000000,
   room       EG,KEZ
   serialNr   MEQ0183971
   status     EG_Fenster
   subType    threeStateSensor
   userattr   room_map status status_map structexclude


List weitere sco:
Internals:
   CUL_0_MSGCNT 6
   CUL_0_RAWMSG A0D2CA610387EBE8F55B306010000::-54:CUL_0
   CUL_0_RSSI -54
   CUL_0_TIME 2016-03-03 15:47:25
   DEF        387EBE
   IODev      CUL_0
   LASTInputDev hmusb
   MSGCNT     12
   NAME       KE_Fenster_1
   NR         1353
   NTFY_ORDER 50-KE_Fenster_1
   STATE      closed
   TYPE       CUL_HM
   hmusb_MSGCNT 6
   hmusb_RAWMSG E387EBE,0000,0A91578E,FF,FFC1,2CA610387EBE8F55B306010000
   hmusb_RSSI -63
   hmusb_TIME 2016-03-03 15:47:25
   lastMsg    No:2C - t:10 s:387EBE d:8F55B3 06010000
   protLastRcv 2016-03-03 15:47:25
   protSnd    6 last_at:2016-03-03 15:47:25
   protState  CMDs_done
   rssi_at_CUL_0 avg:-53.58 min:-54 max:-53.5 lst:-54 cnt:6
   rssi_at_hmusb avg:-62.66 min:-63 max:-62 lst:-63 cnt:6
   Readings:
     2016-03-03 15:55:48   Activity        alive
     2016-03-02 16:48:52   CommandAccepted yes
     2016-03-02 16:48:50   D-firmware      1.0
     2016-03-02 16:48:50   D-serialNr      MEQ0183927
     2016-03-02 16:48:52   PairedTo        0x8F55B3
     2016-03-02 16:48:52   R-cyclicInfoMsg on
     2016-03-02 16:48:53   R-eventDlyTime  0 s
     2016-03-02 16:48:52   R-pairCentral   0x8F55B3
     2016-03-02 16:48:52   R-sabotageMsg   on
     2016-03-02 16:48:53   R-sign          on
     2016-03-02 16:48:52   RegL_00.        02:01 09:01 0A:8F 0B:55 0C:B3 10:01 14:06 00:00
     2016-03-02 16:48:53   RegL_01.        08:01 20:9C 21:00 30:06 00:00
     2016-03-02 16:48:52   aesCommToDev    ok
     2016-03-02 16:48:52   aesKeyNbr       00
     2016-03-03 15:47:25   alive           yes
     2016-03-03 15:47:25   battery         ok
     2016-03-03 15:47:25   contact         closed (to myVCCU)
     2016-03-03 15:47:25   recentStateType info
     2016-03-03 15:47:25   sabotageError   off
     2016-03-03 15:47:25   state           closed
     2016-03-02 16:47:05   trigger_cnt     66
   Helper:
     HM_CMDNR   44
     mId        00C7
     rxType     28
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +387EBE,00,00,00
       nextSend   1457016445.46201
       rxt        2
       vccu       myVCCU
       p:
         387EBE
         00
         00
         00
       prefIO:
         CUL_0
     Mrssi:
       mNo        2C
       Io:
         CUL_0      -52
         hmusb      -63
     Prt:
       bErr       0
       sProc      0
       sleeping   1
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         CUL_0
       flg        A
       ts         1457016445.37577
       ack:
         HASH(0x20abbc8)
         2C80028F55B3387EBE00
     Rssi:
       At_cul_0:
         avg        -53.5833333333333
         cnt        6
         lst        -54
         max        -53.5
         min        -54
       At_hmusb:
         avg        -62.6666666666667
         cnt        6
         lst        -63
         max        -62
         min        -63
Attributes:
   IODev      CUL_0
   IOgrp      myVCCU:CUL_0
   actCycle   000:50
   actStatus  alive
   autoReadReg 5_readMissing
   devStateIcon .*open:fts_door_right_open .*closed:fts_door_right
   expert     2_full
   firmware   1.0
   group      Fenstersensor
   icon       fts_door_right
   model      HM-SEC-SCo
   peerIDs    00000000,
   room       EG,KEZ
   serialNr   MEQ0183927
   subType    threeStateSensor


Der aktuelle nicht gepaired sco war zuvor auch mit VCCU:CUL gepaired und plötzlich hat er diese Infos verloren. Also habe ich auch mal VCCU:hmusb als IOgrp eingetragen. Aber das hilft nichts.
Für mich ist das so, dass die IO-Devices sich nicht mit den Fenstersensoren sauber pairen wollen. Jetzt weiss ich, dass es beim pairen entweder oder gibt. Aber hier würde ich sagen, dass nur zeitweise ein richtiges pairing vorliegt. Also in den Registern PairedTo 0xblabla.

Ich hoffe, dass ich das nicht zu chaotisch dargestellt habe.

frank

pairen bedeutet: die ID der zentrale (8F55B3) ins eeprom vom device schreiben.

also weder zeitweise richtig gepaired, noch fast gepaired, ..... => entweder steht die id drin oder nicht.
löschen nur über werkreset (selbst das nur, wenn kein eigener aes key gesetzt ist).

1. dein hmusb braucht fw 0.967 und aktuellen hmland.
2. fhem muss tagesaktuell sein.
3. dein gepairter sco ist auch gesichert. also muss mindestens ein io beim pairen aes gekonnt haben. da der cul die besten rssi hat, wird wohl die vccu den cul zum pairen benutzt haben.
4. als prefered io (IOgrp) am besten immer den io mit den besten rssi eintragen.
5. da der fk meistens schläft, musst du ihn nach dem hmpairforsec wecken, damit er die befehle empfangen kann. entweder knöpfchen drücken (funktioniert bei jedem device) oder fenster öffnen, da dieser fk auch lazy config kann.
6. einfach noch mal drüber pairen, bis es funktioniert.

7. immer ruhig bleiben.  8)
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

Alcamar

Danke Frank!

hmland und firmware-Update vom hmusb habe ich vorgenommen.
Danach weiss nicht wie oft ich das gleiche weiderholt habe, bis endlich der Sensor gepaired ist.
Ich verstehe, dass die ID entweder im Device geschrieben wurde, oder nicht. Damit ist auch festgelegt, ob das pairing vollzogen wurde, oder nicht. Trotzdem meine Frage:
Kann es eine Konstallation geben, wo das beschriebene Device wieder seine eingetragene IO-Device-ID verliert?
Mir kommt bzw. kam es so vor. Weil der Fenstersensor wie alle übrigen gepaired war. In meiner Fenstersensorsammlung gibt es noch einen weiteren, der das gleiche Fehlerbild hat. Da sitze ich noch dran.

Mein weiterer Eindruck ist, dass es einen deterministischen Weg gibt, der dieses pairen am Ende vollzieht. Ich habe einfach immer das gleiche wiederholt (hmPairForSec, Knopf drücken am Sensor) irgendwann ging es, aber warum? Vielleicht spielt auch die Zeit ein Rolle, weil nur die ist beim stupiden wiederholen nicht immer exakt gleich. Sonst sind die Schritte immer die gleichen gewesen. Ab und zu habe ich den Sensor auf die Werkseinstellungen zurückgesetzt. Oder ist doch alles nur Zufall. :-)

Bringt es was, wenn die ich Konfiguration sichere? könnte ich diese wieder zum Sensor spielen, wenn er "spinnt"? Vielleicht bin ich es der spinnt. :-)


frank

zufall würde ich mal von deiner agenda streichen. ausserdem ist immer eine optimale funkverbindung grundvoraussetzung für eine korrekte kommunikation. besonders wenn aes im spiel ist, da hier noch mehr gefunkt wird.

ich denke du musst die kommunikationsprozedur mal in ruhe testen, zb mit getconfig. besonders mit batteriedevices die geweckt werden müssen. bei jedem wecken werden nämlich nicht alle anstehenden (pending) cmds abgeholt/ausgeführt, sondern immer häppchenweise. am besten mal im detailfenster des devices unter internals die protokolldaten beobachten. aber beachte, dass diese daten nicht automatisch aktualisiert werden, sondern erst nach einem aktualisieren der website.

wenn man viele cmds absetzt (eventuell über nervöses rumklicken) kann die cmdqueue sehr schnell, sehr lang werden. somit können zb vor dem pairen bereits cmds in der queue hängen, wodurch vielleicht alles ein wenig seltsam erscheint. am besten vor einem cmd, die queue leeren mit set clear msgEvents. erst bei cmds_done wurde die kommunikation erfolgreich beendet.

wie gesagt, kann ein pairing eigentlich nur durch reset am device verloren gehen. um das device von fhem zu resetten, muss es erst gepairt sein.

sichern ist immer gut.  8)
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

Alcamar

sichern ist zwar gut, aber Im Nachhinein ist mir eingefallen, dass mir das wenig bringt, wenn das pairing sich aufgelöst hat. Weil dann doch auch kein Rückspielen des Backups möglich ist, oder?
Ich glaube nämlich, dass ich in meinem Sicherungswahn mal alle Devices gesichert habe.  :)

Man braucht schon etwas Geduld mit diesen Spielzeugen. :-)