I noticed that the nRF Connect SDK has kept up with ZBOSS updates throughout the year. Is there a plan or recent releases with regard to the "nRF5 SDK for Thread and Zigbee" so that is also is kept up with the ZBOSS updates?
We have production products on the "nRF5 SDK for Thread and Zigbee" and it looks as if some of the items we are struggling to resolve might have been already bug fixed in the ZBOSS associated with the nRF Connect SDK.
Hi,
What version of the nRF5 SDK for Thread and Zigbee are you using for the existing devices?
TKR said:1 - The coordinator will accept EP joins regardless of commissioning status. It looks as if this might have been addressed in the ZOI-522 in the NCS. We need the ability to ask our EPs to leave the network in order to have it join another coordinator as needed during deployment. Note that we can ask the EPs to leave and they do so, but immediately join back into the coordinator as an authenticated device outside of the commissioning being enabled.
nRF5 SDK for Thread and Zigbee v4.0.0 already supports the 'zdo mgmt_leave' command and response, so this sounds strange. Could you send a sniffer trace when this happens? You should double check that you are not starting network steering in the code on the coordinator side after sending the leave message. In the sniffer trace you should look for the field "Association Permit" in the coordinator, if it's set to True the end device will join again after leaving, if it is not set to 'false' look through your code and see if you are starting network steering somewhere in your code.
TKR said:2 - big problems with more than a few reporting items. This looks to have been addressed in ZOI-111 in the NCS. It seems like some significant stability was added between 3.2 and 3.6 of the ZBOSS stack in reviewing the release notes. This is not a show stopper as we have reduced the number where there are not any problems at the moment.
The ZBOSS stack had a limitation on the number of active reporting configurations to 10 entries. This is only a problem when you want to subscribe to attributes on a multi-endpoint device. There is a workaround for nRF5 SDK. You can change the size of the reporting table inside the endpoint declaration. Take a look at the answer in this devzone thread. The bugfix ZOI-111 in the release notes for ZBOSS v3.6 relates to this issue who was first in this ticket.
TKR said:3 - We need the ability to stop the commissioning process as soon as we know our EPs have joined the network (reducing the minimum 180 second timeframe). In testing this multiple ways to restart commissioning with a smaller timeout, it still continues for the 180 seconds minimum.
The 180 seconds permit duration is precompiled in the ZBOSS stack, and it is not possible to change this value without recompiling the entire stack, which you can only do if you are a member of the ZBOSS Open Initiative. The 180 seconds are used as default in the network steering procedure (started by calling bdb_start_top_level_commissioning(ZB_BDB_NETWORK_STEERING)) as it's specified in the Zigbee specification. However, you could also use zb_zdo_mgmt_permit_joining_req() directly to send a mgmt permit joining request directly to a remote device, see this post for more information.
TKR said:We may have to move our development now over to the NCS for the coordinator, but now this means we are active in two SDKs which is not the best plan moving forward.
We recommend developing new devices on NCS, but as I wrote in my previous answer the nRF5 SDK will still be supported for a long time (including Devzone support) so developing in nRF5 SDK is still a viable solution if you for example, don't need an RTOS or don't require newer features on Zigbee 3.0 that may come. There shouldn't be any problems using different SDK for different devices for a while either. Having a zigbee coordinator based on the nRF Connect SDK and your end devices based on nRF5 SDK should be fine.
Best regards,
Marjeris
