nRF52840 custom light bulb compatible with Hue and Alexa

[Alex_T]

Hello,

I am new to Nordic and quite new to ZigBee. Just had a short evaluation with Silabs so far.

My goal is developing a custom lamp for serial production that needs to be compatible with Hue Bridge & App, as well with Alexa.

I use PCA10056 and started with an example from the SDK but I did not come very far.

On a PCA10056 Board I run zigbee_light_bulb_pca10056 with SES but the lamp will not show up in the hue app using a Hue Bridge 2.1 when searching for lights.

Using PCA10059 Dongle as a sniffer I can see that there is a "transport key" package but the debug log keeps outputting:

<info> app: Network left (leave type: 0)
<info> app: Network steering was not successful (status: -1)

I read a lot here about hue keys, touch link and comissioning but still did not get it running and feel quite lost.

Nordic does not seem to support touch link and uses normal commisioning instead - what will the difference be like for the user?

How do I get this example working with Hue?

And in general - where to start to make this development process less scientific/tryanderror and more straingtforward instead? Where to get an overview about what you need from the beginning?

Thanks in advance!

[Marte Myrvold]

Hi,

Sorry for the late reply. 

How do I get this example working with Hue?

You're correct that Nordic does not support touchlink. Instead, I would recommend you try using the function zb_zdo_set_tc_standard_distributed_key() and call it before zb_start(), as is done in this reply. If you look at infocenter, you will find that there's no documentation for ZDO distributed security in the latest versions of the SDK. That's just an error in the documentation. The functions exist in the SDK, it's just been removed from the documentation by a mistake, so you should be able to use it as in the case I linked.

what will the difference be like for the user?

Normal commissioning uses network steering, formation, finding and binding. The commissioning mode is initiated by some action performed by the user, for instance a button press. The coordinator will then be in commissioning mode for 3 minutes, which is when routers and end-devices will be able to be commissioned to the network. Nodes that want to join a network scans for open networks and will attempt to join. If they are allowed to join, the node must be authenticated and receive the network key, which is often the Trust Center link key.

Touchlink minimises how much the user has to do. When using touchlink, you don't need a coordinator for forming and joining networks. Instead, the nodes run a special commissioning application which is based on the ZLL Commissioning cluster. You have one initiator, which initiates the formation/joining of the network. If the initiator node is physically close to the node that should be included in the network, the procedure can be done by simply starting the commissioning, which can be done by pressing a button. Touchlink commissioning is performed in three steps:

1. The initiator scans for ZLL nodes and gets a list of possible nodes. If there's more than one, the initiator has to decide which one to commission.
2. The initiator sends a request to the node to get its network information, which it then receives from the node.
3. The initiator requests the node to join the network, or to form a new one if no network already exists.

where to start to make this development process less scientific/tryanderror and more straingtforward instead? Where to get an overview about what you need from the beginning?

I would recommend reading the Zigbee 3.0 specification, as well as reading about the different cluster libraries relevant to your project, in order to better understand how everything works. In addition to that, you can take a look at our documentation for the SDK. There's also several examples there that you can look at in order to see how things can be implemented and used.

If you're still having problems, could you please attach a sniffer log?

Hope this helps you get going and that it answers your questions!

Best regards,

Marte

[Alex_T]

Hi,

Thanks for your reply.

I tried zb_zdo_set_tc_standard_distributed_key() before but I did not implement the other changes mentioned in that post.
This time I changed all keys and also the security behaviour and it works with Hue!

#define ZB_ZGP_DEFAULT_LINK_KEY "\x81< rest of key >
#define ZB_ZGP_DEFAULT_SHARED_SECURITY_KEY_TYPE ZB_ZGP_SEC_KEY_TYPE_NWK
#define ZB_ZGP_DEFAULT_SECURITY_LEVEL ZB_ZGP_SEC_LEVEL_FULL_WITH_ENC
#define ZB_STANDARD_TC_KEY { 0x81, 0x42, < rest of key > };
#define ZB_DISTRIBUTED_GLOBAL_KEY { 0x81, 0x42, , < rest of key > };
#define ZB_TOUCHLINK_PRECONFIGURED_KEY { 0x81, 0x42, < rest of key > };

calling this:
    zb_zdo_set_tc_standard_distributed_key(ZB_ZGP_DEFAULT_LINK_KEY);

before the line with zboss_start_no_autostart in main.c

