CC2562P: How To Implement Optional Attributes

Luca Vetri

Other Parts Discussed in Thread: CC2531EMK

Hi,

I've been consulting the danfoss datasheet and I found some interesting commands/attributes but they marked as optional.

Indeed when I try to read an attribute I get 0x86 as return value.

What Do I have to do to implement an optional attribute or access it?

(The source code I'm writing is in Java.)

Hardware:

CC2562P Sonoff dongle
Danfoss Thermostat

Firmware:

ZStack 3.0.x (Default One you get when buying the dongle)

over 4 years ago

0 YiKai Chen over 4 years ago

Guru 735705 points

I suppose you need to get complete specification for custom command/attributes so you can know how to take care of them in your application.

0 Luca Vetri over 4 years ago in reply to YiKai Chen

Intellectual 560 points

What do you mean by "complete specification"?

Danfoss DataSheet: Danfoss

0 YiKai Chen over 4 years ago in reply to Luca Vetri

Guru 735705 points

What attribute do you read and get 0x86?

0 Luca Vetri over 4 years ago in reply to YiKai Chen

Intellectual 560 points

ClusterID: 0x0201 AttributeID: 0x4015

0 YiKai Chen over 4 years ago in reply to Luca Vetri

Guru 735705 points

There is no attribute ID 0x4015 in cluster ID 0x0201 of Danfoss datasheet so you get 0x86 which is unsupported.

0 Luca Vetri over 4 years ago in reply to YiKai Chen

Intellectual 560 points

Page 5 you can find the "External Measured Room Sensor" attribute. which value is 0x4015

0 YiKai Chen over 4 years ago in reply to Luca Vetri

Guru 735705 points

Are you sure your Danfoss implements this attribute? You can setup sniffer to check it returns unsupported .

0 Luca Vetri over 4 years ago in reply to YiKai Chen

Intellectual 560 points

On ZigBee2MQTT it works.

So I was wondering how do you implement an optional attribute/command.

0 Ryan Brown1 over 4 years ago in reply to Luca Vetri

TI__Guru**** 223757 points

Hello Luca,

The ZNP does not have a ZCL layer and would not know what attributes are optional on a remote device. You can check sniffer logs between Zigbee2MQTT and your setup to determine what differences in the Attribute Read Commands could result in the unsupported attribute response.

Regards,
Ryan

0 YiKai Chen over 4 years ago in reply to Luca Vetri

Guru 735705 points

Do you use ZTool to do ZCL read attribute?

0 Luca Vetri over 4 years ago in reply to YiKai Chen

Intellectual 560 points

Yes I do use ZTool to perform a read using AF_DATA_REGISTER.

The payload data is: 10 01 00 15 40 (also tried: 01 01 00 15 40)

0 YiKai Chen over 4 years ago in reply to Luca Vetri

Guru 735705 points

I don’t think AF_DATA_REGISTER is correct command. It should be AF_DATA_REQUEST.

0 Luca Vetri over 4 years ago in reply to YiKai Chen

Intellectual 560 points

Yea, I meant AF_DATA_REQUEST, rushed to write the answer. My bad.

0 YiKai Chen over 4 years ago in reply to Luca Vetri

Guru 735705 points

Try to use “40 01 00 40 15” as payload.

0 Luca Vetri over 4 years ago in reply to YiKai Chen

Intellectual 560 points

Answer: Data: ...@.. (0x08, 0x01, 0x01, 0x40, 0x15, 0x86)

So still nothing. Which is weird because how the hell does the danfoss gateway communicate with it if it is not implemented?

0 YiKai Chen over 4 years ago in reply to Luca Vetri

Guru 735705 points

I don’t remember exactly payload for now. Maybe you can try “01 01 00 40 15” again. The best way to verify payload is to setup sniffer to check what send over the air exactly.

0 Luca Vetri over 4 years ago in reply to YiKai Chen

Intellectual 560 points

Unfortunately I can't set up a sniffer.

But is it possible to implement an optional attribute or it is something done directly on the end-device firmware?

0 YiKai Chen over 4 years ago in reply to Luca Vetri

Guru 735705 points

If the device implemented optional attribute, it should be no problem to use ZTool AF_DATA_REQUEST to send ZCL read attribute to get correct response. Please setup sniffer which will save you lots of debug time.

0 Luca Vetri over 4 years ago in reply to YiKai Chen

Intellectual 560 points

I will try to find a way set up a sniffer tomorrow.

I will update you tomorrow.

So if the attribute is not implemented is a problem of the danfoss valve and I can't do anything about it?

ATTENTION: The AF_INCOMING_MSG has a strange composition. Can't understand what [0x0C 0x46] and 0x1C they always present when a manufacturer code get reported.

fe 1d 
44 81 --> INCOMING MSG
0 0 1 2 67 87 1 1 0 3f 0 71 f0 16 0 0 --> VARIOUS DATA
9 --> LEN OF PAYLOAD
c 46 --> DON'T KNOW WHAT IT IS

12 19 a --> ZIGBEE ATTRIBUTE REPORT COMMAND
31 40 --> OPTIONAL ATTRIBUTE
10 1 --> VALUE

cf b1  --> END-DEVICE NWK ADDR
1c ---> DON'T KNOW WHAT IT IS
d3 --> FCS

0 YiKai Chen over 4 years ago in reply to Luca Vetri

Guru 735705 points

Yes, you can't do anything about it if the attribute is not implemented.

0 Ryan Brown1 over 4 years ago in reply to Luca Vetri

TI__Guru**** 223757 points

If the attribute works for the Zigbee2MQTT and Danfoss gateway then you will need the sniffer to understand more about the correct communication protocols and packet structure used to acquire information. Since the AF_INCOMING_MSG is relaying ZCL information, I assume the first data byte 0x0c is the frame control (server-to-client direction, manufacturer specific) and 0x46 is the transaction sequence number. With these manufacturer codes, you would need to ask the manufacturer about additional information.

Regards,
Ryan

0 YiKai Chen over 4 years ago in reply to Luca Vetri

Guru 735705 points

Luca Vetri After checking ZCL spec and testing with ZTool, I think correct payload should be "00 01 00 15 40"

0 Luca Vetri over 4 years ago in reply to YiKai Chen

Intellectual 560 points

Hi,

YiKai Chen I've tried the command but still 0x86.

YiKai Chen Ryan Brown1I will setup now a sniffer using the CC2531EMK Card. Do you prefer WireShark or TI Packet Sniffer?

BR,

Luca Vetri

0 Luca Vetri over 4 years ago in reply to YiKai Chen

Intellectual 560 points

Here is the sniffer log: made multiple read and write on the manufacturer attributes.

0x90C1 is the Network Address of the thermostat

I've used TI Packet Sniffer. (Not version 2)

Danfoss.psd

0 YiKai Chen over 4 years ago in reply to Luca Vetri

Guru 735705 points

According to your sniffer log, you send the read command successfully and get read attribute response. Where do you see 0x86?

0 Luca Vetri over 4 years ago in reply to YiKai Chen

Intellectual 560 points

When I try using Z-Tool I get 0x86. ZigBee2MQTT Works Fine. This is why i'm confused.

(Also: what software you using? Looks Good)

0 YiKai Chen over 4 years ago in reply to Luca Vetri

Guru 735705 points

I use Ubiqua Protocol Analyzer to decode you sniffer log. The Danfoss.psd is captured when you use ZigBee2MQTT or Z-Tool? Can you do screenshot to show me how you use Z-Tool to send read command and what youget 0x86?

0 Luca Vetri over 4 years ago in reply to YiKai Chen

Intellectual 560 points

The Sniffer Log is using ZigBee2MQTT.

Will now use Z-Tool and screenshot it. Coming to you in a 10 minutes.

Would like to thank you for the patience.

0 Luca Vetri over 4 years ago in reply to YiKai Chen

Intellectual 560 points

Here It Is.

*** WARNING ***
    Unsupported or unformatted message received.  Raw data: 
    0C 45 CA 36 18 41 56 39 FE FF CC CC CC 00 00 

*** WARNING ***
    Unsupported or unformatted message received.  Raw data: 
    0C 45 CA 36 18 41 56 39 FE FF CC CC CC 00 00 

*** WARNING ***
    Unsupported or unformatted message received.  Raw data: 
    0C 45 CA 36 18 41 56 39 FE FF CC CC CC 00 00 

<RX>11:24:36.19 COM4 ZDO_END_DEVICE_ANNCE_IND (0x45C1)
    SrcAddr: 0x1836
    NwkAddr: 0x1836
    IEEEAddr: 0xCCCCCCFFFE395641
    Capabilities: 0x80

<TX>11:25:46.67 COM4 AF_DATA_REQUEST (0x2401)
    DstAddr: 0x1836
    DestEndpoint: 0x01
    SrcEndpoint: 0x01
    ClusterID: 0x0201
    TransID: 0x01
    Options: 0x00
    Radius: 0x1E
    Len: 0x05
    Data: ....@ (0x00, 0x01, 0x00, 0x15, 0x40)

<RX>11:25:46.68 COM4 AF_DATA_REQUEST_SRSP (0x6401)
    Status: afStatus_SUCCESS (0x0)

<RX>11:25:46.7 COM4 AF_DATA_CONFIRM (0x4480)
    Status: afStatus_SUCCESS (0x0)
    Endpoint: 0x01
    TransID: 0x01

<RX>11:25:46.72 COM4 AF_INCOMING_MSG (0x4481)
    GroupID: 0x0000
    ClusterID: 0x0201
    SrcAddr: 0x1836
    SrcEndpoint: 0x01
    DstEndpoint: 0x01
    WasBroadcast: 0x00
    LinkQuality: 0x56
    SecurityUse: 0x00
    Timestamp: 0x0007F6D8
    TransSeqNumber: 0x00
    Len: 0x06
    Data: ....@. (0x08, 0x01, 0x01, 0x15, 0x40, 0x86) <-- HERE.

0 YiKai Chen over 4 years ago in reply to Luca Vetri

Guru 735705 points

Do you have sniffer log when you test this?

0 Luca Vetri over 4 years ago in reply to YiKai Chen

Intellectual 560 points

Unfortunately no.

Z-Tool works only with the CC2531EMK Daughter Card and not with the sonoff dongle. (Maybe due to the Silicon Labs Bridge?)

So I either use it for Z-Tool or to sniff.

0 Luca Vetri over 4 years ago in reply to YiKai Chen

Intellectual 560 points

What I can possibly do is run ZigBee2MQTT and by using a software to USB Sniff I can possibly see what Z2M sends to the coordinator.

I can't set it up today so I need to wait a day, or two. Can't afford that much time, but out of necessity I possibly can.

+1 YiKai Chen over 4 years ago in reply to Luca Vetri

Guru 735705 points

Try to use "14 46 12 17 00 15 40" as payload to send from ZTool to see if it works.

0 Luca Vetri over 4 years ago in reply to YiKai Chen

Intellectual 560 points

Sure. Will get you back in 5 minutes

0 YiKai Chen over 4 years ago in reply to Luca Vetri

Guru 735705 points

I mimic the payload from ZigBee2MQTT so I think it should work.

0 Luca Vetri over 4 years ago in reply to YiKai Chen

Intellectual 560 points

Actually it worked! Don't know how Z2M Makes the packet but it works.

Looks like that when you read the data you get a 0xC 0x46 at the beginning.

Meanwhile if you want to change value you have to add 0x14 and 0x46 at the beginning. Pretty Strange won't lie haha

<TX>11:50:30.36 COM4 AF_DATA_REQUEST (0x2401)
    DstAddr: 0x1836
    DestEndpoint: 0x01
    SrcEndpoint: 0x01
    ClusterID: 0x0201
    TransID: 0x01
    Options: 0x00
    Radius: 0x1E
    Len: 0x07
    Data: .F....@ (0x14, 0x46, 0x12, 0x17, 0x00, 0x15, 0x40)

<RX>11:50:30.37 COM4 AF_DATA_REQUEST_SRSP (0x6401)
    Status: afStatus_SUCCESS (0x0)

<RX>11:50:32.39 COM4 AF_DATA_CONFIRM (0x4480)
    Status: afStatus_SUCCESS (0x0)
    Endpoint: 0x01
    TransID: 0x01

<RX>11:50:32.4 COM4 AF_INCOMING_MSG (0x4481)
    GroupID: 0x0000
    ClusterID: 0x0201
    SrcAddr: 0x1836
    SrcEndpoint: 0x01
    DstEndpoint: 0x01
    WasBroadcast: 0x00
    LinkQuality: 0x59
    SecurityUse: 0x00
    Timestamp: 0x0006D70F
    TransSeqNumber: 0x00
    Len: 0x0B
    Data: .F....@.).. (0x0C, 0x46, 0x12, 0x17, 0x01, 0x15, 0x40, 0x00, 0x29, 0xC0, 0xE0)

