Confused about polling interval

[Unitware]

I have been studying the power consumption of a prototype and observe that the end device is polling very frequently.

The data request polling is backing off for a while to about every 3 seconds, but suddenly (efter 15 seconds or so) the device starts polling every 200 ms or so. 

If I disable the turbo polling mode then the polling will be every 500ms from start.

I'm wondering if you can help me put with some pointers to there I should start looking. 
My goal is to poll once every ten seconds or so, and maybe a increased polling rate after any device activity to fetch pending commands.  

My project is based on the multiprotocol doorlock example in sdk 4.0.0 and I am using SDK 16.0 to fill in the gaps to make it compile. Changes that I have meade includes moving the application out of the sdk-directory structure and I am using make and gcc to build it.

A log from wireshark: 

Power measurement:

[Marjeris Romero]

Hi,

Sorry for the late reply. The default value for long poll interval is 5 seconds. To change the data polling intervall you need to use zb_zdo_pim_set_long_poll_interval(zb_time_t ms).

Best regards,

Marjeris

[Unitware]

An update.

using  zb_zdo_pim_set_long_poll_interval(zb_time_t ms) works if I call it after a while but I have not been able to call it in a proper way after joining the network.

From the manual:

• A preferable way to change the Long Poll interval if the Poll Control cluster is not defined. Else the Poll Control cluster API should be used to set the Long Poll Interval attribute.
• Long Poll interval configuration should be done after the join procedure because during join the Long Poll interval will be set to the default value ZB_PIM_DEFAULT_LONG_POLL_INTERVAL.

What I see after bootup and joined network is a few "turbo polls" with increasing data request intervals. but after 15 seconds the interval is set to 200ms and thus consuming a lot of battery.

If I call zb_zdo_pim_set_long_poll_interval manually then it will take immediate effect but I do not know how to do it in a good way without guessing with timers. 

What am I missing here?

[Marjeris Romero]

Hi,

Sorry for the late reply. I did some testing and for me it works when I call zb_zdo_pim_set_long_poll_interval(10000) right after steering and reboot (status == RET_OK), can you try that? Something like this:

switch(sig)
    {
        case ZB_BDB_SIGNAL_DEVICE_REBOOT:
            /* fall-through */
        case ZB_BDB_SIGNAL_STEERING:
            /* Call default signal handler. */
            ZB_ERROR_CHECK(zigbee_default_signal_handler(bufid));
            if (status == RET_OK)
            {
                /* Check the light device address */
                if (m_device_ctx.bulb_params.short_addr == 0xFFFF)
                {
                    zb_err_code = ZB_SCHEDULE_APP_ALARM(find_light_bulb, bufid, MATCH_DESC_REQ_START_DELAY);
                    ZB_ERROR_CHECK(zb_err_code);
                    zb_err_code = ZB_SCHEDULE_APP_ALARM(find_light_bulb_timeout, 0, MATCH_DESC_REQ_TIMEOUT);
                    ZB_ERROR_CHECK(zb_err_code);
                    bufid = 0; // Do not free buffer - it will be reused by find_light_bulb callback
                }
                zb_zdo_pim_set_long_poll_interval(10000);
            }
            break;
        default:
            /* Call default signal handler. */
            ZB_ERROR_CHECK(zigbee_default_signal_handler(bufid));
            break;
    }

Also perhaps also check the keepalive timeout you are using (zb_set_keepalive_timeout)?

Best regards,

Marjeris

[Unitware]

hi, I can check this in a few weeks as I'm on vacation now, thanks for looking into it. I can see that I am not calling the default handler, that may have made things worse for me. But I'll get back when I have the things at hand.

[Unitware]

Hi, the missing ```ZB_ERROR_CHECK(zigbee_default_signal_handler(bufid));```in the zboss_signal_handler demo code from 4.0.0 was causing this and some other errors. I'll have a look at the diff and see if I can clean up some more. Thanks for your help!