Bridged vs native pairing
Many devices can join your ecosystem two ways: natively (paired directly to your hub’s radio or via Matter) or bridged (paired to the maker’s hub, which represents it onward — a Hue bulb via the Hue Bridge, an Aqara sensor via an Aqara hub). Native pairing removes a box and a hop; bridging keeps the maker’s full feature set, firmware updates, and a dedicated radio network.
The trade-off is concrete with Hue as the example. Pair a Hue bulb directly to a Zigbee coordinator (Hubitat, Zigbee2MQTT, ZHA) and you skip the Bridge entirely — but you lose the Hue app’s scenes, entertainment sync, and easy firmware updates, and the bulb now shares your general Zigbee mesh. Keep the Bridge and expose it as a Matter bridge, and every bulb appears in Apple Home or Google Home while retaining everything the Hue app offers.
A useful default: bridge when the maker’s hub adds real value or you own many devices of one brand (Hue, Aqara, IKEA); pair natively when you want fewer hubs, one mesh to strengthen with routers, or features only a DIY platform exposes. Watch the constraint in the other direction too — a bridged device is only as capable as the bridge’s Matter implementation. Our guide on how Matter bridges work walks through what carries over and what stays app-only.