Zigbee ZCL read attributes command always times-out without any response.

[Jody P Ono]

I'm using the nRF52840 dongle with nRF Connect 1.90 and the CLI.  I cannot get "zcl attr read" command to return anything.  It simply times-out.  What am I doing wrong?

[Marte Myrvold]

Hi,

What device are you sending the zcl attr read command to, and what cluster and attribute?

Are you able to get a sniffer log of this? If you have an additional nRF52840 Dongle or DK you can use our nRF Sniffer for 802.15.4. Please start the sniffer before the network is started, so the sniffer has the network key.

Best regards,

Marte

[Jody P Ono]

Hi, Marte:

My Wireshark capture looks the same as yours, i.e. I can see broadcast and response packets.  How did you manage to display the specific Zigbee ZCL details of each packet?  Did you use Wireshark?

Best regards,

Jody

[Marte Myrvold]

Hi Jody,

The packets in the sniffer are encrypted. Do you have the network key so that I can decrypt the packets? If not, can you capture a sniffer log where you start the sniffer before the coordinator starts the network so that the sniffer has the network key?

Best regards,

Marte

[Jody P Ono]

Hi, Marte:

Actually, I did start the sniffer before the coordinator and I've never been able to capture the network key,  Is there a way that I can get the network key from the coordinator?

Best regards,

Jody

[Jody P Ono]

Hi, Marte:

The network key is: 41a30653e935ab6f531655f4c4c841d0.

Best regards,

Jody

[Jody P Ono]

Hi, Marte:

I found the problem in my "zcl subscribe on" command.  I was not specifying the correct type.  I did not realize that the response to my earlier attribute queries included the attribute type in hexadecimal while the "subscribe on" command wants the attribute type in DECIMAL.  Anyway, it looks like it's working, sort of.  Should I get a report every time that the subscribed attribute changes?  I'm only seeing one report after I subscribe.

Best regards,

Jody

[Marte Myrvold]

Hi Jody,

Edit: I did not reload the page before publishing this response, so I did not see see that you already figured it out yourself.

I figured out what the issue was. You must use the decimal value for the attr_type in the subscribe on command, and not the hexadecimal value:

zcl subscribe on h:addr d:ep h:cluster h:profile h:attr_id d:attr_type [d:min interval (s)] [d:max interval (s)]

When you send the command with attr_type set to 20, you actually send that the data type of the attribute is 0x14, which is the value for 56-bit data type:

For current hue you should instead use 32 as attr_type:

zcl subscribe on 3e2d 11 0x0300 0x0104 0x00 32 2 5

This will send the command with 8-bit unsigned int as data type, which is the correct one for current hue:

This picture is from a sniffer log I captured where I successfully subscribed on the current hue attribute.

I can understand where the confusion comes from, because zcl attr read shows the hexadecimal value, and not the decimal.

Best regards,

Marte

[Marte Myrvold]

Hi Jody,

Jody P Ono said:

Should I get a report every time that the subscribed attribute changes?  I'm only seeing one report after I subscribe.

If you create a binding between the two endpoints (for example using zdo bind on) you will receive periodic attribute reports.

Best regards,

Marte

[Jody P Ono]

Hi, Marte:

Thank you very much for all of the excellent help.  I think that we can consider this issue closed!

Best regards,

Jody