nrf54l10 zigbee R23 sleepy end device behavior

RE: nrf54l10 zigbee R23 sleepy end device behavior

Elfving — Thu, 13 Nov 2025 15:09:32 GMT

I see. It has internally been suggested that it should be added to ZB_BDB_SIGNAL_TC_REJOIN_DONE as well, didn't think about ZB_BDB_SIGNAL_DEVICE_REBOOT yet though. Like you say, it might be some other signal we've overlooked here this far.

It has been reported to our ZBOSS provider, like you say it will likely result in a fix in the driver.

Regards,

Elfving

RE: nrf54l10 zigbee R23 sleepy end device behavior

hyojoon — Tue, 11 Nov 2025 22:43:45 GMT

When system gets ZB_BDB_SIGNAL_TC_REJOIN_DONE then current still does not drop

I: zboss_signal_handler sig : 58
I: TC Rejoin was not successful (status: -1)
I: start_network_rejoin ZB_JOINED 0 wait_for_user_input 1 is_rejoin_procedure_started 1
I: rejoin_the_network Network rejoin procedure stopped as scheduled.

ZB_BDB_SIGNAL_STEERING

ZB_BDB_SIGNAL_DEVICE_REBOOT

ZB_BDB_SIGNAL_TC_REJOIN_DONE

It works when I add it to those three signals.
Please check with the R&D team if there are any other signals I should add it to.

Also, I think this shouldn’t be handled through the signal but rather at the driver level.
Is there any way to handle it within the driver or SDK itself, similar to how it was done in R22?

RE: nrf54l10 zigbee R23 sleepy end device behavior

Elfving — Tue, 11 Nov 2025 12:19:14 GMT

Hmm. Making this change should be enough for it to work with eg. ncs-zigbee\samples\light_switch\ sample.

...
    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 (bulb_ctx.short_addr == 0xFFFF) {
                k_timer_start(&bulb_ctx.find_alarm,
                          MATCH_DESC_REQ_START_DELAY,
                          MATCH_DESC_REQ_TIMEOUT);
            }
        }
        ZB_TRANSCEIVER_SET_RX_ON_OFF(zb_get_rx_on_when_idle());
        break;
...

it can be added to the zigbee_default_signal_handler as well, but both should work. Could you try adding it there though and see if it makes a difference on your side?

However the call is meaningless for non-ZED devices (zb_get_rx_on_when_idle() is always true), so having it in the specific sample for ZED is enough or it can be added to the default signal handler within

#if defined CONFIG_ZIGBEE_ROLE_END_DEVICE

Regards,

Elfving

RE: nrf54l10 zigbee R23 sleepy end device behavior

hyojoon — Mon, 10 Nov 2025 22:31:41 GMT

void zboss_signal_handler(zb_bufid_t bufid)

