No response generated when aps_data_indication_handler returns true? (TZ-1159)

[mw75]

Question

Is it expected behavior, that the sdk does not generate a default response to messages that where processed by aps_data_indication_handler?

If so, what is the right way to generate that response? Looks like there is no acknowledge function in the APS-API. Is it right to generate native as esp_zb_apsde_data_req_t and send by sp_zb_aps_data_request within the handler?

Thanks for hints and recommendations.

Additional context.

No response

[lpy4105]

Hi @mw75

If your registered aps_data_indication_handler returns true, it means that APS frame is fully handled by users (in the callback). Thus, the stack will skip all the subsequent processing for that frame.

APS ACK is handled by the stack, but default response is kind of ZCL frame. You could generate a raw ZCL default response frame in the ASDU and send via esp_zb_aps_data_request.

[mw75]

I can't get the default response "on-air" (nothing useful in Wireshark with whsniff). Can you provide an example?

Open questions:

• Where/How to free asdu memory?
• Do i need esp_zb_lock_acquire if i send right from aps_data_indication_cb?
• Are there some "helpers" for creating the asdu?

What i have currently:

bool aps_data_indication_cb(esp_zb_apsde_data_ind_t ind){
    ESP_LOGI(TAG, "aps_data_indication_cb status: %x %x %x",ind.status,ind.profile_id,ind.cluster_id);
    bool processed = false;
    if (ind.status == 0x00) {
        if (ind.dst_endpoint == 0 && ind.profile_id == ESP_ZB_AF_HA_PROFILE_ID ) {
            ESP_LOGI("APSDE INDICATION",
                    "Received APSDE-DATA %s request with a length of %ld from endpoint %d, source address 0x%04hx to "
                    "endpoint %d, destination address 0x%04hx",
                    ind.dst_addr_mode == 0x01 ? "group" : "unicast", ind.asdu_length, ind.src_endpoint,
                    ind.src_short_addr, ind.dst_endpoint, ind.dst_short_addr);
            ESP_LOG_BUFFER_HEX_LEVEL("APSDE INDICATION", ind.asdu, ind.asdu_length, ESP_LOG_INFO);
            esp_zb_apsde_data_req_t req = {
                .dst_addr_mode  = ESP_ZB_ZDO_BIND_DST_ADDR_MODE_64_BIT_EXTENDED,
                .dst_short_addr = ind.src_short_addr,
                .dst_endpoint   = ind.src_endpoint,
                .src_endpoint   = 0,
                .profile_id     = ind.profile_id,
                .cluster_id     = ind.cluster_id,
                .tx_options     = 0,
                .use_alias      = false,
                .alias_src_addr = 0,
                .alias_seq_num  = 0,
                .radius         = 5,
                .asdu_length    = 5,
                .asdu           = (uint8_t[5]){0x18,ind.asdu[0x01],0x0b,ind.asdu[0x02],0x00}
                // 0x10 disable default response | 0x08 Direction: Server to Client
                // Sequence number from received data
                // Command: Default Response 0x0b
                // Response to command from received data
                // Status Success 0x00
            };
            ESP_ERROR_CHECK(esp_zb_aps_data_request(&req));
            processed = true;
        }
    } else {
        ESP_LOGE("APSDE INDICATION", "Invalid status of APSDE-DATA indication, error code: %d", ind.status);
        processed = false;
    }
    return processed;
}

Runs three times before abort() call from Zigbee stack assertion failed common/zb_bufpool_mult.c:1321

[lpy4105]

            .dst_addr_mode  = ESP_ZB_ZDO_BIND_DST_ADDR_MODE_64_BIT_EXTENDED,

Please use the value defined here and I believe the correct mode should be ESP_ZB_APS_ADDR_MODE_16_ENDP_PRESENT.

[mw75]

Wow, great hit! Thanks a million. It is working so far.