Commissioning to Google Home
Use a minimal bridge and the Google-optimized settings to build a baseline you can verify, finish onboarding in the Google Home app, tidy up sync, rooms and names, and read the type limits of the Google controller correctly.
Google Home is a controller, not an HA sync service
Home Assistant Matter Hub maps the entities you select into a Matter bridge; Google Home takes that bridge into Google's Matter fabric. This path is not the traditional cloud Works with Google Home link: you are not syncing your whole Home Assistant account to Google, you are letting the Google controller manage the endpoints the bridge declares on the local Matter network.
So "sync" means two different things here. A Matter subscription is what keeps reporting device state; the rooms, display names and home data in the Google Home app are managed by the Google ecosystem. Do not expect your HA areas, Dashboard or automations to be copied over wholesale, and do not treat a voice re-sync command as a universal repair step for a fabric.
Check the app, the hub and the local network before you start
| Prerequisite | How to check | Risk |
|---|---|---|
| Google Home app | Update the app, sign in to the Google account you plan to use, and confirm that you can add a device to the target home. | You join the wrong home, or you do not have admin rights. |
| Matter Hub / Thread border router | Use Google's official support list to confirm that the home has a compatible Google hub; the Matter Hub bridge itself runs over the local network and is not a Thread end device. | Remote access and the long-term connection are unstable, or you apply a Thread problem to an Ethernet / Wi-Fi bridge by mistake. |
| IPv6 and mDNS | The phone, the Google hub and Matter Hub can reach each other over local IPv6, and multicast service discovery works between them. | Nothing is found, the join times out, or the device goes offline. |
| Bridge contents | The bridge is running, and the Devices mappings and the filter preview hold only the entities you expect. | A successful join brings in a pile of unsupported or duplicate devices. |
| Persistence backup | Confirm that the data path of the Stable add-on or the container is backed up and survives a restart. | A lost identity leaves Google Home with both an old and a new copy of the bridge. |
The Google Home Optimized template and the Google Home profile
Stable 2.0.55 has two separate concepts here. Google Home Optimized is a bridge template: include all entities, with autoForceSync, battery, humidity and pressure mapping turned on. Google Home is a controller profile: the same set of flags, plus autoComposedDevices. Both are only starting settings, not a Google certification and not a permanent lock; choosing one does not choose the other, and the result is still decided together by the filter, Entity Mapping, the feature flags and the Matter device types Google supports.
Choose the template and the profile separately
A new bridge can use the Google Home Optimized template; the controller step then picks the Google Home profile on its own. Read the flags in both first. Do not infer full compatibility from the name, and do not assume that picking one also picks the other.
Narrow the filter
Start with a small number of basic lights, switches or plugs; exclude unavailable entities, diagnostic entities and new types you have not verified yet.
Preview the mapping
Check the Matter device type, the name and the failure reason item by item. A template will not turn a type Google does not render yet into a usable UI.
Save and set the baseline
After you start the bridge, test the HA state in Matter Hub first, then move on to Google Home commissioning. Once it is onboarded, avoid switching several profiles or flags at the same time.
Release channel, maturity and Google support
| Aspect | Confirmed fact | Conservative reading |
|---|---|---|
| Release channel | This chapter uses only Matter Hub Stable v2.0.55 and the pinned Stable add-on. | Do not cite callback behavior from Testing / Alpha, or screens that are not pinned. |
| Product maturity | The standard bridge, filters, mappings and commissioning are Stable flows. | Multiple entities in Server Mode, the Camera and Security plugins and some Matter 1.4 types are still experimental inside Stable. |
| Google controller | Google publishes which Matter device types Google Home supports and which hubs are compatible. | The upstream manifest does not certify Google type by type; test discovery, control and state reporting yourself. |
Version numbers are layered too: Matter Hub's v2.0.55 is not a Matter specification version, and the Google Home app, the Google hub firmware and Matter device type support each move on their own. Record them separately in your troubleshooting notes instead of writing "everything is on the latest version".
Onboard the bridge in the Google Home app
Freeze the bridge configuration
Use Bridges and Devices in Matter Hub to confirm that the target bridge is running and holds a short list of entities. During commissioning, do not change the port, the network interface, filters, the name or the mappings.
Show the pairing entry point for this session
Open the commissioning window in the bridge's pairing area. Let the Google Home app scan the local QR code directly and nothing else; do not photograph, forward or write down any manual pairing data.
Add a Matter device in Google Home
Start the add-device flow in the Google Home app, choose Matter-enabled device or the equivalent entry on your screen, scan the QR code, and confirm that you are joining the target home.
Keep the app in the foreground until it finishes
Keep the phone where it can reach the local network and avoid a VPN that changes the path; do not restart the Google hub, Matter Hub or the router while this runs. If it times out, first check whether a fabric was in fact created.
Assign the first room and name
Follow the app prompts to assign the representative devices; if there are many endpoints, tidy them room by room after commissioning. Use short, unique names that do not collide with a room name or with a voice name in another ecosystem.
Verify control and the subscription
Operate one low-risk device from Google Home and watch the state in HA; then operate it from HA and confirm that Google Home updates. If control works but the state stays on an old value, look at the subscription rather than commissioning again.
Expand only once it is stable
Once it survives a Matter Hub restart and day-to-day observation, add a small batch of endpoints of the same type. Each time, keep a filter and configuration record you can roll back to.
How Google Home handles sync, rooms and names
| Data | Where it is managed | Expect cross-system sync? |
|---|---|---|
| HA entity state | Home Assistant; reported through the Matter Hub mapping and the Matter subscription. | Verify that updates go both ways, but this does not copy HA history or the Dashboard. |
| Google display name | The Google Home app. | It is not guaranteed to be written back to HA, and it does not sync to Apple or Alexa automatically. |
| Google room | Inside the Google home. | It is not the same as an HA area; multi-fabric does not copy rooms. |
| Voice alias | Name resolution in Google Assistant / Home. | Avoid homophones and duplicates; do not solve this by editing an HA entity_id. |
| Adding or removing an endpoint | The Matter Hub bridge structure. | Controllers can react differently to dynamic bridge changes; test before you make bulk changes. |
The Google ecosystem's "Sync my devices" voice command usually comes up alongside cloud account links; device discovery and subscriptions on a Matter fabric are a different mechanism. If a new endpoint does not appear, look at the bridge structure, at how the controller handles dynamic changes to bridged endpoints and at the Matter Hub Force Sync notes, instead of just repeating the voice sync.
Use the official device-type list to set the limits
The Matter types listed in Google's official documentation are the first layer of evidence for what the Google controller can do. A type that is not listed, that appears only in a newer Matter specification, or that needs a particular cluster should be marked "unknown" or "partial", not written down as supported just because Matter Hub can map it. Even a listed type may get only the basic commands, with advanced modes, energy data, events, service areas or notifications unused by the Google Home UI.
- Rooms are not assigned automatically: v2.0.55 does send the HA area name through FixedLabel, but the major controllers including Google Home do not currently read it to assign rooms; you assign them by hand in the app.
- Standalone ModeSelect has no control UI: Google's published device type list has no standalone ModeSelect, so the app shows generic information without an options control; the Modes in the cloud Google Assistant are a separate, non-Matter path.
- Covers cannot be a Google Home automation action: WindowCovering gives you basic control, but the pinned upstream documentation records that no action is available when you pick an action in Automation; use an HA automation or a voice routine instead.
- Robot vacuum is only partly supported: basic start / stop works, but room selection and cleaning modes vary by Google version; do not claim full support just because the card appears.
- Newer Matter 1.4 types: water heater, energy override and similar types may be no or unknown on Google's list; if the Matter Hub side marks them experimental, disclose that product maturity separately.
Common Google Home pitfalls
The app scans but finds no device
Confirm that the window is still open, that the bridge is running, and that the phone and the Google hub can reach Matter Hub over IPv6 / mDNS. Turn off a VPN that changes the path and try again. Do not publish the pairing data.
It stalls at connecting or preparing the device
Keep the app in the foreground and stop making other network changes; check whether a Google fabric has already appeared in Matter Hub. If it has, do not rescan straight away, which leaves you with duplicates and an unclear state.
Some endpoints do not appear
Look at the Devices mappings and the filter first, then compare them against Google's official supported device types. Use a basic light on the same bridge as your reference; split special types out into their own test.
Control works but the state lags
Compare HA against Google Home and watch the session and the subscription; check the Google subscription behavior pinned in upstream v2.0.55, and do not make removing the fabric your first step.
Rooms or names do not match HA
This is not a sync failure. The Google room and name are controller data; tidy them in Google Home, and avoid changing names on the HA, bridge and Google layers at the same time.
Duplicate bridges after a restart
Stop commissioning again, check the persistent data and the stable identity, and keep the existing fabric. Back up first and check whether the bridge lost its original identity, then plan the cleanup on the controller side.