Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

theorlangur — Thu, 05 Mar 2026 16:33:09 GMT

awesome!

Thanks

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

Edvin — Thu, 05 Mar 2026 14:15:00 GMT

You can use this one:
devzone.nordicsemi.com/.../libzboss.a

Best regards,

Edvin

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

Edvin — Thu, 05 Mar 2026 13:26:19 GMT

Let me check with our Zigbee team.

Regarding roadmap details, I don't know, and we typically don't share that on DevZone. You can reach out to our Regional Sales Manager for your area to see if they have any details. If you need their contact information, please send me a direct message here on DevZone, and include a link to this ticket, together with the country you are located.

Best regards,

Edvin

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

theorlangur — Thu, 05 Mar 2026 09:19:05 GMT

got it

would it be possible for you to provide also a router (non-ed) version of the zboss library with a fix and without traces?

making my device an End Device was rather a forced move while attempting to troubleshoot the network issues at the beginning

is there a rough ETA on the next ncs-zigbee release? are we talking about weeks or months or more..?

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

Edvin — Thu, 05 Mar 2026 09:05:50 GMT

[quote user="theorlangur"]

Should I mark your post as the 'answer'? Or should I wait until it's published as part of the next ncs-zigbee release and make a post referencing that release?

[/quote]

That is up to you.

I can confirm that the bug was a generic Zboss library, but it has been fixed ipstream, so the fix will be included in the next zigbee release from us.

Whether those other targets are affected, I don't know. It depends on what library, specifically they are using. Not sure if they are all using the exact same code base, or if Zboss delivers slightly different versions to the different vendors.

Best regards,

Edvin

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

theorlangur — Wed, 04 Mar 2026 17:38:33 GMT

I can confirm that this library version works as expected.

Should I mark your post as the 'answer'? Or should I wait until it's published as part of the next ncs-zigbee release and make a post referencing that release?

Unrelated question: was the bug in the generic part of ZBOSS library or Nordic-specific? In other words: would zigbee-capable MCUs from Espressif (like esp32-c6, esp32-h2) suffer from the same issue since AFAIK they are also using ZBOSS as their Zigbee stack implementation?

Thanks!

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

Edvin — Wed, 04 Mar 2026 14:29:38 GMT

That is great news. See if this one works as expected.
devzone.nordicsemi.com/.../libzboss.ed.no_2D00_traces.zip

I will get back to you after discussing with the Zigbee team, but I believe this will be patched in the next version of the Zigbee addon.

But let me know whether this one works as expected or not first.

Best regards,

Edvin

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

theorlangur — Tue, 03 Mar 2026 18:08:09 GMT

Good news 🙂

this version of the fix has worked. I could see that my device has resolved the address once and then used the resolution result to send the on/off commands.

I've also tried it with a different target device with an on/off cluster that was also failing before ('ff:fe' in EUI64 as well) and there it has worked as well.

This trace is for the IKEA smart lamp:

devzone.nordicsemi.com/.../zboss_5F00_trace3.bin

This trace is for some noname smart socket:

devzone.nordicsemi.com/.../zboss_5F00_trace4.bin

Can I have the zboss lib version with a fix but without traces, please? ;-)

It's just that this one with traces I have to actually read from uart or it freezes %(

or can I count on the 1.3.1 bugfix maybe..?

If you need me to test some other version of the fix - let me know, I'm opened for this.

Thanks!

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

Edvin — Tue, 03 Mar 2026 11:39:13 GMT

Thank you!

Ok, next iteration. Can you please try the attached library?

devzone.nordicsemi.com/.../libzboss.ed.a_2D00_2.zip

