Zigbee Long Poll Interval does not follow the set value

Wireshark_poll_interval_ok.pcapng     Wireshark_poll_interval_error.pcapng

We have created a zigbee custom sleepy end device with the base from light switch example. We are able to perform most of the operations successfully.

We have set the following configurations for end device polling.
zb_zdo_pim_set_long_poll_interval(7000)

zb_set_ed_timeout(ED_AGING_TIMEOUT_64MIN)

zb_set_keepalive_timeout(ZB_MILLISECONDS_TO_BEACON_INTERVAL(5000));

The long poll interval is set immediately after network steering and device reboot in default_signal_handler as explained in this link.

It works perfectly when connected to a particular gateway, but not when connected to another gateway. The polling interval is too fast (approx 200ms) in the non-working gateway, be whatever the value set using zb_zdo_pim_set_long_poll_interval..

My query is, Will the gateway influence polling interval? Apart from the above settings is there anything else that should be taken care of? Can you guide me where is that we are going wrong? 

We are using NRF Connect SDK V2.0.0. 

Attached are the Wireshark and PPK logs for both working and non working gateway. 



Parents
  • Hi

    I think I'll need some more details on these gateways you're using. What is the difference between the "particular" working gateway compared to the other one that isn't working? Is this two nRF devices or phones/tablets or some other product? I think gateways can request preferred polling intervals as well, so my guess is that that is what's happening. What are the PPK logs supposed to show here? In what I assume is the non-working one, the poll intervals seemt o be very sporadic, or is the device doing something else than just polling here?

    Best regards,

    Simon

Reply
  • Hi

    I think I'll need some more details on these gateways you're using. What is the difference between the "particular" working gateway compared to the other one that isn't working? Is this two nRF devices or phones/tablets or some other product? I think gateways can request preferred polling intervals as well, so my guess is that that is what's happening. What are the PPK logs supposed to show here? In what I assume is the non-working one, the poll intervals seemt o be very sporadic, or is the device doing something else than just polling here?

    Best regards,

    Simon

Children
  • Hi,

    Thanks for the reply.

    The coordinator that's working is Conbee II with deconz and some other gateways including Alexa has higher polling interval. So all coordinators are third party devices which we don't have any control over.

    Please ignore the power part of ppk screenshot. The intention of ppk is to show the difference in frequency of polling peaks between the two coordinators. This can be validated with the attached wireshark sniffer logs.

    If the coordinator can request preferred polling interval, can the end device override the request and stick to a polling interval? Is there any other possible scenario where we are going wrong? I understand that the information is less, but any help is greatly appreciated.

    The attached screenshots of the sniffer can give an idea about the difference between the two coordinators.


  • Hi, 

    From looking at the sniffer traces, they both seem similar, except in the request for setting the poll interval. Where the connection to Conbee II seems to set the keep alive timeout to false, while it is set to true in the other poll interval request.

    I think that a gateway will always have the last say when it comes to most parameter negotiations, poll intervals included, so it might be that the Alexa doesn't allow/support the poll interval you're suggesting.

    I have asked internally for some of our experts to look at this, but unfortunately it doesn't seem like we can't expect a reply until next week. 

    Best regards,

    Simon

Related