ZigBee dimmable light level control attribute reporting

RE: ZigBee dimmable light level control attribute reporting

Marte Myrvold — Thu, 26 Oct 2023 13:05:39 GMT

Hi Jostar,

I was able to reproduce the same issue on my side. However, my suspicion is that the coordinator does not support it. Are you able to test with a different coordinator or device?

Best regards,
Marte

RE: ZigBee dimmable light level control attribute reporting

jostar — Tue, 24 Oct 2023 01:29:39 GMT

Hi, Marte
I am sorry about the wrong key, here is the sniffer log and the key. By the way. It response with "unsupported cluster " now.
key:24c986effa62ab3cfc3ea2b26eaad321

devzone.nordicsemi.com/.../4812.10_2D00_24.pcapng

Best regards,

Jostar

RE: ZigBee dimmable light level control attribute reporting

Marte Myrvold — Mon, 23 Oct 2023 11:15:02 GMT

Hi,

I am not able to decrypt the packets using the key you shared (3d02b59e8ff81858d569c6d6c5c6aca8).

Best regards,
Marte

RE: ZigBee dimmable light level control attribute reporting

jostar — Mon, 23 Oct 2023 10:10:37 GMT

I have been busy for other project in recent days, so I did not test the configure reporting request to a Nordic device as you advised that period. I am focusing on this project now, I use nrf 52840 as a coordinator which is based on the zigbee-shell example, and I sent bind request to the coordinator by the light device at first, it response with a success signal. Then a configure reporting request was also sent by the light device, but the coordinator did not response. What is going on?

here is the sniffer log:
the transport key is:3d02b59e8ff81858d569c6d6c5c6aca8devzone.nordicsemi.com/.../5504.10_2D00_24.pcapng

RE: ZigBee dimmable light level control attribute reporting

jostar — Thu, 12 Oct 2023 05:11:09 GMT

Hi Marte,

Thank you for your help.

Best regards,

Jostar

RE: ZigBee dimmable light level control attribute reporting

Marte Myrvold — Tue, 10 Oct 2023 08:28:13 GMT

Hi Jostar,

The packets in the latest sniffer log are encrypted, so I am not able to see the contents of the packets.

I gave you incorrect information in my previous reply, so I apologize for that. This is the correct information:

If the binding request is sent from the reporting device (light device) to the receiver (coordinator), the source address and endpoint should be the receiver device and the destination should be the reporting device.
If the binding request is sent from the receiver (coordinator) to the reporting device (light device), the source address and endpoint should be the reporting device and the destination should be the receiver.

So you were doing it correctly previously. I am not sure why the coordinator responded with 'Unsupported General Command' to the Configure Reporting command, but I see that the coordinator is not a Nordic device. Could you try with a Nordic coordinator to see if that also returns unsupported? You can for example use the Zigbee shell sample as coordinator.

Best regards,
Marte

RE: ZigBee dimmable light level control attribute reporting

jostar — Tue, 10 Oct 2023 05:43:41 GMT

Hi Marte,

I did made a mistake of the source device and the destination device. After I revised my code, it comes another question. When the endpoint device send a bind request to the coordinator, the coordinator response with "Not supported ". What should I do now?

Here is the sniffer log. You can see the response in line 59 and Line 77.

devzone.nordicsemi.com/.../10_5F00_8_5F00_log1.pcapng

Best regards,

Jostar

RE: ZigBee dimmable light level control attribute reporting

Marte Myrvold — Mon, 09 Oct 2023 13:38:43 GMT

Hi Jostar,

[quote user="jostar"]1) The configure reporting request send after I configured the binding from the reporting device (the light device in my case). But it still response "unsupported general command", and without attribute reporting, which can be find in the sniffer log in line 388. 390 and 403. [/quote]

Regarding the bind request, the source address and endpoint should be the address and endpoint of the reporting device, which I assume is the Nordic device in your case (address f4:ce:36:78:be:0a:54:17), while the destination address and endpoint is that of the device that will receive the reports.

Try sending the configure reporting command to the same endpoint as the one you create the binding for (based on your bind request this is endpoint 0 if the Nordic device is the reporting device), instead of the broadcast endpoint 255.

