v2025.12.2-pre2

[Nerivec]

Important

This update increases several configs to better take advantage of the higher memory on 24 and 26 series.
If you encounter any trouble after flashing, clear the NVM, then re-flash this firmware.

See https://github.com/Nerivec/silabs-firmware-builder/releases/tag/v2025.12.2-pre1 for previous changes.

Full Changelog: v2025.12.2-pre1...v2025.12.2-pre2

---

This discussion was created from the release v2025.12.2-pre2.

[trenb]

I've installed this on my slzb-06mg26u. I'm very excited for the changes for the mg24/mg26 chipsets. It installed overtop your previous 9.0.1 release with no problems. I'll open a ticket if I run into any issues.

[chris-1243]

Running fine (~48h) on a SLZB-07MG24. I cleared the NVRAM as I did not want to get any trouble and flashed this pre2 release.

EDIT: This firmware has been stable since a month👍

[toxacj]

I flashed my SLZB-07MG24, and there were no problems.I didn't clear the NVM.Thank you for your work.

[propi62]

what methode did you use to update the SLZB-07MG24?

[chris-1243]

This tool provided also by Nerivec

• https://github.com/Nerivec/ember-zli

[MnM001]

I have been running this firmware on a tubeszb-mgm24 for about 5 days with no issues. Did not clear the NVM before updating.
Larger network (151 devices) with lots of Tuya devices. Thanks for your great work.

[burmistrzak]

@Nerivec Somewhat random, but having two ZBT-2 side by side (one Zigbee, the other Thread), I noticed that the one with custom firmware doesn't light up like its friend, which is kinda sad. 😅

What do you think about including the Status LED extension from upstream?

[burmistrzak]

Btw. have you seen NabuCasa#200 (comment)?

[Nerivec]

silabs-firmware-builder/src/zigbee_ncp/zigbee_ncp.slcp

Lines 98 to 99 in bfabc37

	- name: SL_ZIGBEE_MULTICAST_TABLE_SIZE
	value: 26

Should be plenty...

With NC making customizations to the protocol, it is bound to clash with vanilla firmware/apps...
Maintaining logic branches with every possible customizations that any builder can add is unrealistic, you end up needing the equivalent of ZHC for the base protocol... 😰

[burmistrzak]

👏 Time 👏 For 👏 ZoH ☺️

Anyhow, we might want to add a note somewhere that Z2M expects/works best with vanilla NCP protocols and that we're not testing against customized adapter protocols.
I guess no fancy LEDs for me then...

[puddly]

With NC making customizations to the protocol, it is bound to clash with vanilla firmware/apps...

Just chiming in here to say that the firmware extensions we add are all done via XNCP, which is the SDK-provided mechanism for custom commands. We don't touch EZSP and there's no possibility of collision. I've also never run into another EZSP firmware that even implemented XNCP commands to begin with so I think it's safe on that front too 😁

Our firmware extensions are quite useful, I spent a long time (probably too long) making them fully modular and adapter-agnostic. They allow for custom board names for adapters without factory tokens (e.g. early Sonoff), identifying the exact chip used in an adapter, checking the flow control expected by the firmware, disabling firmware filtering of group packets, pulling regulatory information for TX power, and so on: https://github.com/NabuCasa/silabs-firmware-builder/blob/ffbb9030b026b92b7347e127828803e84461363c/src/zigbee_ncp/extension/xncp_common_extension/src/xncp_common_commands.c#L62

I'm sure Z2M would benefit from all of these enhancements the same way ZHA does.

[burmistrzak]

@puddly Thanks for clarifying!
I tried to build a unified fork with @Nerivec's enhancements and your XNCP extensions included, but the different SDK versions are more of a challenge than I initially thought. Any ETA for the first release with the new Silabs SDK?

My ideal firmware would be as fresh (i.e. up to date) as this fork, but include all the extensions you've made as well. 😄

[trenb]

Just wanted to add, I've setup this firmware on a SMLight SLZB-07 and a easyiot ZB-GW04 v1.2, and both have been running stable for quite a while now. I split my zigbee mesh into 3 parts, and since that time, I'm no longer running into ANY issues. The timesync issue I had, gone; the ping timeout issues, gone; the set timeout issues, gone. I'm very impressed it works on the humble EFR32MG21 so well. I can't wait to see what's next!

