Home Assistant can send traffic through any Thread border router in your house, but it can configure only the OpenThread kind. So the box you buy decides whether Home Assistant owns your Thread network or borrows someone else’s. That’s the line this list of the best Thread border routers for Home Assistant draws: four radios that become Home Assistant’s own border router, and the Apple and Google hubs that share a network with it through your phone.
We didn’t have the hardware itself on the bench, so device notes come from maker spec sheets and the Home Assistant docs, and prices are Amazon US on October 20. What we did run is the part every radio pick shares: an OpenThread border router built from source on a simulated radio, wired to Home Assistant in Docker through its REST API on port 8081. We confirmed that handshake working with Home Assistant 2026.10.2 on Ubuntu 26.04 on October 20, 2026.
| Border router | Best for | How Home Assistant uses it | Connection | Price, Oct 20 |
|---|---|---|---|---|
| Home Assistant Connect ZBT-2 | Most Home Assistant setups | Its own border router, fully managed | USB-C | $49 list, out of stock on Amazon |
| SMLIGHT SLZB-06Mg24U | PoE and central placement | Radio over USB, or a border router on the device | Ethernet + PoE, USB-C | about $85 |
| SMLIGHT SLZB-MR3U | Zigbee and Thread in one box | Separate Thread radio beside a Zigbee radio | Ethernet + PoE, USB-C | about $105 |
| SONOFF Dongle Plus MG24 | Lowest cost | Its own border router after a firmware flash | USB-A | about $36 |
| Apple TV 4K (4th generation) | Apple Home households | Shared network, credentials from an iPhone | Gigabit Ethernet | about $290, preorder |
| Google TV Streamer 4K | Google Home households | Shared network, credentials from Android | Gigabit Ethernet | about $149 |
Follow the handshake from the radio to the phone
Three pieces have to agree before a Thread device works in Home Assistant. The radio runs OpenThread RCP firmware and does nothing on its own; the OpenThread Border Router app drives it and exposes a REST API on port 8081 over plain HTTP. Home Assistant’s OpenThread Border Router integration talks to that API, and that’s how Home Assistant can configure the network it owns, from forming it to changing its channel.
The phone is the piece that ties this together. Home Assistant sees every border router on the LAN through mDNS, but those announcements carry no credentials, so an Apple or Google network shows up without a way in. The Companion app moves the credentials in both directions, and the phone then commissions each Matter device onto its own preferred network. After that, Home Assistant’s Matter Server reaches the device over IPv6 through any border router on the mesh, and the traffic stays encrypted end to end.
Read the picks below through that split. A Home Assistant radio covers every step, an Apple or Google hub covers only the mesh side, and a hub whose credentials cannot reach the phone cannot join a shared network at all.
Choose which Thread network Home Assistant joins
Every vendor forms its own Thread network by default, so a home with an Apple TV, a Nest Hub and a ZBT-2 can end up running three of them. The Home Assistant Thread docs are blunt about the cost: they are separate networks with different credentials, and devices “can’t roam between the Thread networks”. One shared mesh is the goal, because every extra router on it improves coverage for all the devices on it.
Setup order decides whether you get one network or two. Home Assistant’s OpenThread border router joins the preferred network only if it hasn’t formed a network yet; otherwise it creates its own, named ha-thread-xxxx. If an Apple or Google network already exists, bring its credentials across before you start the OpenThread Border Router app:
- Put the phone on the same Wi-Fi as the Apple or Google border router: an iPhone for an Apple network, an Android phone for a Google one.
- In the Companion app, open Settings > Connectivity > Thread and select Send credentials to Home Assistant.
- Refresh the screen, then select Make preferred network on the imported network.
- Install the OpenThread Border Router app with your radio, and it joins that network instead of forming a new one.
Going the other way works too. If Home Assistant formed the network first, the Companion app pushes it to the phone. On Android, that’s Sync Thread credentials under Settings > Companion app > Troubleshooting. On an iPhone, it’s Send credentials to phone, at the bottom of the preferred network box under Settings > Connectivity > Thread. That step matters more than it looks. Matter commissioning uses the phone’s preferred network, not Home Assistant’s, so a phone that does not know your network cannot add a Thread device to it.
Pick a border router for Home Assistant
Four of the picks are radios that give Home Assistant an OpenThread border router, the only kind it can configure, either through the OpenThread Border Router app or, on the SMLIGHT boxes, on the device itself. The last two are hubs from Apple and Google that Home Assistant can route through once the credentials are shared. Each comes with the setup step that trips people up.
Home Assistant Connect ZBT-2: best for Home Assistant
The Connect ZBT-2 is Nabu Casa’s $49 adapter, with a Silicon Labs MG24 radio behind an ESP32-S3 USB bridge that runs at 460800 baud, four times the ZBT-1’s rate. It is the only current radio whose Thread setup Home Assistant documents end to end. You pick Use as Thread adapter in the setup wizard, and Home Assistant flashes the firmware. The network lives in Home Assistant rather than on the stick, with a documented migration path when you move it to a new adapter.
One protocol runs at a time. Nabu Casa says it “cannot do both Zigbee and Thread simultaneously” and recommends one device per protocol, so a ZBT-2 already running your Zigbee needs a second one for Thread. Use the 1.5 m USB-C cable in the box to keep it clear of USB 3.0 ports, which Nabu Casa says interfere with 2.4 GHz radios. The Amazon listing Nabu Casa links to was still out of stock on October 21, so the link above goes to Nabu Casa’s product page rather than to a store.
If Zigbee is the job you’re sizing, our Zigbee coordinator guide covers the ZBT-2 in that role and the sticks that pair well with it.
SMLIGHT SLZB-06Mg24U: best for PoE placement
On Amazon, about $85 buys the SLZB-06Mg24U, which puts the same MG24 radio class in a 160 mm stick with 802.3af PoE and USB-C. Its web UI switches it between Zigbee coordinator, Zigbee router and Thread border router. PoE is the reason to buy it: you can mount it in the middle of the house on one cable, away from the server and its USB noise.
Choose how it connects with care, because SMLIGHT’s Thread setup manual offers two modes and only one is clean. Running it as a radio for Home Assistant’s border router over the network is what the OpenThread Border Router app docs warn against: a TCP link to a remote radio can leave devices unreachable “for up to 30 minutes”. Plug it in over USB for that mode, or let it run the border router itself, with Home Assistant connecting to its REST API on port 8080. SMLIGHT still labels that second mode a beta. The Amazon listings for it, from Xnbada and JEB Enterprises, are resellers, not SMLIGHT or Amazon.
SMLIGHT SLZB-MR3U: best for Zigbee and Thread together
The SLZB-MR3U is the honest answer to “one device for both”. It has two radios, a TI CC2674P10 for Zigbee and an EFR32MG24 for Thread, and SMLIGHT says they run “simultaneously, on separate channels”. That’s two radios side by side, not the single-chip multiprotocol firmware that Home Assistant has deprecated, so the advice against multiprotocol does not apply.
JEB Enterprises, a third-party seller, had it at about $105 with 15 left when we checked, and the listing title gets the Zigbee chip wrong (CC2652P10), so go by SMLIGHT’s page. It has the same PoE, Ethernet and connection choices as the 06Mg24U, and the same advice: USB or the on-device border router, not a radio over the LAN. SMLIGHT’s Home Assistant integration has reached Platinum, the top quality tier. Use its Zigbee side with either stack in our ZHA vs Zigbee2MQTT comparison.
SONOFF Dongle Plus MG24: best on a budget
At about $36 the Dongle Plus MG24 has the same MG24 chip class as the ZBT-2, but it ships as a Zigbee coordinator, so Thread starts with a firmware flash. Load the OpenThread RCP image with the SONOFF Dongle Flasher, then add it in the OpenThread Border Router app as a third-party radio. Home Assistant’s docs say to keep the default 460800 baud if the maker doesn’t list one, and that path needs Home Assistant OS.
Sonoff’s flasher also offers MultiPAN RCP firmware, and some launch coverage sold the stick on running Zigbee and Thread from one radio. Do not choose it. Home Assistant’s multiprotocol app now carries a “[deprecated]” label, and Nabu Casa advises a dedicated radio per protocol. At this price, a second stick for Zigbee costs less than the time spent debugging a shared one.
Apple TV 4K (4th generation): best for Apple households
The new Apple TV 4K is about $290 on Amazon as a preorder that ships November 13. Apple’s spec sheet lists Thread, Gigabit Ethernet and Wi-Fi 7 on its single 128 GB model, which removes the old trap: of the two 3rd-generation models, only the Wi-Fi + Ethernet one was a border router. It’s also the home hub Apple Home needs anyway, and of Apple’s current border routers it’s the one you can plug into Ethernet.
For Home Assistant, the iPhone carries the credentials. Send them across from the Companion app, make the network preferred, and an OpenThread border router can then join the Apple network too. Plan for one gap. The Matter integration docs say Matter firmware updates from Home Assistant don’t work for Thread devices on a network with any Apple border router, because Apple’s don’t forward the mDNS needed to find the update provider. A ZBT-2 alongside the Apple TV does not fix that on its own. To update a device from Home Assistant, the docs say to power down every Apple border router, wait at least 30 minutes, then retry, so expect to do that for each firmware round.
Google TV Streamer 4K: best for Google households
Amazon.com sells the Google TV Streamer for $149, with Gigabit Ethernet, and both Google’s border router list and Home Assistant’s docs name it as a border router. That makes it the one current Google border router you can still buy new from Amazon. If you already own a Nest Hub (2nd gen), Nest Hub Max or Nest Wifi Pro, those are border routers too, and you do not need to buy anything.
Google syncs its Thread credentials to your Google account. The Android Companion app sends the phone’s preferred network to Home Assistant with Send credentials to Home Assistant, which is the step that lets an OpenThread border router join the Google mesh instead of forming a new one. Pair it with a ZBT-2 and Home Assistant gets a border router it can configure, on the same network as the Streamer.
Keep these off the shortlist
Several hubs that are border routers don’t make good Home Assistant ones, and the reasons are about the link, not the hardware:
| Device | Why we left it out |
|---|---|
| Amazon Echo and eero | Real border routers, but Amazon exposes the Thread credentials only to Alexa skills, so there is no Companion app import |
| Aqara Hub M200 | About $70 and PoE, but it forms its own network that owners report they cannot merge into Home Assistant’s |
| IKEA DIRIGERA | About $140 from IKEA, not Amazon; one test reached its OpenThread REST API on port 8081, which we couldn’t confirm |
| SwitchBot Hub 3 | A Matter bridge with no Thread radio |
| Connect ZBT-1, Yellow | Discontinued or out of production; fine if you already have one |
| Any radio in multiprotocol mode | Home Assistant’s multiprotocol app is deprecated |
| SONOFF ZBDongle-E | Older MG21 chip, with an owner report of a failed OpenThread flash |
Aqara and IKEA hubs still make sense for their own devices. Treat them as part of the Aqara or IKEA ecosystem, not as Home Assistant’s border router, and give Home Assistant a radio of its own. If the house also runs Z-Wave locks or a Matter presence sensor, our Z-Wave 800 stick guide and mmWave presence sensor picks cover the radios that sit beside this one.
Set up IPv6 routes on a container host
Configure this on the host that runs Home Assistant or the Matter Server, not the border router. Home Assistant OS handles it for you from version 10. On a Linux host running Home Assistant in Docker, or a separate Matter Server box, the host has to accept a route the border router advertises for the Thread prefix. Otherwise it can see the border router but cannot reach a single device behind it.
The route arrives as a Route Information Option inside a router advertisement with a router lifetime of 0, so the border router never becomes your default gateway. Linux ignores those routes unless accept_ra_rt_info_max_plen is at least 64. We reproduced it from a second network namespace on the same bridge, standing in for a separate Matter Server box. Its settings started like this:
sudo ip netns exec lanhost sysctl net.ipv6.conf.eth0.accept_ra net.ipv6.conf.eth0.accept_ra_rt_info_max_plen net.ipv6.conf.eth0.forwardingRouter advertisements were accepted and forwarding was off, but the kernel ignores any advertised route with a prefix longer than the cap, so a cap of 0 drops the /64 Thread route:
net.ipv6.conf.eth0.accept_ra = 1
net.ipv6.conf.eth0.accept_ra_rt_info_max_plen = 0
net.ipv6.conf.eth0.forwarding = 0With that cap, a lookup for the border router’s address on the Thread prefix failed, even though the host had picked up the on-link prefix from the same advertisement:
sudo ip netns exec lanhost ip -6 route get fd84:3565:6fcf:1:4081:ded5:cdae:44dbNo route to the Thread side existed at all:
RTNETLINK answers: Network is unreachableCheck forwarding before you pick the fix, because it changes which value works. Docker turns IPv6 forwarding on when its daemon starts, and on our host the OpenThread install script had already set it:
sysctl net.ipv6.conf.all.forwarding net.ipv6.conf.eth0.forwarding net.ipv6.conf.br0.forwardingAll three were on, which is normal for a machine that routes for containers or for Thread. Our br0 was the lab bridge, so on your host check net.ipv6.conf.all.forwarding plus the key for your own LAN interface:
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.eth0.forwarding = 1
net.ipv6.conf.br0.forwarding = 1The Matter Server OS requirements give the fix for both cases. With forwarding off, accept_ra=1 plus a cap of 64 is enough. With forwarding on, the kernel ignores router advertisements at accept_ra=1, so use 2 instead. Replace eth0 with the interface that faces your LAN:
sudo sysctl -w net.ipv6.conf.eth0.accept_ra=1
sudo sysctl -w net.ipv6.conf.eth0.accept_ra_rt_info_max_plen=64On a host where forwarding is on, which includes most Docker hosts, set accept_ra to 2 instead of the first line:
sudo sysctl -w net.ipv6.conf.eth0.accept_ra=2After the next advertisement, the routing table had a new entry. Check it with ip -6 route on the same host:
sudo ip netns exec lanhost ip -6 routeThe Thread prefix now has a route learned from the advertisement, marked proto ra and pointing at the border router’s link-local address:
fd28:961c:1601:2c6d::/64 dev eth0 proto kernel metric 256 expires 1795sec pref medium
fd84:3565:6fcf:1::/64 via fe80::f013:9bff:fea9:ee72 dev eth0 proto ra metric 1024 expires 1795sec pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref mediumA ping to that same address then came back in under a tenth of a millisecond. We then turned forwarding on in the test namespace to check the other case. At accept_ra=1 the route never came back and the lookup failed with Network is unreachable again; at accept_ra=2 the proto ra route returned and the ping answered. The sysctl -w settings last until a reboot, so put the same two keys in a file under /etc/sysctl.d once they work. The rest of the host and network setup has to line up as well:
- Decide on forwarding on purpose. The Home Assistant Thread docs say a container host needs it on, while the Matter Server docs say to keep it off, because with it on the kernel skips the reachability probing that detects a dead border router, and outages can last up to 30 minutes.
- Run NetworkManager 1.42 or newer if it manages the interface, the minimum the Matter Server docs list.
- Turn off multicast filtering or optimisation and mDNS forwarders on UniFi and Omada gear.
- Keep the border routers, Home Assistant and the phone on one VLAN.
Ubuntu Server adds one more wrinkle. Netplan usually hands the interface to systemd-networkd, which switches off the kernel’s own router advertisement handling and processes advertisements itself, and the Matter Server docs say they have no experience with it. Our demo ran in a namespace that nothing manages, so on a networkd host, check ip -6 route for the Thread prefix rather than trusting the sysctl values.
A NAS that runs Home Assistant in a container may have a kernel built without the IPv6 route support Thread needs, and no sysctl fixes that. If your host is a NAS, the Home Assistant Docker guide is the place to start, and a small mini PC for Home Assistant running Home Assistant OS avoids the problem entirely. One more limit applies to Docker: the Matter docs call running Matter Server as a standalone container unsupported, and say Thread devices need Home Assistant OS, so treat this route fix as necessary but not a guarantee.
Verify the Thread network end to end
Three checks prove the link from the border router to Home Assistant. We ran them on a standalone OpenThread border router host, where ot-ctl and port 8081 are on the host itself. On Home Assistant OS, ot-ctl lives inside the OpenThread Border Router app’s container, so it needs a shell in that container rather than on the host. The app also keeps its REST API on the internal network until you set a host port for 8081 under Show disabled ports in its Network settings. An SMLIGHT running its own border router answers on port 8080 instead. Start on the border router side:
sudo ot-ctl stateA border router that formed or joined a network reports leader or router. Ours was alone on the mesh, so it became the leader:
leader
DoneNext, check the side Home Assistant reads. The REST API is plain HTTP with no login, and the node endpoint returns the network name and role:
curl -s http://127.0.0.1:8081/nodeLook for the state and networkName fields. The output below is trimmed to the lines that matter:
{
"baId": "e02cd8482ec1e41ac65db61fe2d1a247",
"state": "leader",
"routerCount": 1,
"networkName": "HomeThread",
"rloc16": "0x7000",
"extPanId": "28961c1601672c6d"
}The same API serves the active dataset at /node/dataset/active, and that response includes the network key and PSKc in clear text, with nothing to log in to. It also accepts writes to the active and pending datasets, so anything that can reach the port can read your Thread network key or replace the network. Our ot-br-posix build bound it to 127.0.0.1 only, which is the safe default. The exposure is real anywhere the API listens on the LAN. That covers an SLZB running its own border router on port 8080, the Home Assistant app once you give 8081 a host port, and a standalone border router you open up for a remote Home Assistant. Firewall that port to the Home Assistant host.
Finish with the discovery Home Assistant relies on. Border routers announce themselves as _meshcop._udp over mDNS, and this is what Home Assistant’s zeroconf picks up before it offers the Thread integration:
avahi-browse -rt _meshcop._udpThe TXT record names the network (nn) and the Thread version the border router implements (tv). Ours advertised 1.4.0, and the record carries no credentials, which is why Home Assistant can list an Apple or Google network it can’t use. Trimmed to the useful fields:
= br0 IPv6 OpenThread BorderRouter #C448 _meshcop._udp local
hostname = [ot560019af84c3c448.local]
port = [49154]
txt = ["mn=BorderRouter" "vn=OpenThread" "nn=HomeThread" "tv=1.4.0" "rv=1"]Home Assistant did not see it at first. Its zeroconf listened only on the default-route interface, eth0, and the border router announced itself on its own infrastructure bridge. We added that interface through Home Assistant’s network API, the same setting as the Network adapter card under Settings > System > Network, and the Thread discovery card appeared within a second. The Thread panel still reported no border routers until we restarted Home Assistant. In most homes the border router sits on the same LAN as Home Assistant’s default interface, so this only matters when Home Assistant has a second network interface, as our isolated lab bridge was.
Once we added the OpenThread Border Router integration at http://127.0.0.1:8081, the Thread panel listed the HomeThread dataset with otbr as its source. It wasn’t preferred, though. The Thread docs make a new network preferred automatically only when Home Assistant has no preferred network and finds no other border router on it, and ours also saw a stale advertisement from an earlier run. Open Settings > Connectivity > Thread, and if your network isn’t under Preferred network, select Make preferred network on it before you send the credentials to a phone.