Also changed #define IEEE_CHANNEL_MASK to 0x07fff800U and removed APP_BULB_USE_WS2812_LED_CHAIN.

Thanks for explaining - Touchlink seems to be a dispensable feature for me now.

Next to the ZigBee spec I'm also now reading a book on ZigBee as I really need to get deeper into this whole topic and things are already getting clearer.


While Debugging this example I'm facing a new problem now:
The debugger connection gets lost while doing ZigBee related things and eval board seems to reconnect itself.
In the beginning this seemed to be directly related to ZigBee Events (after connection, when trying to change level).
Now I cannot regularly reproduce it so it might also be related to sth else. During debug without touching the board the SES displays "Target connection has been lost" and the board reconnects (the virtual storage device pops up again and terminal on com-port is lost). Other times SES just hung up with no response until I disconnected the board manually.
I thought it might be a power supply related thing but the board is set to SW9 VDD which should work fine?
The attached screenshot shows where this happend the first and second time from the view of the serial ouput.

Lost connection shortly after being discovered by Hue:

Restarted the debugger and reconnected automatically to Hue - trying to enable/disable light and got lost again:

This is all SES is saying:

Thanks again for your support!
Alex

[Marte Myrvold]

Hi Alex,

I haven't seen a problem where Zigbee events cause lost connection before, so I' might need some time to figure out what the issue can be.

Since SES is displaying that the target connection has been lost, the problem seems to be with the JLink connection. Is this only happening with one board, or do you see the same thing with different boards? Have you tried using different cables to connect the board? The problem can simply be faulty hardware.

Best regards,

Marte

[Alex_T]

Hi Marte,

Thanks for your advice. I changed the usb cable to a shorter and higher quality one and the issues seem to be gone now! I did not spend too much time using it but it looks stable for now.

Best regards,

Alex

[Marte Myrvold]

Hi Alex,

Great to hear that it's working as expected now!

Please don't hesitate to ask if you have any other problems.

Best regards,

Marte

[Alex_T]

Hi,

I am proceeding with getting into zigbee but still having some basic problems.

I changed the switch example and send off-with-effect commands to the bulb example and expect the ZB_ZCL_ON_OFF_WITH_EFFECT_VALUE_CB_ID to be received - but nothing.

Using this to send on Button Press instead of normal off:

        ZB_ZCL_ON_OFF_SEND_OFF_WITH_EFFECT_REQ(bufid,
                       m_device_ctx.bulb_params.short_addr,
                       ZB_APS_ADDR_MODE_16_ENDP_PRESENT,
                       m_device_ctx.bulb_params.endpoint,
                       LIGHT_SWITCH_ENDPOINT,
                       ZB_AF_HA_PROFILE_ID,
                       ZB_ZCL_DISABLE_DEFAULT_RESPONSE,
                       ZB_ZCL_ON_OFF_EFFECT_ID_DELAYED_ALL_OFF,
                        ZB_ZCL_ON_OFF_EFFECT_VARIANT_FADE,
                       NULL);

Sniffed packet looks fine and it gets ACK'ed from the dest endpoint.

Is there anything I need to do to "register" this off-with-effect command? I can't find much command-specific in the documentation. As the on-off cluster is included I'd expect the command to be passed to the cb function...?

Thanks in advance!

Alex

[Marte Myrvold]

Hi Alex,

I'm sorry for the late reply. I've started looking into your issue, but I don't know what the problem might be yet. I tried to implement this myself, but I experienced the same as you, that the packet is sent and I get an ACK, but it never enters the callback function. However, I noticed that I got a ZCL Default Response packet after the 'off with effect' command, with the status 'Unsupported Cluster Command'. It's possible that this command isn't supported in the SDK as it's optional to implement it, as can be seen in the ZCL specification.

I have asked the Zigbee team internally and will come backto you when I get a response.

Best regards,

Marte

[Alex_T]

Hi Marte,

From what I found out so far it seems that only mandatory commands are fully processed by the library.

As "Off with effect" is optional it is obviously not handled by the library - but already prepared for it. I would have to override the standard command handler, parse that command myself and e.g. hand it to my device callback.

Maybe you can verify this with your Zigbee team so I am not making things harder than necessary.

Thanks & best regards,

Alex

[Marte Myrvold]

Hi Alex,

That's what I suspect as well, but I have asked the Zigbee team and will update you when I know more.

Best regards,

Marte