[MilesTEG1]

Hello
On my SLZB-06M, there is a new zigbee firwmare (coordinator):

I asked them yesterday if their FW is the same as yours, the answered me:

No, the firmwares are not the same.
We compile them with different settings. You can try both and see which works better.

I can't find a file to send you... So we have to guess ;)
Is someone as tested the SMLIGHT new Zigbee FW ?

[trenb]

@MilesTEG1 I've been running Nerivec's 9.0.1 firmware on all my coordinators (slzb-06mg26u, slzb-07 and zb-gw04 v1.2) and they have all been running flawlessly for over a month now. No longer have any timeouts on ping or timeouts on set. It's really nice. Honestly, I'm a bit disappointed how slowly SMLight has been moving on their advanced coordinators like the slzb-06mg26u.

Anyway, take this with a grain of salt :) Do you want to try the SMLight firmware and respond back?

[Nerivec]

You can use ember-zli to dump the stack config after installing a firmware:
https://github.com/Nerivec/ember-zli/wiki/Stack#get-stack-config-firmware-defaults
Some more internal configs cannot be retrieved like this, but it should cover the big ones.

Firmware builds here are Open Source, so, don't need to dump the config really 😁

silabs-firmware-builder/src/zigbee_ncp/zigbee_ncp.slcp

