Zigbee coordinator + Thread border router with OTBR on the device (no add-on needed) on one PoE box — firmware & schematics to be published, looking for feedback

bitEngine · October 13, 2026, 11:25am

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 and Zigbee2MQTT ember), 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>:6638 for ZHA (EZSP). Zigbee2MQTT with the ember driver (tcp://<host>:6638) works the same way, tested with Zigbee2MQTT 2.14.2 (see the Oct 27 update). 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
Zigbee2MQTT	2.14.2

ZHA: 3 Zigbee devices, 7 days continuous uptime
Thread: 2 Matter-over-Thread devices, 7 days continuous uptime
Zigbee2MQTT (ember): 3 Zigbee devices paired, reporting and control working, 9+ hours on the existing network

Next up: moving an existing network onto the Hub from another coordinator, 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!

zuz242 · October 13, 2026, 5:03pm

Nice setup.
Nothing can beat the feeling of DIY
But its nothing new over the SMhub devices, isnt it?
I use a SLZB-06M for Zigbee and an SMhub essential for Thread.
The Hub could do both but i stick with zigbee to my rock-stable device.

ShadowFist · October 13, 2026, 5:51pm

Yeah, you may have missed this post (or the one above it). That vendor alone sells 8 10 dual-radio models.

bitEngine · October 14, 2026, 2:57am

Fair — “rock-stable” is the bar, and 7 days with 3 devices doesn’t clear it; it’s just what I have so far.

One question, since you’re the exact case I’m curious about: the SMhub could run your Zigbee too, but you keep it on the 06M. Is that from a bad experience with Zigbee on the hub, or just “don’t touch what works”? That’s really the question behind my first bullet: whether anyone wants one box at all, or whether one box only wins if it’s at least as boring as a dedicated coordinator.

bitEngine · October 14, 2026, 3:02am

You’re right, thanks for the correction. I’d read that thread as ending on “the MR1U does Zigbee or Thread” (post #10), but SMLIGHT’s own docs say the MR series runs both at once on separate SoCs, and there’s now MR1/2/3, the U variants, Ultima and SMhub. I’ve edited the OP so it doesn’t misrepresent that.

So, to be concrete about what’s actually different rather than claiming nobody makes this:

Two SoCs instead of three: the ESP32-C5 is the Thread radio itself (native 802.15.4), not a bridge in front of a second radio chip. Trade-off: the optional 5 GHz Wi-Fi uplink time-slices with Thread, which is why I say use Ethernet.
OTBR on the device is the only mode, not an alternate/beta mode. HA talks to it over the OTBR REST API; nothing radio-level crosses the LAN.
5 GHz-only Wi-Fi uplink option, 2.4 GHz deliberately off.
The ESP32 side firmware will be Apache-2.0, not just an ESPHome alternative, plus project config and build scripts for the MG24 image.
Schematics will be published too (CERN-OHL-P), alongside the firmware.

Whether that’s worth anything next to a €55 MR1 is exactly what I’m trying to find out, so “no” is a useful answer too.

zuz242 · October 14, 2026, 4:36pm

I did not use the zigbee on the hub because “dont change a running system”.
Having done the migration from a usb zigbee stick to the SLZB i know the pains of a bumpy migration with many devices.
If i would start anew, i would prefere one multi device over two seperate ones.

bitEngine · October 19, 2026, 11:45pm

Thanks — that answers it, and the migration part is the most useful bit. So for a fresh setup one box wins, but for an existing network the real barrier is moving it, not the box itself. After one bumpy move, “don’t change a running system” is the right call. That changes my test plan. Besides new pairings, I’ll test moving an existing network onto the Hub: - **ZHA**: the built-in radio migration from an existing coordinator (EFR32 first, then CC2652), with the coordinator’s IEEE address carried over so devices shouldn’t need re-pairing — and then back to the old coordinator, so trying it doesn’t lock you in. - **Zigbee2MQTT (ember)**: restoring an ember backup onto the Hub, which is the path for EFR32 sticks like your 06M. Coming from Z-Stack (CC2652) is a different path in Z2M, so I’ll write that one up separately. I’ll post the results here, including any devices that needed a power cycle or re-pair. One question, if you don’t mind: was that move on ZHA or Z2M, and what was the bumpy part — devices that wouldn’t come back without re-pairing, or the tooling itself? Roughly how many devices? That’s exactly the case I’d like to reproduce.

gxhubert · October 30, 2026, 2:48am

Zigbee and Thread both sit in 2.4 GHz, with two antennas in one small enclosure. Have you measured how each side behaves when the other is busy (packet loss or sensitivity drop while the other radio is transmitting)? Channel and antenna separation is the right start, but numbers under load would be really interesting, especially once you move to the final enclosure.

bitEngine · October 30, 2026, 10:23pm

Update: Zigbee2MQTT (ember) passed a full run

Z2M with the ember driver was next on my list. It passed on Oct 27: pairing, reporting and control all work on the current firmware.

Setup


Hub firmware	v1.0.0-86
Zigbee2MQTT	2.14.2, `adapter: ember`, `port: tcp://<hub>:6638`
MQTT	temporary broker; Z2M and the broker each in its own container
Home Assistant	stopped for the duration of the test

Took over the existing network

Before starting Z2M, I read the network parameters off the NCP (read-only): PAN ID, extended PAN ID, network key and channel. They matched the Z2M config, so Z2M picked up the network ZHA had been running instead of forming a new one. It then ran for 9+ hours without a disconnect.

Pairing and interview (all three factory-reset and paired into Z2M)

Device	Result
Third Reality motion sensor 3RMS16BZ	OK; occupied/clear reported both ways, battery 46%
Sengled bulb E11-G13	OK, interview took about 1 s; on/off and brightness work, power reported as 8.5 W
Aqara temp/humidity sensor WSDCGQ11LM	OK; 27.7 °C, 63.4 %, 980.5 hPa

Back to ZHA

After I stopped Z2M and started HA again, ZHA reconnected to the Hub on its own. The three devices kept reporting and responding in ZHA, the two Matter-over-Thread devices stayed online, and the Hub didn’t reboot at any point.

Things that tripped me up

Third Reality 3RMS16BZ: hold “+” for 10 s to factory-reset. 5 s isn’t enough.
Aqara WSDCGQ11LM: short-press its button every 1–2 s during the interview so it doesn’t fall asleep, or the interview tends to stop halfway. Mine also left and rejoined once on its own, then finished fine.
The motion sensor’s IAS enrollment shows as “failed”. That’s a quirk of this device; Z2M has a built-in exception for it and treats it as success.

Context

Z2M had connected before: in July with one temperature sensor, and in September for connection and network only. This is the first time the whole path (pairing, reporting, control) has worked end to end on the current firmware.

Still to do

@zuz242’s case: moving onto the Hub from a different coordinator (ZHA radio migration from EFR32 and CC2652, and restoring a Z2M ember backup). This run switched between ZHA and Z2M on the same Hub, so it doesn’t answer that yet.
The current HA release, and more devices.

The Z2M log (keys filtered out) and the device event log are available if anyone wants to dig in.

bitEngine · October 30, 2026, 10:54pm

Good question, and you’re right that channel and antenna separation is only the starting point.

What we have so far: both networks running at the same time with devices on each side (3 Zigbee devices and 2 Matter-over-Thread devices on one box, including through the Z2M run above). The antennas are 8.5 cm apart (about 0.7 λ at 2.44 GHz), and the firmware keeps the Zigbee and Thread channels as far apart as it can.

What we don’t have yet is numbers under load. The plan:

Antenna-to-antenna isolation (S21) across 2400–2483.5 MHz, in the final aluminium enclosure.
In-house PER: unicast success rate and Thread ping loss on weak links (around -85 to -90 dBm RSSI), aggressor off vs. on.

I’ll post the table here once it’s done, prototype and production enclosure both. If you have a preferred method or a threshold you’d consider “good enough”, I’m happy to include it.

bitEngine · October 31, 2026, 3:09am

Videos of the Hub on camera, one continuous take each, no speed-up:

Home Assistant (ZHA + Thread/Matter): bulb, Aqara P2 door sensor, Eve Energy plug and motion sensor on one box

Zigbee2MQTT (ember driver over TCP)

(Separately, there’s a video of an experimental build that talks to Muse directly on the bitEngineTech YouTube channel.)