Matter bridges, and the features that do not survive one

What a bridge is at the protocol level#

To your controller, a bridge is a single Matter node that happens to have a lot of endpoints.

• Endpoint 0 is the root node, as on any Matter device. It holds the descriptor, basic information, access control and operational credentials clusters.
• An aggregator endpoint declares that this node is a bridge. Its parts list points at every device it is exposing.
• Bridged node endpoints, one per device behind the bridge, each carry a bridged device basic information cluster (vendor name, product name, reachability, a unique ID) plus the application clusters for whatever that device type is: on/off, level control, color control, door lock, window covering, and so on.

Two practical consequences fall straight out of that model.

The bridge is one fabric slot, not fifty. Because everything behind it lives inside one node, sharing a bridge with a second ecosystem costs a single slot against the five-fabric floor. For a house with forty Zigbee bulbs, that is a genuine advantage over pairing forty Matter devices individually.

The bridge is one point of failure. Reboot it, brick it, or lose its cloud account, and every device behind it vanishes from every ecosystem at once. A native Matter device keeps working when its neighbor dies. A bridged one does not.

If the words hub, bridge, controller and border router still blur together, the four terms are separated here.

What actually gets lost#

The generic answer is "vendor-specific features", which is useless at the shelf. Here is the concrete version, with named products.

Philips Hue: dynamic scenes and entertainment mode#

The Hue Bridge can expose its lights over Matter. Home Assistant's own documentation recommends against doing it, and the reason is capability, not reliability: Matter carries basic light control, while the native Hue integration carries dynamic scenes and entertainment mode, which is the low-latency streaming mode used for screen and music sync. Bridge Hue into Matter and a dynamic scene becomes a static color, and entertainment mode is simply absent.

The Hue Bridge also caps at 150 bridged lights. That is generous for a house and a real constraint for anyone who has been buying Hue since the first generation. The wider trade-off between bulbs, switches and fixtures is in smart lighting that stays compatible.

Every bridged device: no firmware updates over Matter#

This is the loss people notice last and regret most. Firmware updates for bridged sub-devices are never available over Matter. The bridge itself can be updated by its manufacturer, but the bulbs, sensors and locks behind it have to be updated in the vendor's own app.

So the vendor app you were hoping to delete stays installed, with its account, its cloud connection and its notifications. Bridging reduces how often you open that app. It does not remove the dependency.

SwitchBot Hub 2: some device classes, not all#

SwitchBot's Hub 2 exposes curtain, lock and blind devices over Matter, but not light. If your reason for buying the hub was to get SwitchBot lighting into Apple Home, that specific path is not there. This is the normal shape of the problem: a bridge supports the device types its manufacturer chose to map, and the gaps are rarely on the box.

Aqara M3: set up in the vendor app first#

The Aqara M3 must be set up in the Aqara app before it can bridge anything. That is not unusual, and it is worth planning for: the bridge is a product of its ecosystem first and a Matter device second. Expect an account, an app and a first-run flow before any Matter code appears.

Lighting effects, everywhere#

Effects are the most commonly stripped feature across all bridges and all vendors. Govee-style animations, candle flicker, chase patterns and multi-zone gradients reduce to on, off, dim and a solid color once they cross into standard Matter clusters. This is a limitation of the Matter lighting device types rather than of any one bridge.

What survives, reliably#

Not everything is bad news. Bridged devices generally keep:

• On, off and brightness for lights, plus color and color temperature where the underlying device supports it.
• Open, close and position for shades and curtains.
• Lock, unlock and lock state for locks, minus vendor credential management.
• Sensor readings: motion, contact, temperature, humidity, illuminance.
• Local operation, if the bridge itself is local. A Zigbee bridge on your LAN keeps working during an internet outage. A bridge that is really a cloud connector does not, which is why local versus cloud control matters more than the bridge label.

When bridging is the right answer#

And when it is not:

• When a good native integration already exists. If you run Home Assistant, the native Hue, SwitchBot or Aqara integrations expose more than the Matter bridge does. Use Matter to reach the ecosystems that have no other option.
• When the feature you care about is the feature that gets stripped. Screen sync, dynamic scenes, per-button scene control on multi-button remotes.
• When you were bridging to delete an app. You will not be deleting it.

Bridges versus native Matter devices#

The honest summary: a bridge is a compatibility layer, and compatibility layers trade capability for reach. That is a good trade for a drawer of Zigbee sensors and a bad trade for the one product you bought specifically for its effects engine.

Migrating without downtime#

If you are moving an old setup onto standards, bridge first and replace later. Keep the vendor hub, add the bridge, confirm everything appears in your main ecosystem, then replace devices individually when they fail or when a feature gap starts to bite. The ordered version of that plan is in upgrading an old smart home, and the platform-switching order of operations is in switching platforms without rebuying.