v2025.12.2-pre1

[Nerivec]

What's Changed

• https://docs.silabs.com/sisdk-release-notes/2025.12.2/sisdk-zigbee-release-notes/sisdk-zigbee-sdk-release-notes
• Update builder to use new Silabs tools
• Allow re-using migrated adapter as router in same network (shuffle EUI/IEEE to avoid conflict)

---

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

[nstefy]

@Nerivec Thanks for the new firmware

It works on SLZB-MR4U

history & steps:

started from
OS version 3.1.0 EFR32MG26 v2025.6.2-pre0

upgrade os -> v3.2.6.dev3
flashed silabs-firmware-recovery v0.5.0
https://github.com/Nerivec/silabs-firmware-recovery/releases/download/v0.5.0/EFR32MG26B420F3200IM48_app_clear_134217728_3276800_8192_134242304.gbl

upgrade firmware version:
v2025.6.2-pre5
https://github.com/Nerivec/silabs-firmware-builder/releases/download/v2025.6.2-pre5/smlight_slzb06Mg26_zigbee_ncp_8.2.2.0_115200_sw_flow.gbl

-> aplha build -> smlight_slzb06Mg26_zigbee_ncp_2025.12.2_9.0.1_115200_sw_flow.gbl
https://github.com/Nerivec/silabs-firmware-builder/actions/runs/23643560171/artifacts/6142759816

v2025.12.2-pre1
https://github.com/Nerivec/silabs-firmware-builder/releases/download/v2025.12.2-pre1/smlight_slzb06Mg26_zigbee_ncp_2025.12.2_9.0.1_115200_sw_flow.gbl

no need for recovery firmware between versions

[Nerivec]

Recovery between firmware should not be needed in general, but when switching firmware builder, they can sometimes have too many differences (configs), which then can cause issues. Seems to have been the root cause of the issues with smlight builds vs these builds around 8.2.x.
In short, as long as you keep to one firmware source, and that source does not change configs too drastically between versions, everything should be fine.

[nstefy]

Thanx for information
I didn't know even existed recovery until 8.2.2 witch was the last step indicated by smlight support team as the last try before replacement was needed

[nstefy]

as an update regarding firmware:
1 device from 86 random failed to sync, didn't happened with v2025.6.2-pre5

https://www.zigbee2mqtt.io/devices/E6.html#nous-e6

[3/29/2026, 10:19:08 PM] zhc:tuya: Failed to sync time with '0xa4c13863fab17b2e' (Error: ZCL command 0xa4c13863fab17b2e/1 manuSpecificTuya.mcuSyncTime({"payloadSize":8,"payload":[105,201,123,35,105,201,165,83]}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false}) failed ({"target":44381,"apsFrame":{"profileId":260,"clusterId":61184,"sourceEndpoint":1,"destinationEndpoint":1,"options":4416,"groupId":0,"sequence":167},"zclSequence":140,"commandIdentifier":11} timed out after 10000ms))
[3/30/2026, 1:00:18 AM] zhc:tuya: Failed to sync time with '0xa4c13863fab17b2e' (Error: ZCL command 0xa4c13863fab17b2e/1 manuSpecificTuya.mcuSyncTime({"payloadSize":8,"payload":[105,201,160,233,105,201,203,25]}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false}) failed ({"target":44381,"apsFrame":{"profileId":260,"clusterId":61184,"sourceEndpoint":1,"destinationEndpoint":1,"options":4416,"groupId":0,"sequence":105},"zclSequence":71,"commandIdentifier":11} timed out after 10000ms))
[3/30/2026, 3:16:10 AM] zhc:tuya: Failed to sync time with '0xa4c13863fab17b2e' (Error: ZCL command 0xa4c13863fab17b2e/1 manuSpecificTuya.mcuSyncTime({"payloadSize":8,"payload":[105,201,192,193,105,201,234,241]}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false}) failed ({"target":44381,"apsFrame":{"profileId":260,"clusterId":61184,"sourceEndpoint":1,"destinationEndpoint":1,"options":4416,"groupId":0,"sequence":11},"zclSequence":237,"commandIdentifier":11} timed out after 10000ms))

[Nerivec]

Unlikely to be related to the firmware, but the update itself could have changed the mesh a bit, and that device could have migrated to a lesser router or something similar.

[MilesTEG1]

