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

[Jody P Ono]

Hi, Marte:

Your changes to the prj.conf file work very well!  I am finding another issue, though.  I am unable to subscribe to any reportable attributes with "zcl subscribe on".  I keep getting a "Status 141" error, which is "Invalid Type".  I am using the same type that is returned when I query the same attribute with "zcl attr read".  I have tried the CurrentHue and CurrentX attributes of the Color Control cluster (0x0300) on a Philips Hue bulb.  These are reportable attributes per the Zigbee specification.  Can you please assist?

Best regards,

Jody

[Marte Myrvold]

Hi Jody,

Can you try using 0xc05e as profile ID instead? This is the profile ID for Zigbee Link Link, which I know some Zigbee light bulbs use instead of Home Automation.

Best regards,

Marte

[Jody P Ono]

Hi, Marte:

I get the same error, "Unable to configure attribute 0 reporting. Status: 141".

Best regards,

Jody

[Marte Myrvold]

Hi Jody,

Can you show me what the command you are sending looks like? Are you able to get a sniffer log of this that you can upload here for me to look at?

Best regards,

Marte

[Jody P Ono]

Hi, Marte:

Here's my command window:

uart:~$ bdb start
Started router
Done
[00:00:11.535,461] <inf> zigbee_app_utils: Production configuration is not present or invalid (status: -1)
[00:00:11.536,193] <inf> zigbee_app_utils: Zigbee stack initialized
[00:00:11.572,082] <inf> zigbee_app_utils: Unimplemented signal (signal: 54, status: 0)
[00:00:11.576,141] <inf> app: Start network steering
[00:00:12.049,743] <inf> zigbee_app_utils: Unimplemented signal (signal: 54, status: 0)
[00:00:12.053,192] <inf> app: Network steering started
[00:01:00.393,127] <inf> zigbee_app_utils: Device authorization event received (short: 0x3e2d, long: 001788010b6dec20, authorization type: 1, authorization status: 0)
[00:01:04.344,482] <inf> app: New device commissioned or rejoined (short: 0x3e2d)
[00:01:04.344,543] <inf> app: Joining period extended.
[00:01:10.199,310] <inf> zigbee_app_utils: Unimplemented signal (signal: 50, status: 0)
[00:03:14.206,390] <inf> zigbee_app_utils: Unimplemented signal (signal: 54, status: 0)
[00:04:06.627,136] <inf> app: Network steering finished
uart:~$ zcl cmd 3e2d 11 0x0300 0x00 -l a9000000
Done
uart:~$ zcl cmd 3e2d 11 0x0300 0x00 -l 64000000
Done
uart:~$ zcl cmd 3e2d 11 0x0006 0x02
Done
uart:~$ zcl subscribe on 3e2d 11 0x0300 0x0104 0x00 20 2 5
Error: Unable to configure attribute 0 reporting. Status: 141

Error: One or more attributes reporting were not configured successfully[00:08:16.009,094] <inf> zigbee.eprxzcl: Received ZCL command (0): src_addr=0x3e2d(sho~
uart:~$

And here's my Wireshark capture.

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