This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Zigbee Light Demo stops responding

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?

  • Did you add the keys described in the sniffer documentation to Wireshark?

    I need to forward the logs to the developers, I'm not able to decode it myself. I realized it would give the developers more details if I also included a sniffer trace with the logs.

  • I had to download the Wireshark source and recompile it to get it to run on the Mac with the nRf52840 dongle, sorry for the delay.

    I don't see where to add an attachment so the sniffer file is on my WEB site at www.cedartechnology.com/.../nRF52840DK.pcapng

    The nRF52840DK is running the sample light bulb application. It was started just after the trace was begun. The device has address 0x10ad. The hub (address 0x0000) is a SmartThings V2 hub and has the nRF52840 listed as a light bulb. I am able to turn the light on and off via the SmartThings application on an iPhone.

    Looking at the trace the last Link Status broadcast from the nRF52840 is at entry number 29229 followed by a couple of Route Reply messages which I assume are in response to the broadcast Route Request messages from the devices that are being replied to.

    After this the nRF52840DK became unresponsive as can be seen starting at row 31914 where the SmartThings hub sent the Off command to turn off the light. This was not acknowledged. The hub repeated the command several times but no acknowledgements were sent by the nRF52840.

    I do not see problems when the nRF52840 is in its own little network with the sample coordinator and switch only when in the full environment with the Samsung SmartThings controlled network.

    Thanks very much for looking into this. If I can supply any further information please let me know. I can be reach by phone at +1-352-281-6286

  • Unfortunately, I'm not able to read the sniffer trace as it is encrypted. Please make sure you run the sniffer before commissioning the device into the network, for the sniffer to obtain the keys. This could require you to erase the devices before starting the commissioning procedure on the devices again.

  • Sorry about that. I did not realise the trace would not have been decrypted already. To save time, here are the keys my system is using to read this data...

    Transport Key : 5A 69 67 42 65 65 41 6C 6C 69 61 6E 63 65 30 39

    Network Key : 50dcaba83f417592833406696ed2bea4

    I hope that helps.

  • Did the keys work for you? I have been trying to do more checking myself. When I run the code on the nRF52840DK I can see that most of the time it stops in the zb_nrf52840_abort function sitting in an endless loop flushing the zb_osif_serial buffer, which is of course empty.

    The stack trace shows only back to the zb_free_buf() function (1 level up) so I cannot tell where it came to from that. Is there any more I can do to enable me to help find out where it is going wrong?

Related