Zigbee third party end device connection with nRF52840 coordinator

[DaKa]

Hello,

I am developing a zigbee coordinator with a BMD340 module (using the nRF52840). I want to support several third party device with the coordinator. I am able to connect and use an Elko thermostat and Elko dimmer. But I try to connect and use an Elko PIR sensor, and it keeps joining and leaving the network (even if the authorization status is 0). Legacy is enabled (using bdb legacy enable command). What could be the issue? I tried to use an Xbee dongle for testing, and it joins the network normally.
I also noticed that sometimes the different signals when new device join the network are happening several times.

BR,
Damien

[Marte Myrvold]

Hi Damien,

Are you basing your zigbee coordinator on one of our examples, and if so which one and which version of the SDK?

Could you please capture a sniffer log? You can see how to do this here.

Best regards,

Marte

[DaKa]

Yes I am basing the zigbee coordinator on the CLI Agent example. My application is written in python, and I send commands to the CLI via UART to control and maintain the network.
I am using the nRF5_SDK_for_Thread_and_Zigbee_v4.0.0_dc7186b SDK.

Attached there is a sniffer log. I did not use sniffer a lot, so I don't know if it is what you need. I created a new network by resetting the module and sending the setup commands (channel, role, start) and then put the end device in pairing mode.
The log in the cli looked like this:

<info> app: Device authorization event received (short: 0xB905, long: 000d6ffffed3b1fd, authorization type: 1, authorization status: 1)
<info> app: Unimplemented signal (signal: 21, status: 0)
<info> app: Device authorization event received (short: 0xB905, long: 000d6ffffed3b1fd, authorization type: 1, authorization status: 1)
<info> app: Device authorization event received (short: 0xB905, long: 000d6ffffed3b1fd, authorization type: 1, authorization status: 1)
<info> app: Device update received (short: 0xDE9A, long: 000d6fff, status: 1)
<info> app: Device update received (short: 0xDE9A, long: 000d6ffffed3b1fd, status: 1)
<info> app: Device update received (short: 0xDE9A, long: 000d6ffffed3b1fd, status: 1)
<info> app: New device commissioned or rejoined (short: 0xDE9A)
<info> app: Device authorization event received (short: 0xDE9A, long: 000d6ffffed3b1fd, authorization type: 1, authorization status: 0)
<info> app: Child left the network (long: 000d6ffffed3b1fd, rejoin flag: 0)
<info> app: Unimplemented signal (signal: 21, status: 0)
<info> app: Unimplemented signal (signal: 21, status: 0)
<info> app: Device authorization event received (short: 0xDE9A, long: 000d6ffffed3b1fd, authorization type: 1, authorization status: 1)
<info> app: Device authorization event received (short: 0xDE9A, long: 000d6ffffed3b1fd, authorization type: 1, authorization status: 1)
<info> app: Device update received (short: 0x71E3, long: 000d6ffffed3b1fd, status: 1)
<info> app: Device update received (short: 0x71E3, long: 000d6fff, status: 1)
<info> app: Device update received (short: 0x71E3, long: 000d6ffffed3b1fd, status: 1)
<info> app: New device commissioned or rejoined (short: 0x71E3)
<info> app: Child left the network (long: 000d6ffffed3b1fd, rejoin flag: 0)
<info> app: Device authorization event received (short: 0x71E3, long: 000d6ffffed3b1fd, authorization type: 1, authorization status: 1)
<info> app: Unimplemented signal (signal: 21, status: 0)
<info> app: Device authorization event received (short: 0x71E3, long: 000d6ffffed3b1fd, authorization type: 1, authorization status: 1)
<info> app: Device authorization event received (short: 0x71E3, long: 000d6ffffed3b1fd, authorization type: 1, authorization status: 1)
<info> app: Device update received (short: 0x5EA9, long: 000d6ffffed3b1fd, status: 1)
<info> app: Device update received (short: 0x5EA9, long: 000d6ffffed3b1fd, status: 1)
<info> app: Device update received (short: 0x5EA9, long: 000d6fff, status: 1)
<info> app: New device commissioned or rejoined (short: 0x5EA9)
<info> app: Child left the network (long: 000d6ffffed3b1fd, rejoin flag: 0)
<info> app: Device authorization event received (short: 0x5EA9, long: 000d6ffffed3b1fd, authorization type: 1, authorization status: 1)
<info> app: Unimplemented signal (signal: 21, status: 0)
<info> app: Device authorization event received (short: 0x5EA9, long: 000d6ffffed3b1fd, authorization type: 1, authorization status: 1)
<info> app: Device authorization event received (short: 0x5EA9, long: 000d6ffffed3b1fd, authorization type: 1, authorization status: 1)
>

