I already use an SLZB-Ultima3 for my main Zigbee network, so when I first saw the Nano, I assumed it was simply another network-attached Zigbee/Thread coordinator.
Looking into it and testing the device, that is not really what it is designed to be.
The EFR32MG24 radio is only one part of the package. The Nano is essentially a tiny, fanless Linux appliance running on a Sophgo SG2000 SoC (RISC-V / ARM architecture) with 512 MB of RAM and 8 GB of eMMC. Instead of acting purely as a remote serial adapter for a central machine, it is designed to run Zigbee2MQTT, Mosquitto, Node-RED, and Matterbridge locally.
That distinction is what made it worth looking into.
Why the architecture makes sense to me
My Home Assistant setup is somewhat specialized: I run Home Assistant Core inside a Python virtual environment on my Proxmox environment, alongside the rest of my homelab containers and services.
It is a solid setup, but like any centralized infrastructure, it has a single point of maintenance: rebooting the host server takes down everything running on it.
The Nano makes it practical to decouple the Zigbee stack from the compute host:
Home Assistant / Proxmox
|
| MQTT / Matter
v
SMHUB Nano
/ | \
Z2M MQTT Node-RED
|
Zigbee mesh
With Zigbee2MQTT and Mosquitto running on the Nano itself, a Proxmox reboot or host maintenance leaves the Zigbee network intact.
Obviously, automations relying on Home Assistant won’t fire while the host is down. However, essential or fallback logic moved to Node-RED on the Nano can keep running locally without depending on the main server.
Hardware observations
The hardware package is compact:
- SoC: Sophgo SG2000
- Memory & Storage: 512 MB RAM, 8 GB onboard eMMC
- Radio: Silicon Labs EFR32MG24 (802.15.4 for Zigbee / Thread) with external antenna
- Connectivity: 10/100 Ethernet, Wi-Fi 6, Bluetooth, USB-A
- Power: USB-C (or 802.3af PoE depending on the hardware variant/SKU purchased)
The 8 GB onboard eMMC is a clear advantage over micro-SD cards for an appliance meant to run 24/7 without flash degradation issues.
The 512 MB of RAM is the obvious constraint. For a single lightweight task it is plenty, but once you start stacking services, headroom gets tight very fast. This is an edge appliance, not a mini PC replacement.
The MG24 radio: Zigbee vs Thread
Because the device relies on a single EFR32MG24 chip for its 802.15.4 interface, you shouldn’t view it as a drop-in replacement for multi-radio hardware if your goal is running concurrent, high-throughput Zigbee and Thread networks on dedicated transceivers.
For running a dedicated Zigbee coordinator, an OTBR border router, or an isolated edge node, the MG24 is well supported. If you need simultaneous dual-radio operation, SMLIGHT’s multi-radio coordinators are still the proper tool.
Remote deployments
This is where the architecture really fits.
If you have an outbuilding, garage, workshop, or a secondary site where you want Zigbee coverage, you typically have to choose between running a long USB/Ethernet run, placing a full Raspberry Pi/mini PC, or relying on weak mesh hops.
A dedicated appliance allows local handling of the Zigbee layer:
MAIN HOUSE
Home Assistant
|
| VPN (WireGuard / Tailscale / Overlay)
v
REMOTE LOCATION
SMHUB Nano
|
Zigbee devices
The firmware includes built-in support for VPN tunnels (such as WireGuard and Tailscale). In my case, connecting edge nodes back to my central Proxmox environment via an overlay network (like Nebula) makes an independent Linux node at an off-site location very straightforward to maintain.
At that point, it behaves like an edge gateway rather than a dumb antenna.
The USB-A port
The USB-A port exposes connected devices over the network. If you need to offload a secondary radio (such as a Z-Wave stick) or an external serial interface to a better physical location without placing your main server there, the Nano can double as a network USB hub.
Memory footprint and long-term stability
The main question mark remains memory management under real workloads.
Zigbee2MQTT, Node-RED, and Matterbridge are all Node.js-based applications. Node.js processes carry a non-trivial baseline memory footprint and rely on V8 garbage collection, which does not leave much margin on a 512 MB system when running three or four of these services concurrently alongside the base OS and Mosquitto.
Early firmware releases had some reports of memory pressure under heavy multi-service loads. Firmware optimization and software builds have evolved since then, but sustained uptime under load is what matters.
Summary
If all you need is a reliable network coordinator to feed a Zigbee2MQTT LXC or container on an existing server, a standard network coordinator (like an SLZB-06 or SLZB-Ultima) is simpler, cheaper, and avoids redundant layers.
The SMHUB Nano makes sense if:
- You run Home Assistant on Proxmox or bare metal and want your Zigbee mesh independent of host reboots.
- You need a self-contained node for a remote location or detached structure.
- You prefer distributing core protocol services (radio + MQTT + fallback logic) out to dedicated appliances.
For those who have been running the SMHUB Nano MG24 for an extended period: what does your real-world RAM usage look like, and have you seen OOM kills, service restarts, or memory pressure when running Z2M alongside Node-RED or Matterbridge over weeks of uptime?