HM-CC-RT-DN pairing problems

English Forums Devices
#1

Dear all,

I’m just trying to pair a HM-CC-RT-DN with Homegear using a Homematic-CUL (Busware). I already paired some HM-Sec-SCo without any problems.

But trying to pair the HM-CC-RT-DN doesn’t work. Even trying to reset of the device doesn’t help.

The log seems to contain a packet from my device:

10/07/17 21:25:39.240 Debug (MyCUL): Packet 1A018400511F070000001400954E45513135313630373759xxxxxx enters raisePacketReceived.
10/07/17 21:25:39.240 Debug (MyCUL): Packet 1A018400511F070000001400954E45513135313630373759xxxxxx is now passed to the EventHandler.
10/07/17 21:25:39.240 HomeMatic BidCoS packet received (MyCUL, RSSI: -50 dBm): 1A018400511F070000001400954E45513135313630373759xxxxxx
10/07/17 21:25:39.240 Debug (MyCUL): Packet processing of packet 1A018400511F070000001400954E45513135313630373759xxxxxx took 0 ms.

The configuration of Homegear is as follows (homematicbidcos.conf):

#######################################
########## General Settings  ##########
#######################################
rfKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

## With each key change currentRFKeyIndex needs to be
## incremented by 1
currentRfKeyIndex = 1

## When you change rfKey, put the old key here. To change the key Homegear needs to know the
## old and the new one.
## !!! Do not set oldRFKey when you set rfKey for the first time !!!
#oldRFKey = 00112233445566778899AABBCCDDEEFF

## When set to "true" unsigned broadcast packets are processed by Homegear. This could enable an
## attacker to make Homegear do things, you don't want. That means, this option is a security
## risk.
processBroadcastWithAesEnabled = true (I also tried 'false')

#######################################
################# CUL #################
#######################################

## The device family this interface is for
[CUL]

## Specify an unique id here to identify this device in Homegear
id = MyCUL

## When default is set to "true" Homegear will assign this device
## to new peers.
default = true

## Options: cul, cc1100, coc, cunx, hmcfglan, hmlgw, hm-mod-rpi-pcb
deviceType = cul

device = /dev/ttyACM0

## Default: responseDelay = 95
## Should be "95" for CUL or COC, "100" for TI CC1101 and "60" for HM-CFG-LAN or HM-LGW
responseDelay = 95

(... the rest are comments)

homegear.err doesn’t show any errors.

Does anyone have an idea why pairing isn’t successful? Is there maybe a configuration mistake or something?

For pairing I do the following steps:

  1. homegear -r
  2. fs 0
  3. pon
  4. Start pairing on the device, which then counts from 30 to 0 without any further information

Thank you in advance!

Best regards

HM-CC-RT-DN an USB-nanoCUL pairen nicht
#2

Hey @flux,

can you make sure, that the HM-CC-RT-DN have not been paired to another central with another AES-key?

If so, pair them again to the “old” central and disable AES or unpair them explicitely. After that you can pair them to homegear with the new AES-key.

Cheers,
p

#3

Hey @pmayer,

thanks for your reply!

Just bought the device yesterday (new device, not “second-hand”) and do not own another central, so it “theoretically” couldn’t be paired to another central with another AES-Key.

Do you know if I can verify that in any way that it wasn’t paired to another central?

Cheers

#4

Hmm. Sorry, no.
I think @sathya has to jump in.

#5

Just found a “solution”. Posting it here, if someone has a similar case:

Setting the “centralAddress” to a individual value or commenting it out didn’t work. Setting it to

centralAddress = 0xFD0001

works.

Thanks for your help!

#6