BR,
Damien

zigbee_sniff.pcapng

[Marte Myrvold]

Hi,

The first picture below is from your sniffer log. You can see the packets "Request Key", "Transport Key", and "Verify Key", and then it leaves after that. This is because your device does not get a "Confirm Key, SUCCESS" as you can see in the second picture, which is from a sniffer log I captured. The Zigbee specification says that if the node is not successful in retrieving the key, then it shall perform a leave request, which is why the sensor leaves.

The reason the Elko PIR sensor does not retrieve the key is because it uses a cluster called IAS Zone, which gives extra security for the device, and has an extra step in the commissioning process.

Unfortunately, we do not have an example for IAS Zone server/client cluster, but you can implement IAS enrollment yourself based on our SDK and using the specification for the IAS Zone cluster. I recommend reading the information about IAS Zone cluster closely if you want to try and implement it yourself.

Please let me know if you have any other questions!

Best regards,

Marte

[DaKa]

Hi,

Ok, thanks for your reply.
I don't really understand what I need to do... Do I need to update modify the firmware?
Does it have something to do with the install code? Because there is an install code printed on the device. But I don't understand how to use it with the CLI or what are the steps to configure it.

BR,
Damien

[Marte Myrvold]

Hi,

You would need to modify the application running on your Zigbee coordinator in order to implement IAS Zone enrollment. You should be able to base it on the examples in the SDK, such as CLI, which you're already doing.

You can find find information about the IAS Zone cluster in the ZCL specification, specifically chapter 8.2. Implementation guidelines can be found in chapter 8.2.2.2.3, where you can find information about the additional enrollment step. I recommend reading this to better understand what you have to do in order to get IAS Zone enrollment to work.

Best regards,

Marte

[DaKa]

Hi,

Sorry but I'm still a bit confused... I am using a custom PCB where a BMD340 module is mounted and flashed with the CLI example. It is therefore complicated for me to flash a new firmware since it requires additional hardware that I don't have. I based my application on the CLI example, and I am sending commands to the CLI to manage the network.
Do you think it is feasible to process the enrollment by sending commands to the CLI? Because I read in the ZCL specification that the Client of a IAS Zone cluster (my coordinator) needs to write its ieee address into the IAS_CIE_Adress attribute to process enrollment. And write attribute can be done with the CLI example right?

Or is it not possible to achieve this with the CLI example? Do I need to customize the CLI example, compile and flash the module to achieve this?

BR,
Damien

[Marte Myrvold]

Hi,

You would need to customize the example yourself to implement IAS Zone enrollment, and then compile and flash the application to your board. The CLI Agent example is just that, an example, and you should modify it for your use case, which in this case would be to include IAS Zone enrollment. You're not able to perform this enrollment simply by sending commands as the example is now.

We recommend using one of our development kits, like the nRF52840 DK, for development purposes, and not custom hardware. After testing that everything works as expected with the DK, you should move forward with custom hardware.

You could also take a look at this link where you can find documentation about the IAS Zone cluster in ZBOSS, which might be useful if you're going to implement things yourself. There's not much explanation there, but you can see what macros exist and there are a few examples.

Best regards,

Marte