Zigbee CLI example can't interact with some clusters and Sleepy End Devices

[SamTheMan]

Hello all,

I'm interacting with some nodes in a test network:

setup: 10x nrf52840 DK (PCA10056) boards loaded with the following software.

1x Coordinator (Zigbee CLI Agent example)

3x Routers (Zigbee Light Bulb Example)

6x End Devices (Zigbee Light Switch)

 

I've made it on the End devices so, that if a certain attribute gets written that the node's LED2 will go on for a few seconds.

(Zigbee CLI Reference --> zcl attr write & zcl attr read)

 

However I face 2 problems.

1) Certain commands aren't working using the CLI.

• Routers accept "zcl attr write" & "zcl attr read" functions targeting all in_clusters
• Routers accept "zcl cmd" commands targeting cluster 0x0006
• Routers don't accept "zcl cmd" commands targeting cluster 0x0003 and 0x0004

2) Sleepy End Devices can't be interacted with.

• Non-sleeping End Devices can be interacted with. But i'd like to use the sleepy behaviour to save power.

Is there a way that I can interact with Sleepy End devices using the CLI example? 

Can I make my Routers accept "zcl cmd" commands targeting at least the 0x0003 and 0x0004 clusters?

[SamTheMan]

2) Sleepy End Devices can't be interacted with has been solved.

The Sleepy End Devices couldn't reach 2 meters away from my routers. Likely a battery related issue.

Non-sleeping End Devices had better connectivity.

[Marte Myrvold]

Hi,

Routers don't accept "zcl cmd" commands targeting cluster 0x0003 and 0x0004

Could you please specify more how you are testing this? How do you know that the routers do not accept commands from these clusters, and what commands are you sending? I tried to reproduce your issue using the same examples, but I did not have any issue sending ZCL commands from the Identify and Groups clusters to the light bulb. Using a sniffer to look at the network traffic I saw the light bulb sent the expected responses back after receiving the commands. 

Sleepy End Devices can't be interacted with.

 Is this when the device is in sleep mode? When Sleepy End Devices (SED) are in sleep mode the radio is turned off, so you cannot communicate with a SED during sleep. If you try to send a packet to a SED while it is sleeping, the parent will not forward this packet to the device. It will instead keep the packet for some time, and when the SED wakes up it will poll it's parent for packets waiting for it. So you should be able to send and receive packets from SEDs, but you cannot expect the SED to receive the packet immediately.

Best regards,

Marte

[SamTheMan]

Hi Marte,

I have setup my network as described in my original post.

Marte Myrvold said:

Routers don't accept "zcl cmd" commands targeting cluster 0x0003 and 0x0004

Could you please specify more how you are testing this? How do you know that the routers do not accept commands from these clusters, and what commands are you sending?

I'm reading out the logging through TeraTerm.

Baud Rate 1000000 on my Routers and End devices and Baud Rate 115200 on my CLI/Coordinator devices.

None of the ZCL CMD commands from 0x0003 and 0x0004 sended to my nodes return a message in the logging.

Also the command to put a node in identifying mode doesn't increase the identifying time.

I can read the Identifying Time of individual nodes using the ZCL ATTR READ method and they return 0.

For testing purposes it is possible for me to artificially increase the Identifying Time through the ZCL ATTR WRITE method, but I can imagine this isn't the intended way of doing things.

Marte Myrvold said:

Sleepy End Devices can't be interacted with.

 Is this when the device is in sleep mode?

Yes, but this works now. It was a range and timing-related thing. ( I just putted the Sleepy End Devices closer to the Routers and waited roughly 500ms before sending a new command to make sure everything had time to process )

Cheers,

Sam

[Marte Myrvold]

Hi Sam,

SamTheMan said:

None of the ZCL CMD commands from 0x0003 and 0x0004 sended to my nodes return a message in the logging.

 This does not necessarily mean that the commands are not received or handled by the router, but it could simply mean that there is no logging for the command in the example. The CLI agent did not print logs when I sent the commands to the router, but I could see in the sniffer log that the router did receive and respond to the commands. Can you get a sniffer log of the network traffic when you are sending the packets? If you have a nRF52840 Dongle or DK you can use nRF Sniffer for 802.15.4. Please share the log as a pcap file so I can look at it.

SamTheMan said:

Also the command to put a node in identifying mode doesn't increase the identifying time.

 What does the command you are sending look like? Are you sending it to the correct address and endpoint? You should be able to change the IdentifyTime attribute using the Identify command. It should not be necessary to use the generic write attributes command. I tested with all commands in the Identify cluster, and I was able to change IdentifyTime, and verify that it was changed with the Identify Query command and read attributes command. 

This is the command I used to put the device in Identify mode for 120 seconds:

zcl cmd 0b010e1585785ce7 10 3 0 -l 0x78

Where the arguments were as follows:

zcl cmd <dst_addr> <endpoint> <cluster> <command_id> -l <payload>

Best regards,

Marte

[SamTheMan]

Ah, so uh... everything is working as intended haha 

I used the wrong command, as during my first few tests the command from the tutorial wasn't working due to what i can only assume to be a setup mistake. So I threw that one away and tried to use one from the Zigbee Cluster Library Specification. But I didn't use the correct syntax or didn't know that it was working because I should've used a Sniffer instead of the TeraTerm log terminal for confirmation.

 

The following commands worked to put my nodes in identifying mode for 5 seconds and with a code adjustement I can see LED2 light up when it's in identifying mode.

Put in identifying mode

zcl cmd <dst_addr> <endpoint> <cluster> <command_id> -l <payload>

Light Switch --> zcl cmd 0x22C1 1 3 0 -l 0x05

Light Bulb --> zcl cmd 0xDF29 10 3 0 -l 0x05

 

Minor code adjustment in main.c's main loop to put LED2 ON while identifying and OFF if not identifying

/*SELF INSERTED CODE
  Turn LED2 on if identify_time > 0; Else turn LED2 off*/
if (m_attr_identify_time > 0) {
  bsp_board_led_on(1);
}
else{
  bsp_board_led_off(1);
}