{

zb_zdo_app_signal_hdr_t *sig_hndler = NULL;

zb_zdo_app_signal_type_t sig = zb_get_app_signal(bufid, &sig_hndler);

#ifdef CONFIG_WINDOWS_ITP

zb_ret_t status = ZB_GET_APP_SIGNAL_STATUS(bufid);

#endif

#ifdef CONFIG_ZIGBEE_FOTA

/* Pass signal to the OTA client implementation. */

ias_zigbee_fota_signal_handler(bufid);

#endif /* CONFIG_ZIGBEE_FOTA */

if(sig != 22) {

LOG_INF("zboss_signal_handler sig : %d", sig);

}

switch (sig) {

case ZB_BDB_SIGNAL_DEVICE_REBOOT:

__fallthrough;

case ZB_BDB_SIGNAL_STEERING:

ZB_ERROR_CHECK(zigbee_default_signal_handler(bufid));

ZB_TRANSCEIVER_SET_RX_ON_OFF(zb_get_rx_on_when_idle());

break;

Ultimately, if the connection fails, the current still does not drop.

RE: nrf54l10 zigbee R23 sleepy end device behavior

hyojoon — Mon, 10 Nov 2025 00:24:58 GMT

Hi Elfving

As you suggested, I added the code, but the issue remains the same

The image below shows the behavior for the R22 version, not the add-on.
As you can see, when the channel is not found, the current drops close to sleep mode levels.

This is the behavior I want.
Currently, the R23 add-on does not operate this way.

RE: nrf54l10 zigbee R23 sleepy end device behavior

Elfving — Fri, 07 Nov 2025 14:50:53 GMT

Hi, and I am so sorry about the wait,

The R&D team was finally able to reproduce this. And have gotten a workaround:

at the end of ZB_BDB_SIGNAL_STEERING case on the signal handler, add:

ZB_TRANSCEIVER_SET_RX_ON_OFF(zb_get_rx_on_when_idle());

Could you try this?

Regards,

Elfving

RE: nrf54l10 zigbee R23 sleepy end device behavior

Elfving — Tue, 14 Oct 2025 14:03:55 GMT

Ah sorry about the misunderstanding there. I figured the focus of the question was demonstrating the device infact going to sleep, or simply make the current measurements low enough. I am familiar with the device going to sleep after finding a network, and that it would typically need a network to do so. So to first demonstrate that something default worked on your side first, I figured we could try a DK and get it to find a network. To me, getting a commissioning failure first wouldn't be the easiest way to show that. Though if doing it with a commissioning failure is what you need that changes things.

I'll ask the relevant R&D team, and get back to you.

Regards,

Elfving

RE: nrf54l10 zigbee R23 sleepy end device behavior

hyojoon — Sun, 12 Oct 2025 22:09:04 GMT

Is my question incorrect?
I clearly mentioned that the device is not connected to a network.
I am asking why the current consumption remains high after a commissioning failure, and
how to reduce the current in that situation.

The same issue occurs with the nRF54L10 DK board using the sample code.
In other words, after a network join failure, the current does not drop,
and I am asking how to reduce it.

RE: nrf54l10 zigbee R23 sleepy end device behavior

Elfving — Fri, 03 Oct 2025 13:58:39 GMT

That is odd. Are you seeing the same thing with a DK? If you have one on hand?

Are you connected to a Zigbee network with it? Besides that I think the only thing you'd need with the sample is to hold Button 2 while it is booting.

Regards,

Elfving

RE: nrf54l10 zigbee R23 sleepy end device behavior

hyojoon — Mon, 29 Sep 2025 02:43:12 GMT

Yes, the light switch example shows the same behavior—the current does not drop either.

RE: nrf54l10 zigbee R23 sleepy end device behavior

Elfving — Tue, 23 Sep 2025 12:45:55 GMT

Sorry about the wait Hyojoon,

[quote user="hyojoon"]The part you mentioned has already been applied.
[/quote]

Ah right. In that case I do not see that you are missing anything. Though it might be that you do actually have to be connected to a network first, and that start_network_rejoin() is mainly for when you were already connected. I am uncertain about that.

Are you seeing the same issue with something like the Zigbee: Light switch sample, which is meant to be able to demonstrate the sleeping behavior?

Regards,

Elfving

RE: nrf54l10 zigbee R23 sleepy end device behavior

hyojoon — Mon, 22 Sep 2025 22:39:17 GMT

Is there really no one who can tell me about this?

RE: nrf54l10 zigbee R23 sleepy end device behavior

hyojoon — Wed, 17 Sep 2025 21:55:29 GMT

Hi Elfving

void zigbee_configure_sleepy_behavior(bool enable)
{
	if (enable) {
		zb_set_rx_on_when_idle(ZB_FALSE);
		LOG_INF("Enabled sleepy end device behavior.");
	} else {
		zb_set_rx_on_when_idle(ZB_TRUE);
		LOG_INF("Disabling sleepy end device behavior.");
	}
}

The part you mentioned has already been applied.
So when the Zigbee device successfully joins the network, it draws an average of about 14 µA.
What I mean is that in the current add-on SDK, if the device fails to join the network after start_join_network, even when stop_join_network is called, the current still does not drop.

Best.
Hyojoon

RE: nrf54l10 zigbee R23 sleepy end device behavior

Elfving — Wed, 17 Sep 2025 14:50:50 GMT

Hi,

To start off I just want to mention that the case is open. If that was not your intention I can make it private.

To reduce power consumption, then making it a sleepy end device (SED) is a good idea (I see also that there are more general power consumption tips here), though I believe zb_set_rx_on_when_idle(ZB_FALSE) is how it is supposed to be done in the add-on SDK. Could you try this?

Regards,

Elfving