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,

Yes, I used our 802.15.4 sniffer and Wireshark. I suspect that there might be a bug or something missing in the actual SDK. I tested with unmodified versions of the network coordinator and light bulb samples from the SDK on a nRF52840 DK as well, only adding CONFIG_ZIGBEE_SHELL=y to configure Zigbee shell, and I saw the same there. 

After some more digging I have found out what happens, but not exactly why. The CLI endpoint does not get registered, causing the endpoint handler, cli_agent_ep_handler_attr, to never be called. This seems to be true for all the CLI handlers in Zigbee shell (attr, generic_cmd, report, ping), and not just the one for attribute read/write. This handler is used to intercept incoming frames, so the way it is supposed to work is that when the read attr command is constructed and sent an alarm is scheduled. When the device receives a response, e.g. read attributes response, the endpoint handler should be called, and the alarm is cancelled inside the endpoint handler. Since the handler is never called the alarm is not cancelled, and it says that it times out even though the response was actually received. 

In the Zigbee shell sample the CLI endpoint was registered and the endpoint handler worked as expected. I have not been able to figure out why it works in this example and not when configuring Zigbee shell in the other examples yet, as the latter worked in earlier versions of nRF Connect SDK. I have asked the developers about this, whether it is a bug somewhere, or if there is just some additional configuration or code that is needed in order to enable Zigbee shell in v1.9.0. I will update you when I get a response or if I find something else.

Best regards,

Marte

[Jody P Ono]

Hi, Marte:

Thank you for all of your hard work!  I look forward to whatever you and the Nordic developers discover and hope that a fix is possible.

Regarding your Wireshark capture, are you using some special kind of interpreting plugin such that details of the ZCL command (like profile ID and endpoint) are shown in your capture?  When I do a capture, it does not display that kind of detail.

Best regards,

Jody

[Marte Myrvold]

Hi,

It seems to have been a misunderstanding on my part. I thought that the CLI endpoint is a different endpoint than the application endpoint, and that you could set it to whatever valid endpoint value you wanted. However, it is actually the same endpoint as the application endpoint. So to fix this, all you need to do is to set CONFIG_ZIGBEE_SHELL_ENDPOINT in prj.conf to the same as ZIGBEE_COORDINATOR_ENDPOINT, which should be 10 unless you have changed in your code.

I also realized that the prj.conf that I shared earlier does not enable logging on the dongle. I was able to fix this by removing the configuration CONFIG_NCS_SAMPLES_DEFAULTS and setting CONFIG_LOG=y.

Best regards,

Marte

[Jody P Ono]

Hi, Marte:

This is great news.  I will modify the firmware and test tomorrow (er, today, I guess?).  Anyway, it's really late (or early) here and I need to get some sleep.  Thanks again for your exemplary (and quick) problem solving!  I'll report back with my results.

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