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

[Kenneth]

Hi,

nRF5 SDK for Thread and Zigbee v3.2.0 is quite old one. Can you verify it with latest nRF5 SDK for Thread and Zigbee v4.2?

Kenneth

[abe]

Hi Kenneth
this for me is very hard, the new 4.2 SDK (for what I know) seems not compatible with old one!
And the coordinator FW now in production is a result of over two years of developing ...
Could you help on SDK I have used ?

[Marte Myrvold]

Hi Abele,

Thank you for providing the additional information!

abe said:

then it is not possible to update only Zboss Stack? I have already done it from 3.0.0 to 3.1,0

It is possible to do so, but the SDK might not be compatible with a different version of ZBOSS than it was made for. Additionally, platform certification points out one particular version of ZBOSS, so you will not be able to use platform certification if you use a different version of the ZBOSS stack than the SDK was certified with.

abe said:

Zboss log need to be enabled (how we can do it?)

This is described in the documentation here: Debugging, but what you need to do is to:

• Replace the libzboss libraries in your project with the files located in <InstallFolder>/external/zboss/lib/debug
• Configure the following in sdk_config.h:

Configuration option	Value for nRF52840	Value for nRF52833*
NRF_LOG_DEFAULT_LEVEL	4	4
NRF_LOG_BUFSIZE	65536	32768
NRF_LOG_MSGPOOL_ELEMENT_COUNT	32	32
NRF_LOG_MSGPOOL_ELEMENT_SIZE	40	40
NRF_LOG_BACKEND_RTT_TX_RETRY_CNT	100	100
SEGGER_RTT_CONFIG_BUFFER_SIZE_UP	32768	512

• Then change these in main():
  

  ZB_SET_TRACE_LEVEL(ZIGBEE_TRACE_LEVEL);
  ZB_SET_TRACE_MASK(ZIGBEE_TRACE_MASK);
  to
  ZB_SET_TRACE_LEVEL(4);
  ZB_SET_TRACE_MASK(TRACE_SUBSYSTEM_ZCL | TRACE_SUBSYSTEM_ZDO | TRACE_SUBSYSTEM_NWK | TRACE_SUBSYSTEM_SECUR);

The UART log from nRF Should output some character strings. Please save this log and upload it here so I can forward it to the developers for decoding.

Best regards,

Marte

[abe]

Thanks Marte
I next days (or next week) I will arrange the needed modify to have Zboss Log Out and I will try to reproduce the issue (but it is not easy, the issue is randomly)
As I have news I will send you the results
Abele

[Marte Myrvold]

Hi Abele,

I have an update from the developers as well:

1. Changing only ZBOSS libs should be only with the rest of the SDK - there were some major changes between SDK v3.2 and v4.X.
   I pretty sure that even attempt to change ZBOSS libs will require factory reset of the device.
2. ZBOSS logs could also be configured to be printed over RTT so maybe the additional connector for serial is not required. 
3. Customer claims that the Link Status issue could be reproduced with the original CLI example.
   Could you ask them to how can it be reproduced? I have tried a bit but wasn't able to reproduce it.

Best regards,

Marte

[abe]

Hello Marte,

Marte Myrvold said:

Changing only ZBOSS libs should be only with the rest of the SDK - there were some major changes between SDK v3.2 and v4.X.

Yes, of course, I see there are some function that must be adapted/changed, but this could be resolved, I think

Marte Myrvold said:

I pretty sure that even attempt to change ZBOSS libs will require factory reset of the device.

This is not a issue, all custom data/configurations stored on FDS will be restored via BLE

For the issue, I haven't said that it can be reproduced with CLI sample, I said that ii needs to be tested.
I said that Link Status timing are same of CLI example

To try to reproduce the issue, you must have a Battery powered end node (button or door sensor) and a Bulb or other mains powered end node that act also as Router
If you see my WireShark log, you can see that the all end nodes regullary report some attribute, in addition, the Door Sensor is configured also to send IAS zone status info to Coordinator and it send these information via router.
If you power down the router, and for example open / close the door sensor, it try to send via router, but it is not reachable; then it ask to find a route, the coordinator rejoins it and accept data, but after some seconds sends "leave" to just rejoined end node.
Unfortunatly this happens "randomly" not every time you make this sequence

Abele

PS We are using Heiman end nodes (bulbs, door sensor , ...)

[abe]

Hi Marte
Have you still tried to reproduce the issue? (using my suggests...)
Have further news?
On my side, I hope to try with Zboss log enabled during this week ...

Abele