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] end device does not send End Device Timeout Request keepalive

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

  • 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

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

    legacy_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

  • 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

  • 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

  • Hi Jørgen,

    Was there any update on this?

    Regards,

    Chris

Related