[quote user="jostar"]2) I had tried to binding the custom(private) cluster, the coordinator response "binding table full". What can I do to solve it. It can be find in the sniffer log in line 204.[/quote]

You can send a Binding Table Request to the coordinator to see if the binding table is full. If it is full, you can delete bindings you do not need.

Best regards,
Marte

RE: ZigBee dimmable light level control attribute reporting

jostar — Sat, 07 Oct 2023 07:57:23 GMT

Hi Marte,

Sorry for long time without replying. Your advices had helped me a lot, but I still got some question with it, which are listed as below:
1) The configure reporting request send after I configured the binding from the reporting device (the light device in my case). But it still response "unsupported general command", and without attribute reporting, which can be find in the sniffer log in line 388. 390 and 403.

2) I had tried to binding the custom(private) cluster, the coordinator response "binding table full". What can I do to solve it. It can be find in the sniffer log in line 204.

Best regards,
Jostar

devzone.nordicsemi.com/.../10_5F00_7_5F00_log.pcapng

RE: ZigBee dimmable light level control attribute reporting

Marte Myrvold — Wed, 27 Sep 2023 08:31:40 GMT

Hi Jostar,

Regarding the sniffer log. You do not send any bind requests to create a new binding in the sniffer log. I see a binding table request, but this command is used to retrieve information about the binding table on a device, that is, which bindings already exist on the device. It does not create a new binding.

You can see the difference between the two packets here:
Binding Table Request (to get information about bindings):

Bind Request (to configure a new binding):

[quote user="jostar"]By the way, If I want to send a report attribute command to the coordinator by the endpoint after I press the button3 every time(not automatically), which API(macro) should I used?[/quote]

What is it you want to achieve by doing this? There is no macro for directly sending a report attribute command, but there might be other solutions to this depending on why you want to do this.

[quote user="jostar"]And, how to retrieve the long address of the coordinator?[/quote]

If you know the short address of the device, which in this case is 0x0000, you can send an IEEE address request, similar to this:

typedef struct parent_device_params_s
{
  zb_uint8_t  endpoint;
  zb_uint16_t short_addr;
  zb_addr_u nwk_addr;
} parent_device_params_t;

static parent_device_params_t     parent_device_ctx;

/**@brief A callback called on EUI64 address response.
 *
 * @param[in] bufid Reference number to ZBOSS memory buffer.
 */
static void zb_resolve_ieee_addr_cb(zb_bufid_t bufid)
{
    zb_zdo_ieee_addr_resp_t * p_resp = (zb_zdo_ieee_addr_resp_t *)zb_buf_begin(bufid);
    zb_char_t addr_buf[2 * 8 + 1];    /* 8 bytes (2 characters) plus one byte for null-terminator. */

    if (p_resp->status == ZB_ZDP_STATUS_SUCCESS)
    {
        ZB_LETOH64(parent_device_ctx.nwk_addr.addr_long, p_resp->ieee_addr_remote_dev);
        ieee_addr_to_str(addr_buf, sizeof(addr_buf), parent_device_ctx.nwk_addr.addr_long);
        LOG_INF("Received EUI64 address for device 0x%04x -> %s", parent_device_ctx.short_addr, addr_buf);
    }
    else
    {
        LOG_WRN("Unable to resolve EUI64 source address. Status: %d",
                        p_resp->status);
    }

    zb_buf_free(bufid);
}

/**@brief Resolve EUI64 by sending IEEE address request.
 *
 * @param[in] nwk_addr  Network address to be resolved.
 */
static void zb_resolve_ieee_addr()
{
    zb_zdo_ieee_addr_req_param_t * p_req = NULL;
    zb_bufid_t                     bufid;

    bufid = zb_buf_get_out();
    zb_uint16_t dst_short_addr = 0x0000;

    // Create new IEEE address request and fill with default values.
    p_req = ZB_BUF_GET_PARAM(bufid, zb_zdo_ieee_addr_req_param_t);
    p_req->start_index  = 0;
    p_req->request_type = 0;
    p_req->nwk_addr     = dst_short_addr;
    p_req->dst_addr     = p_req->nwk_addr;
    zb_zdo_ieee_addr_req(bufid, zb_resolve_ieee_addr_cb);
}

