DeviceState reports 0xA6, but what does the highest bit mean ? about deconz-serial-protocol HOT 3 CLOSED

This error code was recently also seen in deCONZ when sending a APS request from an source endpoint which isn't registered in the firmware (default is 0x01).

0xA6 means INVALID_PARAMETER status code which is generated when the Zigbee stack tries to send the request.

We are working on a new firmware wich lifts this limitation and allows also receiving messages which are addressed to a non existing endpoint. The following firmware has these two issues fixed, you may give it a try: deCONZ_ConBeeII_0x266c0700.bin.zip

from deconz-serial-protocol.

Thanks. Will try to work with this firmware.

from deconz-serial-protocol.

I will investigate in more detail but it looks like it is due to the escaping. The message shared is getting a ZCL attribute from the LightLink profile, basic cluster. LightLink has the Value 0x5EC0 but becomes 0x5EDBDC (that is according to RFC 1055). However it looks like the firmware interprets it incorrectly.
Message decomposition from the original message (see my initial message):
0x12 -> Enque Send Data Request
0x56 -> Sequence number
0x00 -> Reserved
0x0029 -> Framelength (Payload length + 7)
0x0022 -> Payload Length
0x03 -> Sequence number of frame
0x00 -> Flags
0x02 -> NWK Address to follow
0x08FCF -> Network address of the IKEA light bulb
0x01 -> Destination end point (this is the port for the LightLink profile)
0x5EDBDC -> Profile (but escaped as it is really 0x5EC0, the LightLink profile)
0x0000 -> Cluster ID (Basic cluster)
0x01 -> Source endpoint
0x0013 -> ASDU length (19 bytes)
00:01:00:00:00:01:00:02:00:03:00:04:00:05:00:06:00:07:00 -> 19 bytes data
0x00 -> Tx Options
0x00 -> Radius
0xFC9A -> CRC (the frame without escaping)
0xC0 -> End Of Frame

I think the package is correct according to the spec you delivered but I think the firmware is incorrectly parsing the escaped 0x5EC0 of the light link profile and interprets the endpoint as 0x00 on cluster DC00, could that be ?
I will play with the package (by removing the escaping here and see what happens :-) If I remove the escaping and it works it looks like a firmware bug or I interpreted the specification incorrectly and should only escape the ASDU package, in stead of the full message ????
But I got a feeling that the 0xA6 code is triggered by the Escaped Profile in this message ...

from deconz-serial-protocol.