Read ZCL command field and then call default handler

[Valerio.Colombo]

Hi,

I'm having some difficulties understanding how to manage commands in endpoint-specific callbacks.
For example, when receiving a "ZB_ZCL_CMD_CONFIG_REPORT" I'm able to intercept the command by checking the "zb_zcl_parsed_hdr_t" structure.
My doubt is about the correct way to obtain the command fields values (i.e. for reporting configuration the minimum/maximum reporting interval value...).
Another difficulty is that I would like to read a field of the command and then propagate the command to the default handler.

zb_uint8_t processCommandCallback(zb_bufid_t bufid)
{
    zb_bufid_t zcl_cmd_buf = bufid;
    zb_zcl_parsed_hdr_t *cmd_params = ZB_BUF_GET_PARAM(zcl_cmd_buf, zb_zcl_parsed_hdr_t);
    if (cmd_params->cmd_direction == ZB_ZCL_FRAME_DIRECTION_TO_SRV &&
        cmd_params->is_common_command &&
        cmd_params->cluster_id == <right cluster id> &&
        cmd_params->cmd_id == ZB_ZCL_CMD_CONFIG_REPORT)
    {
        // read minimum reporting value from incoming command for internal usage 
    }
    return ZB_FALSE; // impose ZB_FALSE to propagate command to default handler
}

How can I read the command fields?

Thank you,

Valerio

[Amanda Hsieh]

Hi, 

Usually, with callbacks for ZCL commands you would use zb_zcl_device_callback_param_t in the callback function to get the data, but you can't use this with the configure reporting command. I think the best method is to use ZB_ZCL_GENERAL_GET_NEXT_CONFIGURE_REPORTING_REQ to parse the configure reporting command:

zb_zcl_configure_reporting_req_t *config_rep_req;
ZB_ZCL_GENERAL_GET_NEXT_CONFIGURE_REPORTING_REQ(bufid, config_rep_req);

You should then be able to get the min and max interval from config_rep_req (zb_zcl_configure_reporting_req_s):

config_rep_req->u.clnt.min_interval

config_rep_req->u.clnt.max_interval

There's more information on this here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/zboss/3.11.1.0/group__cfg__reporting__cmd.html

Regards,
Amanda

[Valerio.Colombo]

Hi,

I tried the suggested code and it reads successfully the fields of the reporting command request. But as I feared, when I propagate the command to the default handler, by returning ZB_FALSE, I see from the traces captured with Wireshark that the configuration request response is malformed. I attach the log and a screenshot of the trace.

Thank you,

Valerio

configure_reporting_error.pcapng

[Amanda Hsieh]

Hi, 

The team doesn't really understand what you try to achieve with what you are doing but this may explain some of the bits:

1. Why reading Configure Reporting cmd when this command should be handled by the Zigbee stack?
   
   Reporting is handled internally in the stack and it's better to not mess with that to avoid unwanted behavior.
   Reading and parsing this command in the endpoint handler can cause problems, explained below:
   
   
2. Parsing Configure Reporting cmd with ZB_ZCL_GENERAL_GET_NEXT_CONFIGURE_REPORTING_REQ can modify the buffer the command is stored in.
   You can see that in details inside the ZB_ZCL_GENERAL_GET_NEXT_CONFIGURE_REPORTING_REQ.
   
   
3. Endpoint handlers are used to intercept ZCL frames coming to the specific endpoint and the value returned by the handler function tells the stack if this command should be further processed or not:
   ZB_FALSE if stack should process it,
   ZB_TRUE if the command was processed in the handler function and should not be processed by the stack.

Endpoint handlers are frequently used in Zigbee Shell (cli agent in nRF5 SDK) and there are few use cases implemented there. Zigbee shell in NCS doc

When it comes to parsing the ZCL frame fields, the Zigbee endpoint logger can be an example implementation of that. Zigbee endpoint logger in NCS doc

In general, ZBOSS documentation:

• Regarding endpoint handlers and configuration
• Parsing ZCL commands

-Amanda

[Valerio.Colombo]

Hi, thanks for the responses.

I'll explain what we're trying to do so that you have some context. We are implementing some Zigbee sensors. Let’s take the example of a temperature sensor. We would like to take a measurement at a rate equal to the minimum reporting period, so as not to make useless measurements. In our case, the minimum reporting period is not known a priori but is discovered/configured at runtime. We would like to obtain it and use it to set our internal measurement frequency instead of hardcoding it.

To rephrase, is there's some intended way to match the reporting frequency to the sensor measurement frequency at runtime?

The problem could be solved also by reading the values from the "zb_zcl_reporting_info_t" structure. To do so, a mechanism that notifies when the configuration has been done is needed.

Is there a way to know when the reporting has been configured, without periodically checking the structure for changes?

Thank you,

Valerio

[Amanda Hsieh]

Hi, 

From the team:

Alright, I didn't see that coming. This is doable but I haven't tested this - be careful not to change things that shouldn't be changed.

One way to do this is:

1. There is always a reporting default configuration, after the device startup the measurement frequency should be adjusted to that.
2. For runtime configuration changes, parse incoming ZCL command to look for Configure Reporting frame and once catched, schedule adjusting measurement frequency. Be careful and don't parse the payload, left it to the stack.
3. zb_zcl_reporting_info_t can be read (don't make any changes in this structure!) to get minimum reporting interval, zb_zcl_find_reporting_info() should return a pointer to a structure corresponding to a temperature attribute.
   For this structure to be updated, the stack needs to process the received command - schedule adjusting measurement frequency after some delay.

One thing to consider: reporting can be configured with minimum interval set to zero, so be aware of possible edge cases.
Also, with change-based reporting it would be to an application to select the measurement frequency - minimum reporting interval doesn't provide such information in this case.

I would also suggest getting familiar with ZCL Specification (2.5.7 Configure Reporting Command) to understand possible reporting configurations.

Regards,
Amanda