If you use a struct like parent_device_ctx as in the code above, you can use this in the bind request like so:

ZB_MEMCPY(p_req->src_address, parent_device_ctx.nwk_addr.addr_long, sizeof(zb_ieee_addr_t));

Best regards,
Marte

RE: ZigBee dimmable light level control attribute reporting

jostar — Tue, 26 Sep 2023 12:35:21 GMT

Hi,

You've really helped me a lot! I understand how the report attribute works now. By the way, If I want to send a report attribute command to the coordinator by the endpoint after I press the button3 every time(not automatically), which API(macro) should I used?

The sniffer log file is upload below. As you can see, in line 115(I press the button), the endpoint send a configuring reporting command, and in line 119, the coordinator send back a response "unsupport general command" with no attribute report response.

Bset regards,

Jostar

devzone.nordicsemi.com/.../9_5F00_27_5F00_log.pcapng

RE: ZigBee dimmable light level control attribute reporting

Marte Myrvold — Tue, 26 Sep 2023 10:12:17 GMT

Hi,

Please upload the sniffer log as a pcap file so I can look at the packets.

[quote user="jostar"]1)Is the API ZB_ZCL_GENERAL_INIT_CONFIGURE_REPORTING_CLI_REQ, ZB_ZCL_GENERAL_ADD_RECV_REPORT_CONFIGURE_REPORTING_REQ and ZB_ZCL_GENERAL_SEND_CONFIGURE_REPORTING_REQ I used is corret?[/quote]

Yes, these are the correct macros to use when configured on the reporting device, and the macros are filled correctly.

[quote user="jostar"]2)Is every time I call zb_zcl_start_attr_reporting function, then the endpoint device will report its attribute to the coordinator?[/quote]

No, this is not how reporting works. What you are doing in configure_attr_reporting() is to configure and enable the reporting, and this only needs to be done once. After it is configured, the device should automatically start sending the attribute report periodically. You do not need to manually start and stop the reporting.

One important thing is that in order to configure reporting, you need to first create bindings between the two devices on the cluster that should be reported. This is done by sending a bind request, with zb_zdo_bind_req(). If you configure the binding from the reporting device (the light device in your case), it can be done similar to this:

static void bind_req()
{
    zb_bufid_t                   bufid;
    zb_ieee_addr_t               src_nwk_addr;
    zb_zdo_bind_req_param_t    * p_req;
    

    bufid = zb_buf_get_out();

    // Get the long address of the reporting device
    zb_osif_get_ieee_eui64(src_nwk_addr);

    zb_uint16_t receiver_short_addr = 0x0000;
    
    p_req = ZB_BUF_GET_PARAM(bufid, zb_zdo_bind_req_param_t);
    // receiver_nwk_addr is the long address of the device that will receive the reports
    // This needs to be retrieved in some way
    ZB_MEMCPY(p_req->src_address, receiver_nwk_addr, sizeof(zb_ieee_addr_t));
    p_req->src_endp = 255
    p_req->cluster_id = ZB_ZCL_ATTR_LEVEL_CONTROL_CURRENT_LEVEL_ID;
    p_req->dst_addr_mode = ZB_BIND_DST_ADDR_MODE_64_BIT_EXTENDED;
    ZB_MEMCPY(p_req->dst_address.addr_long, src_nwk_addr, sizeof(zb_ieee_addr_t));
    p_req->dst_endp = HA_DIMMABLE_LIGHT_ENDPOINT;

    p_req->req_dst_addr = receiver_short_addr;


    zb_zdo_bind_req(bufid, zb_bind_callback);
}

This code is provided as if, so please make sure to modify it to your needs and test that it works.

Best regards,
Marte

RE: ZigBee dimmable light level control attribute reporting

jostar — Tue, 26 Sep 2023 01:41:39 GMT

Hi, here is my sniffer log, log circled in red are sent by the coordinator.

RE: ZigBee dimmable light level control attribute reporting

jostar — Mon, 25 Sep 2023 12:22:01 GMT

