Matter, Thread, and Border Routers: How Matter Devices Actually Connect to Home Assistant

Matter is supposed to be the standard that makes smart home shopping simple. In practice, the moment you look past "just buy anything with the Matter logo," you run into Thread, Thread Border Routers, IPv6, and commissioning, and none of it is explained in plain language anywhere. This trips up a lot of people, including folks who have been building smart homes for a while. This guide breaks down what each piece actually is and how they connect to Home Assistant, without assuming you already know networking.

Quick Answer

• Matter is a smart home standard, not a radio. It runs over one of two transports: Wi-Fi or Thread.
• Matter-over-Wi-Fi devices connect directly to your existing Wi-Fi network, no extra hardware needed.
• Matter-over-Thread devices join a low-power mesh network (Thread) that needs a Thread Border Router (TBR) to bridge it onto your home network so Home Assistant can reach it.
• Thread runs on IPv6 only, so your router and network need IPv6 support for Thread devices to work.
• Home Assistant can be its own Thread Border Router using a Thread-capable USB dongle, or it can join a Thread network that already exists from something like an Apple TV, HomePod mini, Google Nest Hub, or eero router.

What Matter actually is

Matter is a standard, not a wireless technology of its own. It defines a common language so that a lock from one brand and a hub from another brand can understand each other, instead of every manufacturer inventing its own app and protocol. We cover the bigger picture of Matter versus other protocols in our Matter 1.6 vs Zigbee guide, and if you want the full rundown of Wi-Fi, Bluetooth, Zigbee, Z-Wave, and Matter side by side, our smart home protocols guide covers that. For this article, the short version: Matter devices still need to physically get their data across your home network somehow, and that's where "transport" comes in.

Matter supports two transports:

• Wi-Fi – the device connects straight to your home Wi-Fi, same as your phone or laptop.
• Thread – the device joins a separate low-power mesh network called Thread, which then needs to be bridged into your home network.

A device is either "Matter over Wi-Fi" or "Matter over Thread." It's usually printed on the box or listed in the product spec, since the device's hardware only supports one or the other.

Matter over Wi-Fi vs Matter over Thread

Here's what each one actually needs to work:

Matter over Wi-Fi is simpler to set up because there's nothing extra to install, but it comes with the same trade-offs as any Wi-Fi smart device: it's a mains-powered connection that adds one more client to your router, and it depends on your Wi-Fi coverage reaching that exact spot. We've written before about why leaning too heavily on Wi-Fi for a smart home causes problems as the device count grows, and that applies to Matter-over-Wi-Fi devices too.

Matter over Thread avoids that by using a mesh, similar in spirit to Zigbee, where devices are low-power and can relay data for each other. The catch is that a Thread mesh isn't directly reachable by your phone, your router, or Home Assistant, since it speaks a different language on a different radio. Something has to translate between the two, and that's the Thread Border Router.

What is Thread, and why does it need a Border Router?

Thread is a low-power mesh networking protocol, built for the same kind of always-on battery sensors and locks that Zigbee handles. The key difference from Zigbee is that Thread devices communicate using IP addresses (specifically IPv6) natively, instead of a proprietary format that only a dedicated coordinator understands.

That sounds like it should make things simpler, and in one way it does: an IP-based device is, in theory, reachable like anything else on a network. But your phone, laptop, and Home Assistant only understand Wi-Fi and Ethernet. They have no radio for Thread. So even though a Thread device technically speaks IP, nothing on your normal network can hear it directly.

A Thread Border Router (TBR) is the device that solves this. It has one foot in each world: it has a Thread radio to join the mesh, and it sits on your regular Wi-Fi or Ethernet network. It bridges the two, so that when Home Assistant sends a command over your network, the border router forwards it into the Thread mesh, and vice versa.

Here's how that path looks, end to end:

Matter-over-Thread device (e.g. a door sensor)
        |
        v
  Thread mesh network
        |
        v
  Thread Border Router  <-- bridges Thread to your home network
        |
        v
  Your home network (Wi-Fi / Ethernet)
        |
        v
     Home Assistant

Without a Thread Border Router somewhere on your network, Home Assistant has no path to a Matter-over-Thread device at all, no matter how close it is physically.

Why does Thread need IPv6?

Thread's mesh addressing is built entirely on IPv6, which is why every Thread device gets its own individual IPv6 address rather than being addressed indirectly through a coordinator (the way Zigbee works). This is part of how Thread devices can be reached more directly once they're bridged onto your network.

The practical implication for your home: your router needs IPv6 support turned on for Thread to work properly. Most routers sold in the last few years support IPv6 out of the box, but some ISP-issued routers ship with it switched off by default, so it's worth checking your router's settings for an IPv6 toggle if a Thread Border Router isn't behaving as expected.