Hello,
I installed this version on my SLZB-06M, no problems, everything seems to be working fine.

The only things, is that the version isn't recognized by SLZB-OS, so Home Assistant keep's telling me there is an update 😅

[Nerivec]

This release shuffles quite a bit around the build process (due to internal changes at Silabs), no doubt several of these "checks" will need updating for proper support. Also have to update a few things in ember-zli myself 😉

[chris-1243]

This release is working fine on the SLZB-07MG24

[apydo]

Hi,

I'm testing this release on SLZB-06M (core firmware 3.2.0) and on SLZB-06Mg24 (core firmware 3.2.0) in Ethernet mode.
I was previously on v2025.6.2-update1.

Z2M 2.9.2 started with no error on both adapters. Running now for more than 10 minutes without trouble.

Thanks for your work @Nerivec.

[Asmir1975]

Hi @Nerivec,
I switched yesterday from SLZB-06M (Radio 8.0.2, Core 3.2.6 dev)) to Sonoff Dongle M.

I was busy on my repo that I didn't notice you were already far beyond 8.0.2 on the SLZB-06M 😎
Testing the Sonoff Dongle-M for over 24 hours now with v2025.6.2-update1 - zero problems. Great work as always! 🎸

The only thing I noticed are slightly lower LQI values compared to the SLZB-06M, but as we all know, LQI alone doesn't say much about real-world stability. Network is running smooth.

Would you recommend jumping from v2025.6.2-update1 directly to v2025.12.2-pre1 on the Sonoff Dongle M, or is it better to wait for a stable release given that it's a pre-release build?

Thanks for everything you do for the community! 👏

[Asmir1975]

Quick follow-up @Nerivec: I mentioned "slightly lower LQI" with the Sonoff Dongle-M – turns out it was more than slightly 😄.
The Sonoff was rock solid stable, no complaints there. But out of curiosity I switched back to the SLZB-06M yesterday with the same v2025.6.2-update1, same location, same config and after 20 hours the mesh performance is significantly better. LQI values much higher across the board. 🎸.SLZB-06M is back home! 😄

[Nerivec]

mesh performance is significantly better

Was this just about the LQI values, or did you notice real perf changes?

[Asmir1975]

Hi, it might just be my subjective impression, but the results speak for themselves 😄. The SLZB-06M was stable from the start with LQI values of 150+ across 56 devices, 26 of which are routers. I gave the Sonoff time to reroute, but even after 24 hours the LQI was still ranging from 64 to around 140 on many devices. Despite better specs on paper, the SLZB-06M simply performs better in my mesh. Thanks for your support 👍 You rock as always 🎸 Best regards from sunny Holland 🫶​​​​​​​​​​​​​​​​

[Nerivec]

I'll communicate this to Sonoff, could be calibration issues, which could affect the LQI.
Though, as you mentioned, LQI isn't strictly reliable for perf monitoring, too many different calculations, too many things affecting it. 🤷
I'd be more worried if you started seeing actual problems, like latency in device responses & co.

[Asmir1975]

Actually, both are rock solid devices. But one would expect better performance from the newer MG24 chip with two antennas compared to the MG21 SLZB with one antenna. In direct comparison under identical conditions, the SLZB-06M delivers significanty better LQI. Your greatest achievement is not just keeping perfectly capable devices alive that manufacturers would love to see replaced by the next shiny thing. You show manufacturers where to go, fix what they break and continue developing for models they have “retired”. That is truly remarkable! 😉🎸 Thanks for everything you do for the community 🫶

[jclendineng]

Updated backup MG24-2024 to 2025.12+bootloader no issues. Will switch the network over to it and let it bake a bit.

[burmistrzak]

@Nerivec Quick question: The official ZBT-2 integration allows convenient updates from within HA. Unfortunately, the firmware repo URL is hardcoded and points to the (less up to date) Nabu Case repository.

In your opinion, would it still make sense to open a PR over there and propose support for a custom firmware repo? 🤔

[Nerivec]

You can try.
On top of a few builder repos, several users are building their own firmware nowadays, just the way they want them, so, might make sense as an advanced option.
Would have to support all hardware though, not just ZBT-2, else it would skew features.

One probable barrier would be the fact that there are likely quite a few hardcoded verifications (even in USF itself), so, it might not allow updating to custom firmware without matching exactly what it expects, or refactoring that as well...