ZeroStack.
Your coordinator, rebuilt from zero.

ZeroStack is new firmware for the Texas Instruments radio chip inside your SMLIGHT adapter: the CC2652P, CC2652P7 and CC2674P10. It replaces the stock Zigbee coordinator stack with one we re-engineered from the operating system up, and it speaks exactly the same Z-Stack language to Zigbee2MQTT and ZHA as before. Flash it, restart your hub, and the adapter you already own becomes a different device: twelve times the traffic in our lab, no freezes, no dropped battery sensors, no lag between your command and the light.

It is designed and signed specifically for SMLIGHT coordinators.

Home Assistant and Zigbee2MQTT users with 50 to 300 devices on a CC-based coordinator have seen these lines. Each one has a specific cause inside the stock firmware. ZeroStack removes the cause, not the symptom.

Not sure which of these you have been hitting? The in-browser ZeroStack log analyzer, published with the release, matches a Zigbee2MQTT, ZHA or OpenThread Border Router log against this catalogue and tells you which of them you were hitting and whether ZeroStack removes it. Nothing leaves your browser. The same catalogue ships as an MCP server, so an AI coding or operations agent can read your log and reach the same conclusion.

The Zigbee stack inside every CC-based coordinator on the market has a long lineage. Its design goes back to the first Zigbee radios of the early 2000s, chips with a few hundred bytes of RAM. Twenty years and several owners later, the decisions made for those chips are still in the code.

Those early decisions each cost a small stall somewhere on the path between the radio and your hub. We traced the freezes people report to a handful of them, all in the foundations of the stack, none of them fixable with a setting.

Under a burst of traffic, say Zigbee2MQTT restarting and re-interviewing 40 routers, those stalls compound. The queue grows faster than it drains, your hub logs a six-second timeout, and the coordinator stops answering. The stock stack falls off a cliff. Below the cliff, throughput is zero.

All measurements from SMLIGHT’s radio lab: real adapters, hardware debuggers reading the chip’s memory while it runs, RF sniffers validating every frame on air, Zigbee2MQTT attached as the host. One transaction is one command and its confirmation, for example switching a light on. The comparison is stock TI firmware on the same adapter.

Every number above comes from a specific, repeatable lab run. The engineering notes behind them are published with the release.

Memory and table sizes are set per chip, so every model uses all the RAM it has.

1. Check your hub’s backup. Zigbee2MQTT writes coordinator_backup.json when it stops; ZHA keeps its own backups automatically. Stop Zigbee2MQTT or ZHA cleanly before you flash, so the backup is current.
2. Open SLZB-OS in your browser and go to Settings and Tools → Firmware update.
3. Pick ZeroStack in the Zigbee firmware list for your model, 115200 baud unless you have set your hub to 460800, and press Flash. The adapter fetches the signed image from SMLIGHT’s update server and flashes the radio. About 30 seconds.
4. Start Zigbee2MQTT or ZHA. The hub finds a blank radio, recognises its own network in the backup, and restores it onto ZeroStack: same channel, same PAN, same network key, same device link keys. Zigbee2MQTT logs Started with result 'restored'.
5. Done. Mains-powered devices answer at once. Battery devices rejoin on their own the first time they wake up, as they do after any coordinator restore, then report normally.

We tested exactly this path. On Oct 25 we took a live Zigbee2MQTT 2.14 network (routers and sleepy end devices) from stock firmware to ZeroStack, back to stock, and to ZeroStack again. Each time the network restored from the hub’s backup and no device was paired again.

zh:zstack: Detected znp version 'ZStack3x0' ({"majorrel":2,"minorrel":8,"revision":20261026})
zh:adapter:zstack:manager: determined startup strategy: restoreBackup
zh:zstack:backup: successfully recovered link key for 94b216fffec6687d using tclk seed
zh:controller: Started with result 'restored'
z2m: Currently 35 devices are joined.

Going back. The stock firmware stays in the same list. Flash it, start your hub, and it restores the network the same way. Note that the update erases the radio’s own copy of the network; the restore relies on your hub’s backup. If you run a hub without backups, make one first.

460800 baud. Builds for 460800 are in the list for people who want the faster serial link. The baud rate is part of the firmware, so changing a setting is not enough: flash the 460800 build of ZeroStack, then set 460800 in SLZB-OS and in your hub. All three must match. 115200 remains the default.

USB adapters. The SLZB-07p7 and SLZB-07p10 update from the SMLIGHT web flasher in your browser instead of SLZB-OS. Steps 1, 4 and 5 are the same.

ZeroStack runs on the Texas Instruments radio in these SMLIGHT models. It does not apply to models with a Silicon Labs radio (SLZB-06M, 06Mg24, 06Mg26, SLZB-07, 07Mg24, and the Silicon Labs radio inside MR and Ultima units).

Requirements: a current SLZB-OS with ZeroStack in its Zigbee firmware list, and Zigbee2MQTT or ZHA with a current coordinator backup.

ZeroStack came out of the SMLIGHT Radio Lab, the test bench we built to push coordinators past their limits before customers do. Nine live radios on the bench, each with a hardware debugger reading the chip’s memory in real time, ZREL units injecting traffic at a chosen rate, and an RF sniffer validating every frame on air against the specification.

• Sustained load. 180 transactions per second for the length of the run, with Zigbee2MQTT attached: 1,686 incoming messages processed, 0 errors, 0 timeouts. Stock firmware on the same bench stopped answering long before that.
• Fuzzing. 2.4 million malformed host frames in three seconds against the host interface. That alone found four memory-safety bugs. All fixed before release.
• Hardware validation. Every chip in the release passed the same hardware validation suite under the debugger.
• Upgrade and downgrade. Live network moved to ZeroStack and back, twice, no re-pairing.
• Field builds. Early builds went to users with chronic freezes before the release.