[Zigbee] end device does not send End Device Timeout Request keepalive

[chris.t]

Hello, I am working with 2 nRF52840 dk's and a Conbee ii.

The DK's are using nRF5 SDK for Thread and Zigbee 4.1.0.

DK 1 is running the CLI example.

DK 2 is running the multi-sensor example, with

zb_set_rx_on_when_idle(ZB_TRUE);

.

From a sniffer capture, the CLI example only supports MAC data poll keepalive, and it works as intended with the multi-sensor example, sending out data poll requests every ~3 seconds.

However when connecting the multi-sensor to the Conbee ii, the sniffer shows it supporting both MAC data poll keepalive and End Device Timeout Request keepalive, but the multi-sensor never sends out a Timeout Request keepalive and eventually ages out if left to run long enough.

Please see the attached capture of the multi-sensor joining the Conbee.

Multi_sensor_Conbee_ii_join.pcapng

I have read over the Zigbee programming principles section on end device keep alive as well as this similar tickets.

Is there something that is missing from the multi-sensor example that would allow the use ED timeout requests when supported by the ZC/ZR?

Regards,
Chris

[Jørgen Holmefjord]

Hi,

From the sniffer trace, it looks like the Conbee II reports as a legacy device (i.e. not a Zigbee 3.0 device/Zigbee specification above r21).

The End device timeout protocol was first added to the specification in r21, so this may not be supported by the coordinator. I'm not sure what happens in your sniffer trace, but it looks like the device sends a new "Permit Join Request" in frame 126, then stops sending more packets after this.

Can you try to add zb_bdb_set_legacy_device_support(1); to the Multisensor example, and capture a new sniffer trace to see if this makes any difference?

Best regards,
Jørgen

[Jørgen Holmefjord]

Hi,

chris.t said:

Where from the trace can you determine that the Conbee is reporting as a legacy device?

This can be seen from the "Stack Compliance Revision" flag in the Coordinators "Node descriptor response":

According to the R21/R22 specifications, this field should be set to the spec revision (21/22). On legacy devices (pre-r21), the field is reserved and set to 0's.

Are you using the latest version of the firmware/software for the Conbee 2?

chris.t said:

Would it be possible to enable Timeout request Keepalive in addition to MAC data poll on the CLI example, perhaps testing with that would be easier?

The Zigbee CLI Agent example does not support the End Device role, so I'm not sure how trivial it would be to add support for this.

Best regards,
Jørgen

[chris.t]

That's good to know!

Yes latest fw on the Conbee 2 and sw on the host computer.

Reported compliance rev aside, the Conbee responding to end device timeout requests should be enough for the Multisensor to start sending timeout requests, correct?

When I say, "enable Timeout request keepalive on the Zigbee CLI Agent", I mean, in a coordinator role, to respond to the Multisensor as supporting both methods like the Conbee:

Thanks,

Chris

[chris.t]

Hi Jørgen,

Was there any update on this?

Regards,

Chris

[Jørgen Holmefjord]

Hi Chris,

Sorry for not getting back to you sooner regarding this issue. I had to consult our Zigbee team to get help with how to enable support for "End Device Timeout Request Keepalive" in Coordinator/router role.

Unfortunately, I could not find any API to enable this in nRF5 SDK for Thread and Zigbee v4.1.0. In nRF Connect SDK, there is additional API to enable this: zb_set_keepalive_mode(). By setting this to ED_TIMEOUT_REQUEST_KEEPALIVE or BOTH_KEEPALIVE_METHODS, the nRF Zigbee Coordinator/router will report True to supporting "End Device Timeout Request Keepalive". I tested this with the Zigbee Shell sample in nRF Connect SDK v1.8.0, by calling this function when the coordinator role is set:

zb_set_keepalive_mode(ED_TIMEOUT_REQUEST_KEEPALIVE);

Unfortunately, it seems that the multi-sensor example in nRF5 SDK for Thread and Zigbee v4.1.0 does not send timeout requests with the Coordinator running on a Nordic chip either.

Next, I tested it against the Zigbee Light Switch sample from nRF Connnect SDK v1.8.0, and this seems to send the timeout requests as expected.

Attaching sniffer trace: NCS_Zigbee_ED_timeout_keepalive_request.pcapng

This leads me to believe that there is a bug in the Zigbee stack in the old SDK release, which makes the ED timeout keepalive requests not working properly.

Have you considered moving your development to nRF Connect SDK? This is the main development platform for our products, and where all new features will be released. nRF5 SDK is in maintenance mode, which means bugfix releases may be coming, but likely not with a high frequency.

If you intend to stay with nRF5 SDK, this issue should be resolved in next nRF5 SDK for Thread and Zigbee release. You can contact your regional sales manager for details about when that will become available.

Best regards,
Jørgen