• State Not Answered
  • Replies 37 replies
  • Subscribers 76 subscribers
  • Views 6156 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 291888
Options

Unwanted "Leave" command from coordinator

abe

Hello, I developed for my customer, a ZigBee coordinator in last 2019, using nRF5 SDK for Thread and Zigbee v3.2.0.
Now my customer has this issue:
- End Node connected via router, if router deads, the coordinator rejoin it but after few time send "leave" command to end node
Here attached WireShark log file of ZigBee radio communication
Some details:
- end node has NW address E3DF
- router has NW address D01B
- at line 14631 and following, the router deads
- at line 14680 starting end node routing search
- at line 14747 and followings rejon procedure
- at line 14850 Coordinator sends LEAVE command to end node E3DF

What is happened? Why Coordinator sends "Leave" command?
How can we avoid this unwanted behaviour?

Many thanks for your help!

Abele

Parents Reply
  • 0 in reply to Marte Myrvold

    I'm very disappointed for this answer, when I developed the application the SDK 3.x was the new available, and now after few year Nordic don't support it anymore.
    I hoped a best help to issues, expecially when the alternative solution porposed has high impact on already developed project: migrating to the latest SDK practically forces to redo the project, with all difficulty related.
    In addition, the new SDK don't support IAR EWARM (the 3.2 yes, I have developed my project with IAR EWARM)
    Last, peraphs you can ask to development team if there is a possibility to "disable" the leave command on ZigBee SDK 3.2 ?
    This could be a "patch" that has minor impact the project.
    Please, let me know as soon


    Best regards,
    Abele

Children
  • 0 in reply to abe

    Hi Abele,

    As stated in my previous reply, you will not be able to certify Zigbee products that are using R21 of the Zigbee specification anymore. This is not a limitation on our side, but by CSA. Even if the leave problem is fixed you will not be able to certify a new product developed in v3.2 of the SDK.

    Support for R22 of the specification was added in v4.0.0 and has been supported in our SDKs for more than 2,5 years already. I would really recommend migrating to v4.2 if possible, as this version supports ZCL8 as well and there was a lot of fixes between this version and the previous one, but if that is absolutely not possible then you should at least migrate to v4.1. There are still a lot of changes between v3.2 and v4.1, but it will not be as many as with v4.2, and there is still support for IAR. As mentioned by Kenneth previously we have a migration guide available in our documentation: https://infocenter.nordicsemi.com/topic/sdk_tz_v4.1.0/zigbee_r22_migration.html.

    If you experience any issues with v4.1 I will try to help, but if these are bugs that have been fixed in later versions of the stack I unfortunately cannot help. 

    Best regards,

    Marte

  • 0 in reply to Marte Myrvold

    Hi Marte,
    I will inform my customer for your answers.
    Nordic help in migration to 4.1 would be very appreciated, I'll keep you updated in next weeks when I can start this work

    Regards

    Abele

    PS the link you paste seems not working ...

  • 0 in reply to abe

    Hi Abele,

    Thanks for letting me know. For some reason DevZone changed the link to try to link to something on DevZone instead. I have updated the link, but it is also here: https://infocenter.nordicsemi.com/topic/sdk_tz_v4.1.0/zigbee_r22_migration.html.

    Best regards,

    Marte

  • 0 in reply to Marte Myrvold

    Hi Marte,
    I'm evaluating to use Segger Embedded Studio to migrate my project to SDK 4.2.0.
    It's very probably that I will need help for several things, here a starting list:
    - adding BLE gatt/services and DFU bootloader integration
    - Handler when NEW devices will accepted on network (we need to read from device some info and store on BLE GATT)
    - Zboss method to handle end-node steering and net formation (user must manually activate devices network joining process)
    - Computing of needed NVRAM for 100 Zigbee nodes, and how to handle it
    - using and handle of FDS storage for store some data used by custom application (without issues with Zboss NVRAM)
    This is main list, but I think that we could need other help during the development.
    I will inform you that our product is a Zigbee Coordinator, and the previous development (from SDK3.2) was made integrating DFU bootloader and CLI agent configured as coordinator into Multiprotocol Ble-Zigbee template
    Let me know for these helps.
    Many thanks in advance.
    Abele

  • 0 in reply to abe

    Hi Abele,

    I am sorry for the delay.

    abe said:
    - adding BLE gatt/services and DFU bootloader integration

    We do have some nRF5 SDK Bluetooth guides on Devzone here:  Bluetooth low energy , such as this guide for services:  Bluetooth low energy Services, a beginner's tutorial . As for DFU there is a guide for getting started with the secure DFU bootloader here:  Getting started with Nordic's Secure DFU bootloader, a step by step guide . You should also be able to find information in our documentation on infocenter. If you have more problems with this part, please create a new ticket.

    abe said:
    Handler when NEW devices will accepted on network (we need to read from device some info and store on BLE GATT)

    You can use the ZB_ZDO_SIGNAL_DEVICE_ANNCE or ZB_ZDO_SIGNAL_DEVICE_UPDATE signals in zboss_signal_handler() to handle when a device is updated/joins the network. See components/zigbee/common/zigbee_helpers.c for how these signals are used there.

    abe said:
    - Zboss method to handle end-node steering and net formation (user must manually activate devices network joining process)

    Do you mean that the user must be able to open the network on the coordinator? Because if so, then you can look at the light coordinator example. There the network is reopened if button 1 is pressed:

    case BSP_EVENT_KEY_0:
    UNUSED_RETURN_VALUE(ZB_SCHEDULE_APP_ALARM_CANCEL(steering_finished, ZB_ALARM_ANY_PARAM));

    comm_status = bdb_start_top_level_commissioning(ZB_BDB_NETWORK_STEERING);

    abe said:
    Computing of needed NVRAM for 100 Zigbee nodes, and how to handle it

    We have some information about NVRAM in our documentation here: https://infocenter.nordicsemi.com/topic/sdk_tz_v4.2.0/group__zboss__nvram.html

    I hope this answers some of the questions. If you have specific questions about any of this, please create a new ticket for the questions, as they are no longer directly related to the original issue in this ticket. Thank you!

    Best regards,

    MArte

Related
Terms of service