Lines 95 to 238 in bfabc37

	define:
	# - name: SL_ZIGBEE_CUSTOM_MAC_FILTER_TABLE_SIZE
	# value: 15
	- name: SL_ZIGBEE_MULTICAST_TABLE_SIZE
	value: 26
	## xg21
	- name: SL_ZIGBEE_ROUTE_TABLE_SIZE
	value: 200
	condition: [ "device_generic_family_efr32xg21" ]
	## xg24
	- name: SL_ZIGBEE_ROUTE_TABLE_SIZE
	value: 254
	condition: [ "device_generic_family_efr32xg24" ]
	## xg26
	- name: SL_ZIGBEE_ROUTE_TABLE_SIZE
	value: 254
	condition: [ "device_generic_family_efr32xg26" ]
	## xg21
	- name: SL_ZIGBEE_DISCOVERY_TABLE_SIZE
	value: 8
	condition: [ "device_generic_family_efr32xg21" ]
	## xg24
	- name: SL_ZIGBEE_DISCOVERY_TABLE_SIZE
	value: 16
	condition: [ "device_generic_family_efr32xg24" ]
	## xg26
	- name: SL_ZIGBEE_DISCOVERY_TABLE_SIZE
	value: 16
	condition: [ "device_generic_family_efr32xg26" ]
	configuration:
	- name: SL_BOARD_ENABLE_VCOM
	value: 1
	- name: SL_IOSTREAM_USART_VCOM_FLOW_CONTROL_TYPE
	value: usartHwFlowControlCtsAndRts
	condition:
	- iostream_usart
	- name: SL_IOSTREAM_EUSART_VCOM_FLOW_CONTROL_TYPE
	value: SL_IOSTREAM_EUSART_UART_FLOW_CTRL_CTS_RTS
	condition:
	- iostream_eusart
	- name: SL_CLI_MAX_INPUT_ARGUMENTS
	value: 16
	# - name: SL_ZIGBEE_BINDING_TABLE_SIZE
	# value: 32
	# - name: SL_ZIGBEE_MAX_END_DEVICE_CHILDREN
	# value: 32
	- name: SL_ZIGBEE_PACKET_BUFFER_HEAP_SIZE
	value: SL_ZIGBEE_LARGE_PACKET_BUFFER_HEAP
	# - name: EMBER_AF_PLUGIN_ZIGBEE_PRO_STACK_CHILD_TABLE_SIZE
	# value: 32
	# - name: SL_ZIGBEE_KEY_TABLE_SIZE
	# value: 20
	- name: SL_CLI_EXAMPLE_IOSTREAM_HANDLE
	value: sl_iostream_vuart_handle
	- name: NVM3_DEFAULT_NVM_SIZE
	value: 32768
	condition:
	- device_series_2
	# If using zigbee_secure_key_storage we do not need to support backwards
	# compatibility because we have never deployed images with keys in PSA
	# As a result, these lines end up saving some code space
	- name: SL_PSA_ITS_SUPPORT_V1_DRIVER
	value: 0
	- name: SL_PSA_ITS_SUPPORT_V2_DRIVER
	value: 0
	- name: SL_PSA_ITS_SUPPORT_V3_DRIVER
	value: 1
	- name: SL_STACK_SIZE
	value: 4096
	condition:
	- cmsis_rtos2
	- name: SL_ZIGBEE_STACK_RTOS_TASK_STACK_SIZE
	value: 4096
	condition:
	- cmsis_rtos2
	# custom from zigbee_ncp_uart_hw
	- name: SL_IOSTREAM_USART_VCOM_RX_BUFFER_SIZE
	value: 128
	condition:
	- iostream_usart
	- name: SL_IOSTREAM_EUSART_VCOM_RX_BUFFER_SIZE
	value: 128
	condition:
	- iostream_eusart
	- name: SL_ZIGBEE_BROADCAST_TABLE_SIZE
	value: 30
	- name: SL_ZIGBEE_NEIGHBOR_TABLE_SIZE
	value: 26
	- name: SL_ZIGBEE_BINDING_TABLE_SIZE
	value: 32
	- name: SL_ZIGBEE_KEY_TABLE_SIZE
	value: 1
	## xg21
	- name: SL_ZIGBEE_SOURCE_ROUTE_TABLE_SIZE
	value: 200
	condition: [ "device_generic_family_efr32xg21" ]
	- name: SL_ZIGBEE_ADDRESS_TABLE_SIZE
	value: 32
	condition: [ "device_generic_family_efr32xg21" ]
	- name: SL_ZIGBEE_APS_UNICAST_MESSAGE_COUNT
	value: 64
	condition: [ "device_generic_family_efr32xg21" ]
	- name: SL_ZIGBEE_MAX_END_DEVICE_CHILDREN
	value: 32
	condition: [ "device_generic_family_efr32xg21" ]
	## xg24
	- name: SL_ZIGBEE_SOURCE_ROUTE_TABLE_SIZE
	value: 254
	condition: [ "device_generic_family_efr32xg24" ]
	- name: SL_ZIGBEE_ADDRESS_TABLE_SIZE
	value: 128
	condition: [ "device_generic_family_efr32xg24" ]
	- name: SL_ZIGBEE_APS_UNICAST_MESSAGE_COUNT
	value: 128
	condition: [ "device_generic_family_efr32xg24" ]
	- name: SL_ZIGBEE_MAX_END_DEVICE_CHILDREN
	value: 64
	condition: [ "device_generic_family_efr32xg24" ]
	- name: SL_ZIGBEE_APS_DUPLICATE_REJECTION_MAX_ENTRIES
	value: 64
	condition: [ "device_generic_family_efr32xg24" ]
	- name: SL_ZIGBEE_PACKET_BUFFER_HEAP_SIZE
	value: SL_ZIGBEE_HUGE_PACKET_BUFFER_HEAP
	condition: [ "device_generic_family_efr32xg24" ]
	## xg26
	- name: SL_ZIGBEE_SOURCE_ROUTE_TABLE_SIZE
	value: 254
	condition: [ "device_generic_family_efr32xg26" ]
	- name: SL_ZIGBEE_ADDRESS_TABLE_SIZE
	value: 128
	condition: [ "device_generic_family_efr32xg26" ]
	- name: SL_ZIGBEE_APS_UNICAST_MESSAGE_COUNT
	value: 128
	condition: [ "device_generic_family_efr32xg26" ]
	- name: SL_ZIGBEE_MAX_END_DEVICE_CHILDREN
	value: 64
	condition: [ "device_generic_family_efr32xg26" ]
	- name: SL_ZIGBEE_APS_DUPLICATE_REJECTION_MAX_ENTRIES
	value: 64
	condition: [ "device_generic_family_efr32xg26" ]
	- name: SL_ZIGBEE_PACKET_BUFFER_HEAP_SIZE
	value: SL_ZIGBEE_HUGE_PACKET_BUFFER_HEAP
	condition: [ "device_generic_family_efr32xg26" ]

---

You should keep to one source of firmware though, it avoids issues (large stack config changes can result in NVM corruption after flashing, which can happen when changing from one firmware source to another which may have wildly different configs).
It's recoverable (have to clear NVM), but it's annoying.