Message ZBHCI_CMD_DATA_CONFIRM with status 0xA7 or 0xA9

wes58

I have 2 devices which are "sleeping", end-devices. They both have the same code.
When I send the message to the first device to turn it on or off I receive response - 55820000090002 24A5 01 19 0006 A7 43 AA with status code 0xA7
The only information about status code 0xA7 I could find in aps_api.h
APS_STATUS_NO_ACK           = 0xa7

When I send the message to the second device to turn it on or off I receive response - 55820000090002 24A5 01 19 0006 E9 44 AA with status code 0xE9
The only information about status code 0xA7 I could find in tl_zb_mac.h
MAC_STA_NO_ACK             = 0xE9

The devices receive the message because they are turned on or off.

1. What is the reason and is it possible to fix this?
2. Why first device always receives message with status code 0xA7 and the other one always with status code 0xE9?
I understand that it may something to do with that they are slepping devices but why 1 gest 0xA7 and the other one always 0xE9?
And there is no problem with other end-devices with different code/function.

wes58

I found the reason for this issue.
Recent SDKs use DEFAULT_POLL_RATE which is defined for each project. Those 2 device were compiled with one of those SDKs
#define DEFAULT_POLL_RATE                                        (10 * (4 * POLL_RATE_QUARTERSECONDS)) //10 sec.

All other devices I had were compiled a couple of years ago and used SDK with a global definition (for all projects) of POLL_RATE defined in zb_config.h
#define POLL_RATE                                                                        (4 * POLL_RATE_QUARTERSECONDS) //1 sec

So 10 sec polling rate caused the message with status APS_STATUS_NO_ACK or MAC_STA_NO_ACK.

What is a difference between the to status codes 0xA7 and 0xE9? Why one device received always 0xA7 and the other 0xE9?

TL_YANGBIN

The above figure shows the handshake process of normal communication.
MAC ACK is a point-to-point response, while APS ACK is a message response that can be relayed.


For sleep ZED devices that require frequent message reception, it is recommended that the polling rate not be less than 6 seconds.
Because the time for the parent node to cache messages for SED is 7.68 seconds, the messages will be discarded after timeout.

wes58

TL_YB 发表于 2026-1-8 10:56
The above figure shows the handshake process of normal communication.
MAC ACK is a point-to-point ...

To receive response in more than 6 seconds is a very long delay!

TL_YANGBIN