Setting up a Thread Border Router for Home Assistant

There are two ways Home Assistant gets access to a Thread network, and you may not even need to buy anything extra.

Do you already have an Apple TV 4K, HomePod mini, Google Nest Hub
(2nd gen or newer), eero router, or a third-party hub like an
Aqara Hub M2/M3 at home?
        |
        +-- Yes --> One of these is likely already running as a Thread
        |           Border Router for its own ecosystem. Home Assistant's
        |           Thread integration can detect and join that existing
        |           Thread network, so no extra hardware is needed.
        |
        +-- No  --> Plug a Thread-capable USB dongle (e.g. Home Assistant
                     Connect ZBT-1) into your Home Assistant hardware.
                            |
                            v
                     Enable the OpenThread Border Router (OTBR)
                     add-on in Home Assistant.
                            |
                            v
                     Home Assistant creates its own Thread network
                     and becomes the Border Router for it.

Both paths get you to the same place: a Thread network that Home Assistant can see and route traffic through. Running Home Assistant as its own border router gives you a network you fully control end to end. Joining an existing Apple, Google, or eero Thread network means less hardware to manage, since Thread supports multiple border routers sharing the same mesh for redundancy, so Home Assistant joining an existing network doesn't take it away from the ecosystem that set it up.

One practical note if you're using a USB dongle: like Zigbee dongles, Thread dongles are sensitive to interference from USB 3.0 ports and other high-speed devices nearby. If you're seeing an unreliable Thread network, moving the dongle onto a USB extension cable away from your Home Assistant hardware is a common fix.

What about third-party gateways like Aqara hubs?

Apple, Google, and eero aren't the only Thread Border Routers out there. Several third-party smart home hubs have added Thread support through firmware updates, and the Aqara Hub M2 and M3 are common examples of this: on top of their existing Zigbee support, they can also host a Thread network and act as a Border Router for it.

Whether Home Assistant can actually use that Thread network comes down to whether the hub shares its Thread network credentials with other Border Routers. Thread has a standard mechanism for this, where Border Routers from different ecosystems (we compare Apple, Google, and local-first platforms like Home Assistant in our smart home platforms guide) can sync up automatically. That's how an Apple HomePod and a Google Nest Hub can end up sharing one Thread network without you doing anything manually.

We've actually done this in our own test lab, with an Aqara hub and Home Assistant on the same Thread network. Here's what that looks like from inside Home Assistant's Thread panel (Settings > System > Network > Thread):

Network name: AqaraHome-b543
Channel: 11
PAN ID: b543
Extended PAN ID: f5a6580ed953b548
OTBR URL: http://core-openthread-border-router:8081

Two things confirm it worked. First, the network name starts with "AqaraHome-", which is Aqara's own naming convention, telling us the Aqara hub created this network. Second, Home Assistant's own OTBR add-on is reporting this exact same network (matching PAN ID and Extended PAN ID), rather than a different one of its own. That means Home Assistant joined the Aqara hub's network instead of creating a separate, competing one, which is the outcome you want.

Do you actually need Home Assistant's own OTBR add-on?

Not necessarily. The OTBR add-on's job is to let Home Assistant host its own Thread network. If a third-party Border Router, like an Aqara hub, is already on your network and sharing its credentials properly, Home Assistant's Thread integration can pick up that existing network on its own, without Home Assistant needing to run its own OTBR add-on at all.

The OTBR add-on becomes necessary when:

• You have no other Thread Border Router on your network at all, so something needs to create the network in the first place.
• You want Home Assistant to act as an additional Border Router for redundancy, so your Thread devices stay reachable even if the third-party hub goes offline or gets reset.

In our test lab, Home Assistant ended up running its own OTBR add-on alongside the Aqara hub, which is why the example above shows two Border Routers sharing one network rather than Home Assistant just quietly using the Aqara hub's. If you already have a working third-party Border Router and don't need that extra redundancy, you can skip the OTBR add-on and let Home Assistant simply join the existing network.

Do multiple Thread Border Routers conflict with each other?

No. Having more than one Thread Border Router on your network, say an Aqara hub and an Apple HomePod mini, is not just fine, it's how Thread is designed to work. Multiple Border Routers on the same Thread network act as redundant paths into the mesh: if one goes offline, your devices stay reachable through the other. Think of it like having two Wi-Fi access points repeating the same network for coverage, not two separate Wi-Fi networks competing for the same devices.

