Hello,
I recognized a wrong answer is sent by the ZigBee stack of nRF Connect 1.5.1 and 1.7.0 (and others).
Eg. the application provides a color control cluster as a server.
Whenever a device reads attributes from this server with unsupported attributes included first in the read-attribute-command, then the answer will be wrong.
The first unsupported attributes are reported correctly as unsupported but the next supported attribute will be reported twice. First correctly as supported but additionally in the same packet as unsupported. Screenshot is provided.
In "zb_zcl_general_commands.c" in "zb_zcl_read_attr_handler_continue" the "status = ZB_ZCL_STATUS_SUCCESS;" should be set at the beginning of the loop - not before the loop.
Best regards,
Alex
