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

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

Jørgen Holmefjord — Thu, 17 Feb 2022 15:27:37 GMT

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: devzone.nordicsemi.com/.../NCS_5F00_Zigbee_5F00_ED_5F00_timeout_5F00_keepalive_5F00_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

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

chris.t — Thu, 27 Jan 2022 16:20:21 GMT

Hi Jørgen,

Was there any update on this?

Regards,

Chris

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

chris.t — Thu, 20 Jan 2022 16:44:19 GMT

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

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

Jørgen Holmefjord — Thu, 20 Jan 2022 14:19:06 GMT

Hi,

[quote user="chris.t"]Where from the trace can you determine that the Conbee is reporting as a legacy device?[/quote]

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?

[quote user="chris.t"]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?[/quote]

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

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

chris.t — Mon, 17 Jan 2022 16:47:28 GMT

Hello,

Where from the trace can you determine that the Conbee is reporting as a legacy device? It's product page advertised it as Zigbee 3.0.

devzone.nordicsemi.com/.../legacy_5F00_enabled.pcapng

The behavior looks the same with legacy device support on the Multisensor example enabled. At frame 144, I restarted the Multsensor example and it did rejoin the network but still no keep alive messages even though the Conbee responded with supporting both types.

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?

Thanks,

Chris

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

Jørgen Holmefjord — Mon, 17 Jan 2022 16:18:52 GMT

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