Zigbee Light Demo stops responding

[IanAber]

I programmed a NRF52840 Dongle with the example light switch code having changed the channel to 14 which is what my coordinator is on.

I then programmed a NRF52840DK with the example switch code and adjusted the search to look specifically for the dongle with the endpoint at 10. All the other compatible devices in my Zigbee network have endpoints set to 1.

I programmed my Smartthings hub to recognise the Nordic dongle as a simple light bulb.

I put the hub in discover mode and fire up the dongle and the DK which both connect.

The Smartthings hub recognises the dongle as a light and I can turn it on and off from the Smartthings app on my phone.

The NRF52840DK switch also finds the dongle and I can control the light on the dongle using the two buttons on the DK board. The Smartthings hub DOES NOT see the updates to the dongle made from the DK switch unless I manually refresh it, but that is another issue.

Everything is fine for a random amount of time varying between a few minutes and several hours up to just over a day on one occasion. Then the light (dongle) simply stops responding. It no longer responds to the Smartthings hub nor to the DK board switch. If I restart the switch it fails to find the light. Only when I restart the light does it work again.

Does anyone have any idea why this should be happening? Can anyone suggest how I can debug this situation?

[Jørgen Holmefjord]

Hi,

Have you tried running the light bulb application on the DK, and do you experience this issue on this as well? If you see the issue, you should enter debug mode and check if you can see where the application is stuck. You can also connect the debug out pins of the DK to SWD pinson the dongle, to debug the application running on this as well.

Best regards,
Jørgen

[Jørgen Holmefjord]

Can you please share the project you used when seeing this issue? That would help us with reproducing and debugging it.

[Jørgen Holmefjord]

Our developers have analyzed the logs you provided, and confirm that the Zigbee stack is asserting. They know where the assert was called, but still don't know why it asserts. They have tried to reproduce the issue without success, and will now acquire SmartThings hub V2 to test with.

In the meantime, it would be of great help if you could provide information on the following points:

• Please provide as much details about the hub as you can collect (the hub name, version, revision, if possible to get also it's firmware version).
• Please provide as much information as possible about other devices in your zigbee network (do you have other routers or end devices, except light bulb demo and light switch demo?).
• Can you perform the test again and gather logs (this binary dump with <info> zboss: is perfect) AND wireshark logs from the same test run? Having both will help us correlate logs with network traffic.

[IanAber]

I have two SmartThings hubs in my environment in separate buildings. I will try the Nordic 52840DK in the second environment to see if it is truly the hub that is causing this or if it is some other device in the network. I will also try and grab a WireShark trace. It would be great if we could get some sort of time stamp on the debug log trace so we might be a ble to match it to the WireShark trace. Do you know if this is possible in Segger? My hubs are both Samsung SmartThings V2 hubs. I can provide access to my SmartThings account so you can see exactly what is in the network. I will need an email address to set up an account.

[IanAber]

I moved the nRF52840DK to my other environment which has an identical hub and it has been working for 24 hours without issue. This leads me to suspect some other device in the network is upsetting the ZBoss stack. I will move it back and run some tests by removing other Zigbee devices to try and nail down what is causing the failure. I will report back as I make progress. Thanks again for your help.

[IanAber]

I believe I have isolated the device that is causing the nRF52840 to fall over. It is an older Zigbee power socket from SmartThings. In the WireShark trace it is at source address of 0xa1d5. With that device out of th enetwork the nRF52840 worked for 24 hours but once it was reintroduced tot he network the nRF52840 fell over within a few minutes.

[Jørgen Holmefjord]

Is it possible to obtain this "older Zigbee power socket from SmartThings" in order to reproduce the issue? Do you have a model/version number?

Could you provide zigbee stack trace and wireshark log when this device connects to the network?

[IanAber]

Sorry for the delay in y reply but O have been travelling for the past couple of weeks.

I suspect that this socket is not available any more as it is quite old and I know they no longer market this model. I imagine the problem is caused by something this device is doing which may not be conforming to the Zigbee specification. whilst the Nordic nRF52840 should indeed survive this it is difficult to justify the effort required to resolve the issue if it is truly unique to my situation. I have removed the device from my network and have not encountered any further problems as yet.

If you would like to pursue the problem further I would be happy to send you the offending device for your developers to test with. Just let me know who and where to send it to and I will ship it to you for testing. I really do appreciate your help and the responsiveness of your support which confirms that the nRF52840 was the correct choice for my development.

[Jørgen Holmefjord]

Our developers will be happy to receive the device for debugging. Please send me a private message and I will provide shipping details.