NRF5340 DK as end device with 3rd party coordinator

[nilesb]

I'm interested in configuring a NR5340DK as an end device on a Zigbee network where the coordinator is a 3rd party device that uses legacy Zigbee. I'm fairly new to Zigbee, and am very new to Zigbee 3.0 features. Currently I have configured the R22 light_switch sample such that it sends a association request to the coordinator, and the coordinator responds with an association response success. Unfortunately, this is as far as I've gotten. After the association response, the NRF5340 never sends a device announcement.

I was able to use a sniffer to inspect the association process between 2 NRF5340DKs using the R22 samples where one had the light_switch example running as the end device and the other had the shell example running as the zigbee coordinator. It looks like after the association response from the coordinator, the coordinator then sends a Transport Key to the end device. Then, the End Device sends the device announcement. 

My legacy zigbee coordinator is not configured to send the transport key, and as such I would I like to configure the NRF5340 to not expect the transport key and to send the device announcement following the association response success. Is there a way to configure nrf5340 to do this?

I am aware of the zb_bdb_set_legacy_device_support() option, but my understanding this is for configuring a coordinator and not an end device. Is there a similar way to configure an end device to be compatible with legacy zigbee?

Thanks!

[Edvin]

Hello,

I am aware of the zb_bdb_set_legacy_device_support() option, but my understanding this is for configuring a coordinator and not an end device.

Yes, that is indeed for the coordinator to allow legacy devices to join the network. 

What exactly is your network coordinator? Ususally it is the coordinator that handles setting up everything in the network. Typically, figuring out what device that just connected, and then bind it to other endpoints of the network, based on the user's wishes. 

I recommend that you play around a bit with the Zigbee Shell sample:

https://docs.nordicsemi.com/bundle/addon-zigbee-r23-latest/page/samples/shell/README.html

The sample description is not too detailed, but if you look at the description of the old Multi sensor example found in nRF5 SDK for Thread and Zigbee:

https://docs.nordicsemi.com/bundle/nrf5_sdk_thread_zigbee/page/zigbee_multi_sensor_example.html

Then you can see how this onboarding process for a new node can be done. You can use the Zigbee shell sample as an example. Basically, the zigbee nodes are quite passive in the process, and most things are handled by the coordinator of the network. It tells the Zigbee node where to report and what to listen to within the network.

Best regards,

Edvin

[nilesb]

Thanks for the response. I have been playing around with the Zigbee Shell sample using 2 nRF5340DKs. In doing this I saw that the Zigbee Coordinator sends a Transport Key message immediately after sending the Association Response. It is only after this Transport Key message that the Zigebee End Device sends the Device Announcement message. Is there a way I can configure the nRF5340DK as a Zigebee End Device to send the Device announcement message without ever receiving the Transport Key message?

[Edvin]

Hello,

I talked to someone in our Zigbee team, and it turns out that there was a security patch, not allowing end devices to send device announcement before the transport key was sent. This is for security reasons. The only way it is possible is to use the ZBOSS stack (zigbee stack) from NCS v2.5.3, as the patch was applied in v2.6.0. 

What kind of Coordinator are you using?

Best regards,

Edvin

[nilesb]

I'm using a custom Zigbee coordinator that runs Freescale BeeStack Zigbee. I'm experimenting with enabling security on my Zigbee Coordinator to be compatible with the ZBOSS stack, but I'm curious if there is a way to disable security completely on the ZBOSS stack for testing?

I found an interesting comment in zb_config_common.h:

/*! \addtogroup ZB_CONFIG */

/*! @{ */

/**@cond internals_doc*/

/* To compile MAC only build;

   TODO: Fix it. there should probably be another way to build without security

*/

It's not clear to me what this is talking about, I think it maybe has something to do with the MAC Split, which I am also not quite sure what that is. However, since it mentions building without security, I am curious if the you could share any more info on the meaning of this?

I also noticed this define and comment in zb_config_common.h:

/* parameters for security level 5 - the only security level supported */

/**

 SECUR: security level. Now fixed to be 5

*/

#define ZB_SECURITY_LEVEL 5U

Is this comment accurate in that security cannot be disabled? I understand that it is not recommended to disable security, but I am curious if it is even possible to do it in ZBOSS temporarily for testing and evaluation?

[Edvin]

nilesb said:

Is this comment accurate in that security cannot be disabled? I understand that it is not recommended to disable security, but I am curious if it is even possible to do it in ZBOSS temporarily for testing and evaluation?

Unfortunately, it is not possible to disable this security in NCS. The recommended action is to enable security in your coordinator. 

Alternatively, you need to roll back to NCS v2.5.3, but that is not really recommended. 

Best regards,

Edvin