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!

[Alex_T]

Found out it works better with the documentation of the matching SDK version ;-). Still a bit try & error but result is already good.

https://infocenter.nordicsemi.com/topic/sdk_tz_v4.1.0/using_zigbee__z_c_l.html#process_zcl_cmd_implementing

[Marte Myrvold]

Hi Alex,

Great to hear that the results are good. I don't know how far you've come with implementing this now, but I finally got a response from the Zigbee team:

Yes, this command is optional and may not be handled internally by the stack.

To handle this command, register endpoint handler for the endpoint with the light bulb, using ZB_AF_SET_ENDPOINT_HANDLER() and the proper handler logic needs to be implemented.

The handler itself can be implemented like below but it lacks the logic to handle Off with effect command:

/* Handler function for incoming ZCL frames. */
static zb_uint8_t light_bulb_ep_handler(zb_bufid_t bufid)
{
    zb_zcl_parsed_hdr_t *p_cmd_info = ZB_BUF_GET_PARAM(bufid, zb_zcl_parsed_hdr_t);
 
    /* Make sure that received frame was sent with proper profile and to proper cluster. */
    if (p_cmd_info->cluster_id != ZB_ZCL_CLUSTER_ID_ON_OFF ||
        p_cmd_info->profile_id != ZB_AF_HA_PROFILE_ID)
    {
        return ZB_FALSE;
    }
 
    /* Check if the received command is OFF WITH EFFECT command. */
    if (p_cmd_info->cmd_id == ZB_ZCL_CMD_ON_OFF_OFF_WITH_EFFECT_ID)
    {
        zb_zcl_on_off_off_with_effect_req_t off_with_effect_payload;
        zb_zcl_parse_status_t status;
 
        ZB_ZCL_ON_OFF_GET_OFF_WITH_EFFECT_REQ(&off_with_effect_payload, param, status);
        if (status == ZB_ZCL_PARSE_STATUS_SUCCESS)
        {
            /* HERE - Implement logic to handle the OFF WITH EFFECT command.
             * The "off_with_effect_payload" structure stores the command payload data.
             */
 
            /* Once the command is handled, return ZB_TRUE to inform stack that the frame has already been processed. */
            return ZB_TRUE;
        }
    }
 
    return ZB_FALSE;
}

Hope this helps!

Best regards,

Marte

[Alex_T]

Hi Marte,

Sorry for my late reply!

Thanks for the code - it was helpful to see how this implementation is intended. My proof of concept is working quite well already.

I am wondering about another thing now. I am receiving standard "get scene membership" commands. That command is mandatory. The example answers them with "default response" but I'd expect the answer to be a "scene membership response" command.

In my application I also see these commands arriving in "zb_zcl_device_cb" with endpoint 0 instead of the real endpoint number - but in my own packet handler they arrive with the correct endpoint set.

Can you help me figuring out why the default response is send and why no endpoint id is passed to the device callback?

Thanks in advance,

Alex

[Marte Myrvold]

Hi Alex,

Yes, from the Zigbee Cluster Library Specification, chapter 3.7.2.4.8, it's stated that the Get Scene Membership command shall generate an appropriate Get Scene Membership Response command from the device that received the first command, so you should get that instead of a default response. How was the command addressed? It shall only respond with the response if the command was addressed to a single device, or if an entry within the Scene Table corresponds to the Group ID.

I will ask our Zigbee team internally about this. However, because of holiday season it might take some time to get a response from them, so please be patient.

Best regards,

Marte

[Alex_T]

Hi Marte,

This is the request:

Frame 85967: 48 bytes on wire (384 bits), 48 bytes captured (384 bits) on interface wireshark_extcap2892, id 0
IEEE 802.15.4 Data, Dst: 0x0088, Src: 0x0001
    Frame Control Field: 0x8861, Frame Type: Data, Acknowledge Request, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit
    Sequence Number: 158
    Destination PAN: 0x1174
    Destination: 0x0088
    Source: 0x0001
    [Extended Source: ......]
    [Origin: 1]
ZigBee Network Layer Data, Dst: 0x0088, Src: 0x0001
    Frame Control Field: 0x0248, Frame Type: Data, Discover Route: Enable, Security Data
    Destination: 0x0088
    Source: 0x0001
    Radius: 30
    Sequence Number: 223
    [Extended Source: ......]
    [Origin: 1]
    ZigBee Security Header
ZigBee Application Support Layer Data, Dst Endpt: 10, Src Endpt: 64
    Frame Control Field: Data (0x00)
    Destination Endpoint: 10
    Cluster: Scenes (0x0005)
    Profile: Home Automation (0x0104)
    Source Endpoint: 64
    Counter: 202
ZigBee Cluster Library Frame
    Frame Control Field: Cluster-specific (0x01)
    Sequence Number: 224
    Command: Get Scene Membership (0x06)
    Payload
        Group ID: 0xf44c

This is the wrong default response from the example (or slightly modified but similar application):

Frame 85969: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface wireshark_extcap2892, id 0
IEEE 802.15.4 Data, Dst: 0x0001, Src: 0x0088
ZigBee Network Layer Data, Dst: 0x0001, Src: 0x0088
ZigBee Application Support Layer Data, Dst Endpt: 64, Src Endpt: 10
    Frame Control Field: Data (0x40)
    Destination Endpoint: 64
    Cluster: Scenes (0x0005)
    Profile: Home Automation (0x0104)
    Source Endpoint: 10
    Counter: 68
ZigBee Cluster Library Frame, Command: Default Response, Seq: 224
    Frame Control Field: Profile-wide (0x18)
    Sequence Number: 224
    Command: Default Response (0x0b)
    Response to Command: 0x06
    Status: Failure (0x01)

This is what I would expect - captured from a certified device:

Frame 382: 51 bytes on wire (408 bits), 51 bytes captured (408 bits) on interface wireshark_extcap1788, id 0
IEEE 802.15.4 Data, Dst: 0x0001, Src: 0x007a
ZigBee Network Layer Data, Dst: 0x0001, Src: 0x007a
ZigBee Application Support Layer Data, Dst Endpt: 64, Src Endpt: 11
    Frame Control Field: Data (0x00)
    Destination Endpoint: 64
    Cluster: Scenes (0x0005)
    Profile: Home Automation (0x0104)
    Source Endpoint: 11
    Counter: 207
ZigBee Cluster Library Frame
    Frame Control Field: Cluster-specific (0x19)
    Sequence Number: 160
    Command: Get Scene Membership Response (0x06)
    Payload
        Scenes Status: Success (0x00)
        Scene Capacity: 50
        Group ID: 0xf44c
        Scene Count: 0

Looking forward to your response and have a nice Holiday!

Best regards,

Alex