I'm looking into the use of the nRF52840 as a light switch/dimmer for a Philips Hue system, but have been running into issues with getting connected to the Hue network. I have a single nRF52840-DK board and a Ti CC2531 dongle which I've been using to sniff the Zigbee exchanges through Wireshark.
I've read through previous posts to the Dev zone (namely "Philips Hue with Zigbee 3.0") and have been attempting to build on top of the information I've found here and elsewhere. For now, I've been testing with the light_bulb example until I have the correct network-connect procedure.
To the best of my knowledge, I need one or more different secret keys. I have both the ZLL master-key and the ZLL Commissioning Trust Centre link key, which I believe should be enough to get me connected.
I've captured the connection procedure for a known-compatible bulb (IKEA Trådfri), and the ZLL-TC link key does indeed appear to be capable of decrypting the exchange between the Hue Bridge and the bulb. This has allowed me to obtain the network key specific to my network, as well as to see the correct connection behaviour of the devices. I've attached a Wireshark dump of the "correct" connection procedure here. The ZLL-TC key is required to decrypt some of those frames, so below is a screenshot of the frames.
On the nRF side of things, I've been able to get the Hue bridge and the DK board to have some form of initial communication, however a proper network connection is never made. Relevant Wireshark dump here, and screenshot of the decrypted frames below.
By comparing the two dumps, it seems as though both the bulb and the nRF board initially follow the same procedure. First, the Hue bridge permits joining (triggered by searching for lights in the Hue app). After this, the "light" device sends an association request , which the bridge responds to with a new assigned short address for the device. Following this, the bridge sends the Network Key (encrypted by the ZLL-TC link key) as a Transport Key command.
At this point, the behaviour of the two devices diverges. The IKEA bulb begins to identify itself by the new short address, and broadcasts some information about itself to the wider network, and answers some requests directed at its short address. The nRF board, however, seems to get caught up with the Transport key, not broadcasting any information about itself nor does it identify itself by the short address (can also see that it ignores messages directed at its short address). After a few seconds it repeats this connection behaviour again, over and over until the bridge stops searching for new bulbs.
This is where I've been unable to proceed. I'm not entirely sure why the nRF board stops responding at this point. The only debug message from the board is "Failed to join network. Status: -1", which is delivered from the ZB_ZDO_SIGNAL_DEFAULT_START and ZB_BDB_SIGNAL_DEVICE_REBOOT signal handler. Beyond that, nothing (besides the relatively unhelpful zboss binary dump).
One possibility that I've considered is that the network key is not being decrypted by the nRF once the "Transport Key" command is received. I know that the encryption key required here is the ZLL-TC link key, but it's a bit unclear to me where the key should be entered in the code. So far, I've dropped it into multiple places in zb_config.h and zb_config_common.h, but the behaviour is always the same. I've also tried changing ZB_ZGP_DEFAULT_SECURITY_LEVEL to ZB_ZGP_SEC_LEVEL_FULL_WITH_ENC, with the same results.
Any help here would be greatly appreciated. I understand that ZLL/Philips Hue are generally considered proprietary and so direct support here may be limited, but if I could even get a few tips on how to further debug this problem (i.e. more debug info from zboss) it would be very helpful.
Thanks!
