Key points
- A bridge belongs to two networks: Matter on the IP side, and Zigbee, Z-Wave, Bluetooth Mesh or a vendor protocol on the other.
- Each device behind it appears to Matter controllers as its own endpoint, with its own device type, name and reachability.
- It is not a controller, which commissions and controls devices, and not a Thread border router, which routes IP packets for native Matter devices.
- Apple Home, Google Home, Amazon Alexa, SmartThings and Home Assistant all document support for devices exposed through Matter bridges.
Matter bridge role in a smart home
A Matter bridge makes devices on another network look like Matter devices. Google’s Matter primer describes a bridge as a member of both a Matter network and another smart home technology, such as Zigbee, Bluetooth Mesh or Z-Wave, which lets those devices be operated as if they were native Matter devices. The Connectivity Standards Alliance (CSA) puts it the same way in its Matter FAQ: Matter supports bridges that allow devices using other protocols, such as Zigbee or Z-Wave, to participate in a Matter ecosystem.
Bridges exist because Matter does not speak those radios natively. The CSA says Matter natively supports Wi-Fi, Ethernet and Thread. A Zigbee bulb and a Thread bulb can use the same IEEE 802.15.4 radio, but the network and application layers above it differ, so a Matter controller cannot talk to the Zigbee bulb without something translating.
In a typical home the bridge is the hub you already own. Home Assistant’s Matter documentation names the SwitchBot Hub 2, Aqara Hub M2, IKEA DIRIGERA and the Philips Hue Bridge as examples of Matter bridges. You pair devices to the bridge in its maker’s own app, then add the bridge to your Matter controller once, and its devices come with it.
Bridged devices in the Matter data model
A bridge exposes each bridged device as a separate endpoint in the Matter data model. The Matter SDK’s copy of the data model defines an Aggregator device type (0x000E) for the endpoint that collects the bridged devices, and a Bridged Node device type (0x0013) for each device behind it. Every bridged endpoint also carries the Bridged Device Basic Information cluster, which holds the device’s vendor, product name, serial number and a Reachable attribute, with a ReachableChanged event when that flips.
Bridged devices come and go at runtime. The Matter SDK’s Linux bridge example adds three lights as dynamic endpoints, removes one, adds another, and re-adds the removed light at a new endpoint ID. Each light carries the On/Off, Descriptor, Bridged Device Basic Information and Fixed Label clusters, so a controller sees an ordinary Matter light with a name and a room.
Controllers then treat bridged devices like any other. Google’s developer docs say all devices behind a Matter bridge appear as normal for a user in Google Home, while the bridge itself appears as an inert device.
Matter bridges, controllers, hubs and border routers
Bridges, controllers, hubs and border routers do different jobs, and one box often does several. A bridge translates another network into Matter. A controller commissions Matter devices and sends them commands. A Thread border router routes IP traffic between a Thread mesh and Wi-Fi or Ethernet. “Hub” is a product word for a box that combines some of these.
| What it does | Talks to non-Matter devices? | Examples from vendor docs | |
|---|---|---|---|
| Matter bridge | Presents devices on another network as Matter devices | Yes, that is its job | Philips Hue Bridge, IKEA DIRIGERA, Aqara Hub M2, SwitchBot Hub 2 (named by Home Assistant) |
| Matter controller | Commissions devices into its fabric and controls them | No, only Matter devices and bridges | Home Assistant, Google Home hubs, Apple home hubs, Amazon Echo devices |
| Thread border router | Routes IPv6 between Thread and Wi-Fi or Ethernet, and publishes discovery for Thread devices | No, it carries native Matter over Thread devices | Apple TV 4K, HomePod mini, Nest Hub (2nd gen), many Echo models |
| Hub | A product that can combine controller, border router and bridge | Depends on what is inside | SmartThings hubs, home hubs from Apple, Google and Amazon |
The easiest way to keep them apart: a border router carries traffic for devices that already speak Matter, and a bridge stands in for devices that do not. A Matter over Thread lock needs a border router. A Zigbee motion sensor needs a bridge. Home Assistant’s own documentation draws the controller line clearly: Home Assistant, as a Matter controller, only supports control of Matter devices, is not a bridge itself, and cannot turn existing devices into Matter devices.
Smart home apps with Matter bridge support
All the large ecosystems document support for bridged devices:
- Apple Home lists bridges among the Matter accessory types the Home app supports.
- Google Home shows devices behind a bridge as normal devices, and the bridge as an inert device.
- Amazon Alexa documents non-Matter devices exposed by a Matter bridge in its developer docs.
- SmartThings says many brands have announced that their hubs will act as Matter bridges for SmartThings users.
- Home Assistant can add non-Matter devices from ecosystems such as Hue, IKEA, Aqara and SwitchBot through their Matter bridges.
There are also software bridges. Matterbridge is an open-source Matter plugin manager, licensed Apache-2.0 and built on matter.js, that creates a Matter device of type bridge on Linux, macOS or Windows and loads plugins for the devices behind it.
Zigbee and Z-Wave devices in Matter
Bringing Zigbee and Z-Wave devices into Matter is the main reason bridges exist. The CSA says there is no native interoperability between Matter and Zigbee devices, and names Zigbee and Z-Wave as examples of protocols that join Matter through bridges. The bridge still needs its own Zigbee or Z-Wave radio and network, so the Zigbee devices keep using their own mesh and only the bridge talks Matter.
This is why a bridge suits an existing installation. A home with dozens of Zigbee bulbs on a Hue Bridge or DIRIGERA can bring them into a Matter controller without replacing any of them.
Matter bridge limitations
A bridge passes on only what both sides understand, and it adds one more box that everything behind it depends on:
- Device types. A bridged device shows up only if the bridge maker maps it to a Matter device type and the controller supports that type. Google, for example, says device types other than the ones it lists are not officially supported in Google Home.
- Features. Anything the other network can do that has no Matter equivalent stays in the bridge maker’s app, so check which features the bridge exposes before you rely on them from another ecosystem.
- A single dependency. Every command to a bridged device goes through the bridge. If it loses power or its network link, all of its devices become unreachable from Matter, which the Reachable attribute reports.
- Two setups. Devices are paired to the bridge in its own system first. Adding, removing or renaming them happens there, and the Matter side follows.
Offline Protocol and the gateway pattern
A Matter bridge is an example of the gateway pattern: one device sits in two networks and presents one to the other. Offline Protocol is not a Matter bridge, does not speak Matter, Zigbee or Z-Wave, and does not control smart home devices. It uses the gateway pattern at the app level instead. Its Python package runs a full peer on a Linux or desktop gateway, with Bluetooth LE, internet and local network transports, and a local service with an HTTP front lets a program that does not use the SDK call a service on another device with one plain HTTP request.