[Update Zigbee SDK] Problem when update from zigbee and thread 4.1.0 to zigbee and thread 4.2.0

RE: [Update Zigbee SDK] Problem when update from zigbee and thread 4.1.0 to zigbee and thread 4.2.0

user97655 — Wed, 01 Jun 2022 02:04:09 GMT

Thanks you for your answer it is good to know this behavior is nothing abnormal.

The support team in Nordic never let me down. Thanks a lot

Best regards

RE: [Update Zigbee SDK] Problem when update from zigbee and thread 4.1.0 to zigbee and thread 4.2.0

user93921 — Tue, 31 May 2022 14:16:52 GMT

Hi Tu,

Here ZB_USE_SLEEP is defined in zb_vendor.h, so this router device will respond to the sleep signal. This can_sleep signal is related to the "Sleepy" End Device but "Sleepy" End Device is more than that.

I got a more detailed explanation from our Zigbee development team:

ZBOSS stack libraries used in v4.2 are built with a slightly different configuration. For example, ZBOSS stack can be put to sleep for every role, previously it was limited to End Devices only (End Devices are linked with _ed library variant and previously only this library was compiled with ZB_USE_SLEEP enabled).

In principle, this can_sleep signal is used to inform that the stack has nothing to do for some time. ZBOSS has its own scheduler so it can calculate for how long it can "sleep". It's especially useful in NCS where there are other threads that may need some CPU time but have lower priority than zboss-thread.

"Sleepy mode for End Device" is more than that. It changes how the device behaves in the network.As End Device, the device sends Data requests to the parent device with a fixed interval:

When it's "sleepy", the device turns on its radio on regular basis to ask parent device about pending packets. Radio is turned off when there no more packets to receive or send.

When it's not "sleepy", the radio is always on so the device can receive packets.

"Sleepy" End Device is meant for battery-powered applications because it's optimized for low power consumption - radio is off for most of the time and application usually has little to process so the CPU can be halted (WFE/WFI to be precise) for longer periods of time.

Best regards,

Charlie

RE: [Update Zigbee SDK] Problem when update from zigbee and thread 4.1.0 to zigbee and thread 4.2.0

user97655 — Tue, 31 May 2022 00:53:43 GMT

Hi Charlie,

Well in the light bulb example, the device is a router so it will not process that signal but will put it in default case. If I remember correctly unless the device plays the role of a end device, it will never handle that signal.

#ifdef ZB_USE_SLEEP
        case ZB_COMMON_SIGNAL_CAN_SLEEP:
            /* Zigbee stack can enter sleep state.
             * If the application wants to proceed, it should call zb_sleep_now() function.
             *
             * Note: if the application shares some resources between Zigbee stack and other tasks/contexts,
             *       device disabling should be overwritten by implementing one of the weak functions inside zb_nrf52840_common.c.
             */
            zb_sleep_now();
            break;
#endif

As you can see the handle of this signal is only enable with ZB_USE_SLEEP is defined and that macro is only there if the device is ED as in the code below

#ifdef ZB_ED_ROLE
#define ZB_USE_SLEEP
#endif

So It does not really explain my question which is why in my void zboss_signal_handler(zb_bufid_t bufid) if I put the log there it will show that there are signal 22(ZB_SIGNAL_CAN_SLEEP) coming repeatedly, but when the signal is handled by zigbee_default_signal_handler , somehow the defaults handler ignore it.

I want to know how to do it just to verify if this behavior is normal and if it will have any effect on the overall performance of the system.

Looking forward to hearing from you,

Best regards,

RE: [Update Zigbee SDK] Problem when update from zigbee and thread 4.1.0 to zigbee and thread 4.2.0

user93921 — Mon, 30 May 2022 14:17:18 GMT

Hi Tu,

Shouldn't this singal be processed by the following codes in zigbee_default_signal_handler function?

        case ZB_COMMON_SIGNAL_CAN_SLEEP:
        //NRF_LOG_INFO("zboss_signal_handler signal %d", sig);
            /* Zigbee stack can enter sleep state.
             * If the application wants to proceed, it should call zb_sleep_now() function.
             *
             * Note: if the application shares some resources between Zigbee stack and other tasks/contexts,
             *       device disabling should be overwritten by implementing one of the weak functions inside zb_nrf52840_common.c.
             */
            zb_sleep_now();
            break;

Best regards,

Charlie

RE: [Update Zigbee SDK] Problem when update from zigbee and thread 4.1.0 to zigbee and thread 4.2.0

user97655 — Thu, 26 May 2022 11:10:26 GMT

Hi Charlie

So, I have some update on the problem. So the problem is that I have this

void zboss_signal_handler(zb_bufid_t bufid)
{
    zb_zdo_app_signal_hdr_t *p_sg_p = NULL;
    zb_zdo_app_signal_type_t sig = zb_get_app_signal(bufid, &p_sg_p);
    zb_ret_t status = ZB_GET_APP_SIGNAL_STATUS(bufid);
    /*NRF_LOG_INFO("zboss_signal_handler signal %d", sig);*/
    switch (sig) {
        default:
            ZB_ERROR_CHECK(zigbee_default_signal_handler(bufid));
        break;
    }
}

If I uncomment the Log in this funtion it will pop up repeatedly signal 22. But the weird thing is that in the zigbee_default_signal_handler(bufid), when signal 22 hit, it will go to default like in this code.

        default:
            /* Unimplemented signal. For more information see: zb_zdo_app_signal_type_e and zb_ret_e. */
            NRF_LOG_INFO("Unimplemented signal (signal: %d, status: %d)", sig, status);
            break;

But I can never see the log pop up which means that The code in default signal handler has do some thing to filter out the signal. But still I can not figure out how to achieve the same outcome in the self implemented zboss_signal_handler

I also test with the devkit pca10100 and have the same outcome. I also attach the code for you to check it out

test-devzone.nordicsemi.com/.../3884.light_5F00_bulb.zip

Thank you

Best regards,

RE: [Update Zigbee SDK] Problem when update from zigbee and thread 4.1.0 to zigbee and thread 4.2.0

user97655 — Wed, 25 May 2022 02:59:47 GMT

Thank you for your support I will attach the SDK config files and makefile for you to check if there are any configuration should be made

test-devzone.nordicsemi.com/.../0726.app_5F00_config.h test-devzone.nordicsemi.com/.../1307.sdk_5F00_config.h test-devzone.nordicsemi.com/.../8244.Makefile.txt

RE: [Update Zigbee SDK] Problem when update from zigbee and thread 4.1.0 to zigbee and thread 4.2.0

user93921 — Tue, 24 May 2022 11:39:44 GMT

Ok, Is it possible some specific modification in your application triggered this issue? I will also check with our development team for the possible cause. Let's keep each other updated.

Best regards,

Charlie

RE: [Update Zigbee SDK] Problem when update from zigbee and thread 4.1.0 to zigbee and thread 4.2.0

user97655 — Tue, 24 May 2022 02:39:41 GMT

Well, I have tried it and no I do not have the same problem.

RE: [Update Zigbee SDK] Problem when update from zigbee and thread 4.1.0 to zigbee and thread 4.2.0

user93921 — Mon, 23 May 2022 12:28:32 GMT

Hi Tu,

Have you experienced the same issue when you test the original ZigBee light bulb sample on nRF52840DK?

Best regards,

Charlie