'esp_zb_core_action_callback' does not receive report attribute action from the cluster that is not implemented on the destination endpoint (TZ-310)

[Ravenen]

Hello,

I'm currently working on a custom ZigBee gateway project. Specifically, I'm focusing on configuring attributes reporting for the end device. To achieve this, I send a 'configure reporting' command to the end device's attribute and attempt to receive the report through the 'esp_zb_core_action_callback'.

I encountered an issue where I'm unable to receive the ESP_ZB_CORE_REPORT_ATTR_CB_ID event, even though I successfully receive the ESP_ZB_CORE_CMD_REPORT_CONFIG_RESP_CB_ID. However, using the ZBOSS API, I discovered that the command ZB_ZCL_CMD_REPORT_ATTRIB is indeed received by my device, indicating that attribute reporting is functioning.

To solve this, I tried adding the desired attribute's cluster implementation to my application endpoint, and it worked! Now I'm receiving the ESP_ZB_CORE_REPORT_ATTR_CB_ID as expected. Hence, I concluded that the esp_zb_core_action_callback generator implementation includes a filtration mechanism that prevents the generation of the event for endpoints lacking the corresponding cluster implementation.

Therefore, if I want my gateway to receive all attributes reporting, I would need to implement all clusters on the application endpoint. However, I find this solution less elegant. Is there an alternative way to receive the event via the 'esp_zb_core_action_callback' without implementing all clusters? Is there any possibility of adding this feature?

Thank you in advance!

[xieqinan]

@Ravenen ,

Hello,

Your guess is correct; if the reporting attribute of a cluster has not been implemented, the report will be dropped.

Why would you want to receive a report that isn't related to your device? It doesn't seem to have any meaningful purpose.

Furthermore, we offer the esp_zb_raw_command_handler_register() function, which allows you to register a callback to receive raw ZCL commands. Please note that you will need to use the ZBOSSAPI to parse these commands.

[Ravenen]

@xieqinan,

Thank you so much for responding quickly!

Why would you want to receive a report that isn't related to your device? It doesn't seem to have any meaningful purpose.

I do have a purpose for receiving a report that isn't related to my device. You see, I'm currently working on a ZigBee Gateway device. The main goal of my device is to show comprehensive information from the ZigBee network on a different interface, like a web UI, for example. To achieve that, I need to receive all attributes and commands, so I can process the data (business logic of the application) and display it accordingly.

By the way, I'm aware of the esp_zb_raw_command_handler_register function, but personally, I find the esp_zb_core_action_callback function more convenient, and it meets all my requirements at the moment.

However, if my needs are too specific and implementing such a feature isn't feasible, could you please assist me with parsing the raw command using the ZBOSS API? It would be really helpful if you could provide an example of how to extract the payload of the ZB_ZCL_CMD_REPORT_ATTRIB command, for instance. I would sincerely appreciate your assistance.

[xieqinan]

@Ravenen ,

Please try to use the following code to implement the ZB_ZCL_CMD_REPORT_ATTRIB coomand.

#include "zboss_api.h"
bool esp_zb_raw_command_handler(uint8_t bufid)
{
    zb_zcl_report_attr_req_t *req = NULL;
    zb_zcl_parsed_hdr_t *cmd_info = ZB_BUF_GET_PARAM(bufid, zb_zcl_parsed_hdr_t);

    if(cmd_info && cmd_info->is_common_command && cmd_info->cmd_id == ZB_ZCL_CMD_REPORT_ATTRIB)
    {
        printf("dst_ep: %d, cluster id: 0x%x\n", cmd_info->addr_data.common_data.dst_endpoint, cmd_info->cluster_id);
        do {
            ZB_ZCL_GENERAL_GET_NEXT_REPORT_ATTR_REQ(bufid, req);
            if(req){
                printf("attr_id: 0x%x, type: %d\n", req->attr_id, req->attr_type);
            }    
        }while(req);
    }
    zb_zcl_send_default_handler(bufid, cmd_info, ZB_ZCL_STATUS_SUCCESS);
    return true;
}

[diazmanuel]

hello, @xieqina
i open a Feature Request for this, The solution mentioned above works partially, after some time it stops working printing the following log:

W (296453) ZB_ESP_MAC: MAC RX buffer is full!

I also consider that it is an unsuitable solution since it ends up working at the level of the zboss API, and it is a fairly common case that usually occurs in gateways, in fact I currently encounter this problem. The gateway that we are designing includes several clusters and these will also continue to grow over time, which would end up forcing us to constantly update the gateway firmware to add these new clusters.

[xieqinan]

@diazmanuel,

i open a Feature Request for this, The solution mentioned above works partially, after some time it stops working printing the following log:

W (296453) ZB_ESP_MAC: MAC RX buffer is full!

The users are responsible for freeing the bufid themselves. Add the following code to the end of the esp_zb_raw_command_handler function.

zb_zcl_send_default_handler(bufid, cmd_info, ZB_ZCL_STATUS_SUCCESS);

[xieqinan]

Hello @Ravenen ,

Have you tried using the provided code to resolve your issue? If the solution is effective, kindly consider closing this issue.