search

dresden-elektronik / deconz-serial-protocol

deCONZ Serial Protocol
7 stars 2 forks source link

DeviceState reports 0xA6, but what does the highest bit mean ? #9

Closed pwielders closed 2 years ago

pwielders commented 3 years ago

Was using this specification to write a module for the RDK Thunder framework (https://github.com/rdkcentral). Thanks for the eleborative specification realy usefull. However while testing the software I ran into a new value for the device status. It gave 0xA6. The highets bit of the DeviceState is not described in the document, but what is the meaning of the 0x80 bit ?

Here are the message exchanges:

Currently the queue holds: 0 messages, sending out a size of 46 Send: 12:56:00:29:00:22:00:03:00:02:8F:CF:01:5E:DB:DC:00:00:01:13:00:00:01:00:00:00:01:00:02:00:03:00:04:00:05:00:06:00:07:00:00:00:9A:FC:C0:

Received: 12:56:00:09:00:02:00:22:03:

Received: 0E:57:00:07:00:A6:00: A6 ->8,2 | 4,2 -> 8???, Request FreeSots flag and Data Confirm

manup commented 3 years ago

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

pwielders commented 3 years ago

Thanks. Will try to work with this firmware.

pwielders commented 3 years ago

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 ...