Hi Marte,
The "unsupported general command" response was sent by the coordinator, and I will share the sniffer log tomorrow morning, cause I am not in my office now. After that, I still have some question:
1)Is the API ZB_ZCL_GENERAL_INIT_CONFIGURE_REPORTING_CLI_REQ, ZB_ZCL_GENERAL_ADD_RECV_REPORT_CONFIGURE_REPORTING_REQ and ZB_ZCL_GENERAL_SEND_CONFIGURE_REPORTING_REQ I used is corret?
2)Is every time I call zb_zcl_start_attr_reporting function, then the endpoint device will report its attribute to the coordinator?

Your response to this question will be great help! Thanks.

Best regards,

Jostar

RE: ZigBee dimmable light level control attribute reporting

Marte Myrvold — Mon, 25 Sep 2023 11:59:15 GMT

Hi,

Was the "unsupported general command" response sent as a response to the configure reporting command from the light device, or something else?

Please share the sniffer log as a pcap file.

Best regards,
Marte

RE: ZigBee dimmable light level control attribute reporting

jostar — Mon, 25 Sep 2023 05:59:30 GMT

Configure report attributes code

static void configure_attr_reporting(bulb_device_ctx_t m_device_ctx){
    zb_bufid_t                  bufid;
    configure_reporting_req_t   req;
    zb_uint8_t                * cmd_ptr;
    
	zb_uint16_t addr = 0x0000;
    
    bufid = zb_buf_get_out();

	ZB_ZCL_GENERAL_INIT_CONFIGURE_REPORTING_CLI_REQ(bufid, cmd_ptr, ZB_ZCL_ENABLE_DEFAULT_RESPONSE);
	ZB_ZCL_GENERAL_ADD_RECV_REPORT_CONFIGURE_REPORTING_REQ(cmd_ptr, ZB_ZCL_ATTR_LEVEL_CONTROL_CURRENT_LEVEL_ID, 0);
	ZB_ZCL_GENERAL_SEND_CONFIGURE_REPORTING_REQ(bufid, cmd_ptr, addr, ZB_APS_ADDR_MODE_16_ENDP_PRESENT, 255, HA_DIMMABLE_LIGHT_ENDPOINT, ZB_AF_HA_PROFILE_ID
												, ZB_ZCL_CLUSTER_ID_LEVEL_CONTROL, NULL);

}

button press callback code

static void start_reporting(zb_bufid_t bufid)
{
	configure_attr_reporting(dev_ctx);

	if(RET_OK == zb_zcl_start_attr_reporting(HA_DIMMABLE_LIGHT_ENDPOINT, ZB_ZCL_CLUSTER_ID_LEVEL_CONTROL, ZB_ZCL_CLUSTER_SERVER_ROLE, ZB_ZCL_ATTR_LEVEL_CONTROL_CURRENT_LEVEL_ID))
	{
		printf("report sucess start!\n");
	}

	if(ZB_TRUE == zcl_is_attr_reported(HA_DIMMABLE_LIGHT_ENDPOINT, ZB_ZCL_CLUSTER_ID_LEVEL_CONTROL, ZB_ZCL_CLUSTER_SERVER_ROLE, ZB_ZCL_ATTR_LEVEL_CONTROL_CURRENT_LEVEL_ID)){
		printf("report sucess send!\n");
	}
	
	// zb_zcl_stop_attr_reporting(HA_DIMMABLE_LIGHT_ENDPOINT, ZB_ZCL_CLUSTER_ID_LEVEL_CONTROL, ZB_ZCL_CLUSTER_SERVER_ROLE, ZB_ZCL_ATTR_LEVEL_CONTROL_CURRENT_LEVEL_ID);
}


/**@brief Callback for button events.
 *
 * @param[in]   button_state  Bitmask containing the state of the buttons.
 * @param[in]   has_changed   Bitmask containing buttons that have changed their state.
 */
static void button_changed(uint32_t button_state, uint32_t has_changed)
{
	/* Calculate bitmask of buttons that are pressed and have changed their state. */
	uint32_t buttons = button_state & has_changed;

	if (buttons & IDENTIFY_MODE_BUTTON) {
		ZB_SCHEDULE_APP_CALLBACK(start_identifying, 0);
	}

	if (buttons & DK_BTN3) {
		printk("start reporting\n");
		ZB_SCHEDULE_APP_CALLBACK(start_reporting, 0);
	}

}