Just rename it and place it in the same location as the previous one. To make sure that it is updated, delete the build folder and build from scratch (this was not an issue. You did use the correct one in the previous trace, I just thought I'd mention it).

Best regards,

Edvin

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

theorlangur — Mon, 02 Mar 2026 18:41:08 GMT

Hi,

it's great that you were able to see the issue in the traces, it means I've previously dumped the right thing 🙂

I've used and linked the version of zboss lib you've provided, also made sure that it's actually used and actually linked. Unfortunately the potential fix didn't seem to work as I have observed the same behavior.

I'm attaching the new trace log. It includes binding and sending of several on/off commands.

Let me know if you need anything else.

devzone.nordicsemi.com/.../zboss_5F00_trace2.bin

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

Edvin — Mon, 02 Mar 2026 13:34:35 GMT

Hello,

From our Zigbee team:

The traces confirms the issue. Somehow the device doesn't reuse the already resolved short address, but current traces doesn't really show exactly why. We have created a new library with more traces and a potential fix. Can you please try to run the same traces again, but use the attached library (copied into ncs-zigbee/lib/zboss/trace/lib/cortex-m33/hard-float/)

devzone.nordicsemi.com/.../libzboss.ed.a

Best regards,

Edvin

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

theorlangur — Wed, 25 Feb 2026 19:42:34 GMT

it proved a bit challenging. With what you've provided I was unable to get anything.

And correct me if I've screwed up somewhere, but I had to:

* define 'ncs,zigbee-uart = &uart00;' in my DTS overlay file (uart instance is correct)

* also add the following in my config (besides those 2 you've suggested):

CONFIG_ZIGBEE_ENABLE_TRACES=y
CONFIG_ZIGBEE_UART_SUPPORTS_FLOW_CONTROL=y
CONFIG_ZBOSS_TRACE_BINARY_NCP_TRANSPORT_LOGGING=y
CONFIG_ZIGBEE_HAVE_ASYNC_SERIAL=y

Flow control is indeed present and configured for that uart instance.

But I'm not sure about the rest. Anyhow with that I was able to get something regularly printed to uart apparently in a binary format.

Also a curios thing: with either CONFIG_ZIGBEE_HAVE_ASYNC_SERIAL or CONFIG_ZIGBEE_HAVE_SERIAL enabled I somehow losing the initialization of my other uart instances (I communicate with mmWave presence sensors via uart too).

So I had to disable them and just replace with a dumb timer that every 10 seconds sends the off command to bound devices.

I was observing the whole thing with a wireshark and saw already familiar abundance of broadcast address requests

and I was collecting the uart output in parallel.

Nothing else was using that uart instance, it was assigned only to ncs,zigbee-uart.

I've captured it with 'tio' providing the correct baudrate, flowcontrol, etc.

It includes me: binding the lamp to the device. And device attempting to send 'off' command to bound lamp.

During this process I saw many broadcast address requests.

File attached.devzone.nordicsemi.com/.../zboss_5F00_trace.bin

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

Edvin — Wed, 25 Feb 2026 10:05:38 GMT

Hello,

Can you please try to capture a ZBOSS trace from your ZED node. Try to enable it by adding these Kconfigs to your prj.conf:

CONFIG_ZBOSS_TRACE_MASK=0x80000051
CONFIG_ZBOSS_TRACE_LOG_LEVEL_DBG=y

And monitor the UART output. It will look like jibberish data, but save it to a file and upload it here. It needs to be decoded (since this trace is not open source).

Best regards,

Edvin

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

theorlangur — Sat, 21 Feb 2026 09:38:40 GMT

being sick sucks

I hope you feel better now 🙂

I've attached a compressed archive file. There you'll find a wireshark sniffer trace file and desc.md file with all the descriptions and relevant packet numbers.

Let me know if you need something else.

Thanks!

devzone.nordicsemi.com/.../wireshark_5F00_sniffed.tar.gz

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

Edvin — Fri, 20 Feb 2026 10:37:20 GMT

Hello,

Sorry for the late reply. I have been ill and out of office for a few days (nothing serious. Just a fever/cold).

Can you please upload the wireshark sniffer trace, so that I can forward it to our Zigbee team? If you could also specify a few of the relevant packet numbers, that would be helpful!

Best regards,

Edvin

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

theorlangur — Thu, 19 Feb 2026 09:18:23 GMT

if you need me to test some specific case in this regard or sniff some specific communication with wireshark - just let me know.

I also wonder, if you guys could reproduce the issue with "ff:fe" MACs?

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

theorlangur — Mon, 16 Feb 2026 19:35:46 GMT

thanks for the suggestion

I'm looking now at defines you've suggested and the thing is: I don't see where it would make an effect.

If I don't provide these defines, then I don't 'see' the defines in my main.cpp (they don't come from any zigbee header file). And when I do provide the defines (I changed both to 64), there's no difference in the binary size, in the occupied RAM size.

I've found the reference to these defines in:

ncs-zigbee/lib/zboss/src/include/zb_aps_globals.h:110 (zb_aps_binding_table_t)

however there it seems to be used only when ZB_CONFIGURABLE_MEM is NOT defined (which it is).

I've tried changing the defines you've suggested nevertheless. (increased them both to 64).

And the sensor was failing as before attempting to send a command.

I've also tried undef'ing ZB_CONFIGURABLE_MEM and it did change the binary size (made it smaller. I guess because I've cranked up various numbers previously). But alas no improvement with sending the command to a bound device.

However this was not all in vain. Here's a new piece of information I've collected.

Apparently physical location of where the presence sensor was added to the zigbee network doesn't matter all that much for the issue in question. I mean it gets added to a different parent node, that I can see. However it fails sending commands to the bound smart bulb regardless of the physical location.

At the same time added at a location close to the lamp (as I tried many times before without luck), and binding it to a smart socket (it physically is located at some distance over 1 hop in the network) - this worked like a charm without a single issue! No annoying meaningless broadcast with address requests.

I've looked closer at a wireshark sniffed data and the following stands out to me:

4002 39.916372904 0x1af6 Broadcast ZigBee ZDP 138 Network Address Request, Address: SiliconLabor_ff:fe:74:33:11

this is an address request for that smart bulb. It's full MAC is 04:0d:84:ff:fe:74:33:11

the MAC of the smart socket where I don't get any issue binding and sending commands is

70:b3:d5:2b:60:09:d8:3d

I have tried and bound the sensor to another smart socket with MAC ec:1b:bd:ff:fe:a2:0e:a3 and I'm getting exactly the same problem with it: endless meaningless broadcast requests for an address.

I wonder if that 'ff:fe' part of the smart bulb's MAC (and the other smart socket's MAC) which looks suspiciously like a broadcasting short address has anything to do with my problems...

Would it be possible to verify that in ZBOSS sources for you?

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

Edvin — Mon, 16 Feb 2026 14:40:51 GMT

I understand.

You can try to increase these:
ZB_APS_SRC_BINDING_TABLE_SIZE

ZB_APS_DST_BINDING_TABLE_SIZE

And see if that helps.

They are by default defined in ncs-zigbee\lib\zboss\include\zb_config.h, so make sure you define them properly. I have not tested this, but it seems like you need to define ZB_CONFIGURABLE_MEM as well.

Print the final value of ZB_APS_SRC_BINDING_TABLE_SIZE in your log to see that it is properly set.

Best regards,

Edvin

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

theorlangur — Mon, 16 Feb 2026 14:20:49 GMT

my intention is to use a direct binding feature of Zigbee, so that my presence sensor would be able to send commands directly to other devices and not via a coordinator.

I have a zigbee network, based on a coordinator that is managed by a zigbee2mqtt software.

This zigbee presence sensor is added to this zigbee network.

Using a functionality of zigbee2mqtt I bind the endpoint 0, zigbee client On/Off cluster to a corresponding endpoint (also 0) and a zigbee server On/Off cluster of a smart bulb (and in other tests of a smart socket).

The bind command finishes successfully.

And so in the app on my zigbee presence sensor, when I need to send such On/Off command, I'm sending it with "ZB_APS_ADDR_MODE_DST_ADDR_ENDP_NOT_PRESENT" as address mode with an intention to send this command to every device that is bound to this presence sensor (it could be more than one).

And I send On/Off commands exclusively like that, there's no other code path that would send them with other address mode or some explicit destination address. The expectation being that Zigbee implementation would iterate over bound devices, endpoints and clusters, finding the ones that fit the command being sent.

And it works. But for some reason not always, since in some cases it comes to permanent broadcast requests, as described in my original post.

I'm not sure in what format the binding entry is stored but my guess it's using IEEE address instead of a short 16-bit one (which probably is fine in itself...). And for that to work you need an existing entry in the address translation table (I would guess) and if there is none - you need to send a broadcast request to figure out the short network address based on the IEEE one. Why wouldn't it store the received answer permanently in the translation table, locking the entry from eviction - I don't know. I hope people working on ncs-zigbee could help me understand or fix a bug.

All my experiments with different zigbee network sizes were using the described workflow and direct binding functionality.

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

Edvin — Mon, 16 Feb 2026 13:44:43 GMT

[quote user="theorlangur"]destination address: short addr as 0
address mode: ZB_APS_ADDR_MODE_DST_ADDR_ENDP_NOT_PRESENT[/quote]

So these addresses are not used, even when the command works?

If so, how do you usually set up what devices that should receive these messages?

Or is the command sent with a different address in the case of the smaller network when it works as intended?

Best regards,

Edvin

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

theorlangur — Thu, 12 Feb 2026 20:20:14 GMT

Here's a link to the app:
github.com/.../main
the commit state to look at is:

94808f4ac9585ff5bb992e38fd1471c0e311579d

direct link to the repo state

however it might be a little complicated to navigate.
I'm using a self-written C++ wrapper for using ZBOSS API.
It's heavy on templates and constexpr compile-time parts.

The relevant part that sends the on/off command can be found here:
src/main.cpp:320 (send_on_off)

which at the end is 'translated' into a call at:
submodules/nrf_zb_cpp/include/nrfzbcpp/zb_desc_helper_types_ep.hpp:300 (send_cmd)

over to
submodules/nrf_zb_cpp/include/nrfzbcpp/zb_desc_helper_types_cluster.hpp:270 (prepare_args)

important pieces are:

destination short address: 0
destination end point: 0
address mode used: ZB_APS_ADDR_MODE_DST_ADDR_ENDP_NOT_PRESENT

and finally here happens the actual command sending:
submodules/nrf_zb_cpp/include/nrfzbcpp/zb_desc_helper_types_cluster.hpp:347 (on_out_buf_ready)

manufacture code is ZB_ZCL_MANUF_CODE_INVALID
frame direction: ZB_ZCL_FRAME_DIRECTION_TO_SRV
destination address: short addr as 0
address mode: ZB_APS_ADDR_MODE_DST_ADDR_ENDP_NOT_PRESENT
dst ep: 0
profile id: ZB_AF_HA_PROFILE_ID
cluster id: ZB_ZCL_CLUSTER_ID_ON_OFF

What I also find important is that this code that sends commands to bound device works in principle:
in a trivial network case, but also in this big zigbee network, however when added at a different
physical location and when bound to a different target device (smart socket, as I also stated in the
original description).

Also it's important to remember that it works without problems, when the bound device is the immediate
parent node of this end device (I was adding it via zigbee2mqtt by permitting join only for that given
target smart bulb).

In all of these cases exactly the same code path is used for sending commands.

I hope this helps.
Thanks!

Edit:

API used:

zigbee_get_out_buf_delayed_ext

zb_zcl_start_command_header

zb_zcl_finish_and_send_packet

RE: Zigbee end device bound to another device always issues broadcasts to resolve the short network address based on target's MAC

Edvin — Thu, 12 Feb 2026 19:51:11 GMT

Hello,

Can you please share something from your application? What API do you use to send the turn on/off smart socket and light bulbs? Is it possible to share the entire application?

Best regards,

Edvin