What can look like a conflict is actually something different: two hubs running two separate Thread networks with different credentials, instead of sharing one. In that case, a device joined through the Aqara hub and a device joined through the HomePod are simply sitting on two different meshes, and Home Assistant can only reach devices on whichever Thread network it holds the credentials for. That's fragmentation, not a conflict, and it's exactly what cross-vendor Thread credential sharing is meant to prevent by keeping every Border Router on your network in sync on one shared Thread network.

How to make sure your Border Routers share one network, not several

A Thread network is defined by a set of credentials (its network name, PAN ID, network key, and so on). Whichever Border Router you set up first generates this set and creates the network. Every Border Router you add after that either receives the same credentials and joins that network, or fails to receive them and creates its own separate network instead. A few practical habits keep you on the first path:

• Set up your Border Routers one at a time, not all at once. Get your first one running and stable before adding a second, so there's an existing network for the next one to detect and join.
• Watch for a "join existing Thread network" prompt when setting up each new Border Router. Most ecosystem apps scan for an existing network during setup and ask before creating a new one; if an app skips straight to creating a network without asking, it likely made its own.
• Verify after the fact rather than assuming. Compare the Thread network name or Extended PAN ID shown in each app against what Home Assistant shows under Settings > System > Network > Thread. Matching names mean one shared network; different names mean fragmentation, even if every hub is sitting in the same room.
• In Home Assistant specifically, if another ecosystem's Thread network already exists in your home, the Thread integration can import that same credential set when you add a Border Router to Home Assistant, so it joins the existing mesh instead of starting a new one.

How reliably this "join instead of create" behaviour happens automatically depends on the specific vendors involved. It's well supported between the larger ecosystems (Apple, Google), and our own test lab confirms it also works with Aqara, as shown in the example above. Behaviour can still vary with vendors outside of what's covered in this guide, so if you're working with a different brand, checking its current documentation is a reasonable extra step.

Commissioning a Matter device into Home Assistant

"Commissioning" is just the term Matter uses for the pairing process, the step where a brand-new device gets introduced to your network and your Matter fabric (the shared trust network your devices belong to). Here's what that looks like in Home Assistant:

Settings > Devices & Services > Add Integration > Matter
        |
        v
Scan the QR code, or enter the 11-digit pairing code
from the device or its box
        |
        v
Home Assistant commissions the device onto its Matter fabric
        |
        v
If it's a Matter-over-Thread device: Home Assistant also hands
it your Thread network's credentials during this step
        |
        v
Device joins the Thread mesh (or connects via Wi-Fi) and
appears as a device in Home Assistant

This is the same basic flow whether the device is Matter over Wi-Fi or Matter over Thread. The difference happens behind the scenes: a Wi-Fi device just needs your Wi-Fi password, while a Thread device also needs the Thread network credentials, which Home Assistant only has if it's already set up as (or joined to) a Thread Border Router. This is why getting the Thread Border Router working first matters. Skip that step, and commissioning a Matter-over-Thread device will fail or stall, since there's no Thread network for it to join.

Is Matter local, and what happens if your internet goes down?

Yes, Matter is designed to be local. When Home Assistant sends a command to a Matter device, whether over Wi-Fi or bridged through a Thread Border Router, that traffic goes directly between Home Assistant and the device over your local network. It never has to leave your house and round-trip through a manufacturer's cloud server, unlike older cloud-dependent Wi-Fi devices where even a same-room command goes app to cloud to device.

The dependency that actually matters here is your router and local network, not your internet (WAN) connection specifically. A typical "internet is down" situation means your ISP link has dropped, but your router usually keeps your local Wi-Fi network running fine regardless. Since Matter communication is local, devices should keep responding to Home Assistant through that kind of outage, as long as Home Assistant itself is running locally on your own hardware rather than depending on a cloud-hosted instance. We've covered why this local-first approach matters more broadly in our guide to local control.

A few things do still depend on the internet being up, even with Matter:

• Remote access. Controlling your home from outside your Wi-Fi, like checking a camera feed while you're at work, needs internet, since that's how your phone reaches your home network at all. This applies to any home automation setup, not something specific to Matter.
• Cloud voice assistants. If you control a Matter device by saying "Hey Siri" or "Hey Google," that voice command gets processed in the cloud first, so it stops working even though the device itself would still respond fine to a local command.
• First-time commissioning. Pairing a brand-new Matter device typically expects the setup app to have internet access to complete the process, even though the device works locally afterward.
• Non-Matter extras bundled into a device. Things like a camera's cloud video storage or a robot vacuum's cloud-based room mapping are separate features added by the manufacturer, not part of Matter's control layer, so they can stop working independently of whether Matter itself is functioning.

FAQ