This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

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?

Parents
  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • Hi, Marte:

    The network key is: 41a30653e935ab6f531655f4c4c841d0.

    Best regards,

    Jody

Reply Children
  • 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

  • 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

  • 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

  • Hi, Marte:

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

    Best regards,

    Jody

Related