Hi all,
I’ve been building a small gateway for my own Home Assistant setup, and it’s now at the point where I’d like outside feedback before going further.
TL;DR: bitEngine Hub is a PoE box that’s a Zigbee coordinator and a Thread border router at once, with OTBR running on the box itself (no OTBR add-on needed). It has two independent 802.15.4 radios:
- an EFR32MG24 running EmberZNet as a Zigbee coordinator (network adapter over TCP; tested with ZHA so far, Zigbee2MQTT
embernext), and - an ESP32-C5 running a Thread border router (OTBR) on the device itself.
Both run at the same time, on their own channels and their own antennas. No multiprotocol firmware, no cloud, no app.
Why I built it
My HA server sits in a corner of the house, and I wanted the Zigbee/Thread radios in a central spot on a single Ethernet cable. The options I found were either:
- single-radio coordinators where you pick Zigbee or Thread (or run experimental multiprotocol firmware), or
- dual-radio units — mainly SMLIGHT’s SLZB-MR series and SMhub, which run both at once on separate SoCs.
I started from this thread from last year, which asks for exactly this. (Edit: I originally wrote that it “ended without a clear answer” — that was wrong, it points to SMLIGHT, who sell a whole range of dual-radio models. Thanks @ShadowFist for the correction.) So this isn’t “nobody makes this”; it’s a different set of trade-offs, which I’ve tried to spell out below.
How it shows up in Home Assistant
It’s essentially two standard devices in one enclosure. Nothing proprietary to install:
- Zigbee: a network coordinator at
socket://<host>:6638for ZHA (EZSP). Zigbee2MQTT with theemberdriver (tcp://<host>:6638) should work the same way, but I haven’t tested it yet. The Hub also advertises itself via mDNS (_zigbee-coordinator._tcp). - Thread: a standard OpenThread Border Router, added through HA’s Open Thread Border Router integration.
Because OTBR runs on the Hub itself, what goes over your network is plain IPv6 and the OTBR REST API — not a raw radio protocol (Spinel) tunnelled to your HA host. You don’t need the OTBR add-on, it works the same if HA runs in a VM, and the Thread mesh doesn’t depend on the HA host being up. (SMLIGHT’s U-series has a similar on-device OTBR mode, currently marked beta in their docs; here it’s the only mode.)
Hardware
| Zigbee | EFR32MG24, EmberZNet 8.2.x NCP |
| Thread + Wi-Fi | ESP32-C5 (802.15.4 + dual-band Wi-Fi 6) |
| Uplink | 10/100 Ethernet with 802.3af PoE, or 5 GHz Wi-Fi |
| Power | PoE or USB-C 5 V |
| Antennas | 2 × external SMA (one per radio) |
| Indicators | 4 × RGB LEDs: SYS / ZIGBEE / THREAD / NET |
| Enclosure | 3D-printed on the prototype; aluminium extrusion planned for production |
Honest limitations
- Use Ethernet if you can. 2.4 GHz Wi-Fi is disabled on purpose, to keep that band for Zigbee and Thread. 5 GHz Wi-Fi uplink works, but it shares the C5’s radio with Thread (time-sliced), and serial-over-IP coordinators are generally more reliable over a wire anyway.
- Both networks live in the same spot. That’s the trade-off vs. two separate boxes. If your house needs the Zigbee coordinator and the Thread BR in different places, two devices are still the better answer.
- Certification in progress. FCC and CE testing is being planned for the production hardware. Until that’s done, this isn’t for sale.
What I’ve tested so far
Small scale so far — this is my own home network:
| Component | Version |
|---|---|
| Home Assistant | 2026.4.1 |
| ZHA | 1.1.1 |
| bellows | 0.49.0 |
| zigpy | 1.2.2 |
| zha-quirks | 1.1.1 |
- ZHA: 3 Zigbee devices, 7 days continuous uptime
- Thread: 2 Matter-over-Thread devices, 7 days continuous uptime
Next up: Zigbee2MQTT (ember), the current HA release, and larger device counts. I’ll post results and screenshots here as they come in.
Firmware
The plan is to open-source the Hub firmware (ESP32-C5 side: TCP bridge, OTBR integration, web UI) under Apache-2.0.
The MG24 image is built on Silicon Labs’ EmberZNet SDK. The SDK itself can’t be redistributed, so — like Nabu Casa’s silabs-firmware-builder — I’ll publish the project config, my own extensions and build scripts, and the build will pull the SDK from Silicon Labs directly.
It’s not public yet — the code needs cleanup and I want the release to be something people can actually build. It will be published before any units go out to other testers, and I’ll post the link here when it’s up.
Hardware: the schematics (PDF) will be published alongside the firmware, under CERN-OHL-P v2. Board layout and Gerbers won’t be, at least initially.
What I’d love your input on
- Would one box for both networks be useful to you, or do you prefer separate devices? If separate, what’s the main reason?
- What matters most: true simultaneous dual radio / OTBR on the device / PoE / something else?
- Open source: firmware (Apache-2.0) and schematics (CERN-OHL-P) will both be published. Is there anything beyond that — Gerbers, mechanical files — that would actually change whether you’d use it?
- Anything missing you’d expect from a network coordinator? (Bluetooth proxy, WireGuard, etc.)
Testing
I’m running it on my own network right now. If there’s enough interest, I’d like to put a small number of units in other people’s homes later — especially larger Zigbee networks or mixed Matter-over-Thread setups. If that’s something you’d be up for, just say so in a reply.
I’ll keep this thread updated as a dev log. Thanks for reading!