0 Luca Vetri over 4 years ago in reply to Luca Vetri

Intellectual 560 points

I will now check if the code 0x14 0x46 also works with the write command or not.

Edit: Also works with Write Command

+1 YiKai Chen over 4 years ago in reply to Luca Vetri

Guru 735705 points

0x0C is frame control byte and 0x1246 is Manufacturer code. Since it works now, do you still have other question?

0 Luca Vetri over 4 years ago in reply to YiKai Chen

Intellectual 560 points

Thank you so much!

Last questions: do the 0x0c and the manufacturer code have to be added to each AF_DATA_REQUEST when i want to access a manufacturer specific attribute/command?

What is the job of frame control? Why it is not always added?

0 YiKai Chen over 4 years ago in reply to Luca Vetri

Guru 735705 points

Manufacturer ID can be found in Danfoss DataSheet: Danfoss

+1 Ryan Brown1 over 4 years ago in reply to Luca Vetri

TI__Guru**** 223757 points

These results make sense, given that Frame Control is the first byte of ZCL packets.

// ZCL header - frame control field
/// The frame control field is 8 bits in length and contains information defining
/// the command type and other control flags.
typedef struct
{
  unsigned int type:2; //!< Frame type
  unsigned int manuSpecific:1; //!< Manufacturer specific
  unsigned int direction:1; //!< Direction
  unsigned int disableDefaultRsp:1; //!< Disable Default Response
  unsigned int reserved:3; //!< Reserved
} zclFrameControl_t;

The sensor expects the manuSpecific bit to be set, in which case the next two bytes of the ZCL Frame Header would need to be the manuCode

// ZCL header
/// The ZCL frame format is composed of a ZCL header and a ZCL payload
typedef struct
{
  zclFrameControl_t fc; //<! The frame control field is 8 bits in length and contains information defining the command type and other control flags.
  uint16_t            manuCode; //<! The manufacturer code field is 16 bits in length and specifies the assigned manufacturer code for proprietary extensions.
  uint8_t             transSeqNum; //<! The Transaction Sequence Number field is 8 bits in length and specifies an identification number for a single transaction that includes one or more frames in both directions.
  uint8_t             commandID; //<! The Command Identifier field is 8 bits in length and specifies the cluster command being used.
} zclFrameHdr_t;

Next comes the transSeqNum and commandID before the ZCL payload itself.

Regards,
Ryan

0 Luca Vetri over 4 years ago in reply to Ryan Brown1

Intellectual 560 points

Thank you so much! Ryan Brown1 YiKai Chen

Now I fully understand it. It also helped me to refresh my memory regarding the frame control.

Zigbee & Thread

Zigbee & Thread forum

CC2562P: How To Implement Optional Attributes