A controller builds its own devices. It does not import your Home Assistant account

Home Assistant Matter Hub maps the entities you choose into a Matter bridge. What happens next depends entirely on who commissions that bridge. Google Home takes it into Google's Matter fabric and builds Google devices out of the Matter device types and clusters the bridge declares. Alexa does the same for its own fabric. Neither one understands your Home Assistant Dashboard, your areas, or your automations — they only ever see what the bridge exposes as Matter.

That is why the word "sync" causes so much confusion in both apps. A Matter subscription is the mechanism that keeps a device's on/off state, its brightness, its sensor reading flowing between Home Assistant and the controller, in both directions, for as long as the fabric exists. The room a device sits in, the name it is given, and the voice alias it answers to are a completely different kind of data — they live inside that controller's own app, and nothing in the Matter subscription carries them back to Home Assistant.

This part covers Google Home and Alexa back to back, the same order the upstream documentation follows for Stable 2.0.55. Part 8 covered Apple Home; Part 10 lines all three controllers up side by side once you have been through each one individually.

The checklist that saves you a wasted commissioning window

Both apps fail in the same handful of ways when the network underneath them is not ready. Go through the relevant table before you open a pairing screen, not after the first attempt times out.

Google Home checklist

Alexa checklist

A template, a profile, and a decision that is still made by five other things

Stable 2.0.55 gives you two Google-flavored settings that look interchangeable and are not. Google Home Optimized is a bridge template: it turns on including all entities, plus autoForceSync, battery mapping, humidity mapping, and pressure mapping. Google Home is a controller profile: the same set of flags, plus autoComposedDevices. You can pick the template on a new bridge and the profile at commissioning time independently — choosing one never chooses the other for you.

flowchart TD
  T["Google Home Optimized
a bridge template"] --> F["What Google Home
actually renders"]
  P["Google Home
a controller profile"] --> F
  Filt["The filter"] --> F
  Map["Entity Mapping"] --> F
  Types["Matter device types
Google publishes as supported"] --> F

Neither setting is a Google certification and neither is permanent. Both are starting points you can revisit.

1. Step 1

   Choose the template and the profile separately

   Give a new bridge the Google Home Optimized template, then pick the Google Home profile on its own at the controller step. Read the flags each one turns on before you rely on the name. Do not infer full compatibility from either label alone, and do not assume selecting one selects the other.

2. Step 2

   Narrow the filter

   Start with a small number of basic lights, switches, or plugs. Exclude unavailable entities, diagnostic entities, and any type you have not personally verified yet.

3. Step 3

   Preview the mapping

   Check the Matter device type, the name, and the failure reason for each entity, one at a time, in Entity Mapping. A template does not turn a device type Google cannot render yet into a usable card.

4. Step 4

   Save, start, and set your baseline before touching Google Home

   Start the bridge and confirm the HA state is correct inside Matter Hub itself first. Only then move to Google Home commissioning. Once it is onboarded, avoid flipping several profiles or flags at once — you will not know which change did what.

5. Step 5

   Freeze the configuration for the session

   Use Bridges and Devices in Matter Hub to confirm the target bridge is running with a short entity list. While the pairing window is open, leave the port, network interface, filters, name, and mappings untouched.

6. Step 6

   Scan, add, and stay in the foreground

   Open the bridge's pairing area and let the Google Home app scan the local QR code directly — never photograph it, forward it, or write down the manual pairing data. In the app, start Add device, choose Matter-enabled device or whatever your version calls that entry, confirm you are joining the target home, and keep the phone on the local network with no VPN change until it finishes. Do not restart the Google hub, Matter Hub, or the router mid-flow. If it times out, check first whether a fabric was created anyway before you try again.

7. Step 7

   Assign a room and name, then verify both directions

   Follow the app's prompts to assign the first devices to a room; tidy the rest room by room afterward if there are many. Use short, unique names that do not collide with a room name or with a name you already used in another ecosystem. Then operate one low-risk device from Google Home and watch HA update, operate it from HA and watch Google Home update. If control works but the state stays stuck on an old value, look at the subscription rather than commissioning again. Only expand once it survives a Matter Hub restart and a day of normal use.

Rooms, names, and sync belong to Google, not to HA

Once a device is commissioned, five kinds of data behave differently, and mixing them up is the single most common source of "why didn't that sync" questions.

Saying "Sync my devices" to the Google ecosystem is a cloud-account-link command, and device discovery on a Matter fabric is a different mechanism entirely. If a new endpoint refuses to appear, check the bridge structure and how the controller handles a dynamic change to bridged endpoints before you repeat that voice command a third time.

Use Google's own device-type list to set your expectations

Google's official documentation of which Matter device types it supports is the first layer of evidence for what its controller can actually do. A type that is not on that list, that only exists in a newer Matter specification, or that needs a particular cluster should be recorded as unknown or partial — never as supported just because Matter Hub is able to map it.

• Rooms are not assigned automatically. Stable 2.0.55 does send the HA area name through the FixedLabel cluster, but Google Home does not currently read it to assign a room. You still assign rooms by hand in the app.
• Standalone ModeSelect has no control UI. Google's published device-type list has no entry for a standalone ModeSelect, so the app shows generic information with no options control. The Modes feature inside the cloud Google Assistant is a separate, non-Matter path.
• Covers cannot be a Google Home automation action. WindowCovering gives basic control, but the pinned upstream documentation records that no action is available when you pick an action in Google's own Automation feature. Use an HA automation or a voice routine instead.
• A robot vacuum is only partly supported. Basic start and stop work; room selection and cleaning modes vary by Google version. A card appearing is not proof of full support.
• Newer Matter 1.4 types — water heater, energy override, and similar — may be marked no or unknown on Google's list. If Matter Hub's own side marks them experimental, disclose that separately rather than folding the two facts into one.

Why the first Alexa commissioning has to land on port 5540

The pinned v2.0.55 documentation states this plainly: after Alexa completes its AddNOC step against a bridge on any other port, the commissioning rolls back anyway. Only a bridge currently running on 5540 can finish Alexa's first commissioning. In practice, that means keeping one core Alexa bridge permanently on UDP 5540 and onboarding a small, deliberate set of devices to it. Other controllers are free to join bridges on other ports, or to join that same core bridge as an additional fabric later.

flowchart TD
  A["The bridge you are about
to hand to Alexa"] --> B{"Is this the first bridge
Alexa will ever commission?"}
  B -->|"no, a fabric already exists"| C["Alexa can join it as an
additional fabric, on any port"]
  B -->|"yes, this is the first"| D{"Is it running on
port 5540 right now?"}
  D -->|"yes"| E["AddNOC completes.
Commissioning succeeds"]
  D -->|"no"| F["AddNOC rolls back.
Move the core bridge to 5540 first"]

Keep the three rules apart in your head, because it is easy to blur them into one vague sense that "Alexa is fussy." Port 5540 solves first-commissioning compatibility, nothing else. The practical device count in the next section is a planning range, not a port rule. And the compatibility flags after that fix specific UI and command differences — they do not touch the port at all. Do not let one of the three explain a failure that actually belongs to another.

• 5540 is a local Matter service port. Never forward it to the internet, and never expose it publicly to "help" Alexa find the bridge from outside.
• If two bridges on the same host both want 5540, do not let them fight over it. Decide up front which one is the core Alexa bridge.
• Changing the port after commissioning adds real risk. Back up first, assess every existing fabric, and pick a maintenance window — do not swap ports casually to run a quick test.
• Treat a "not on 5540" warning as an Alexa-specific compatibility risk first. It does not mean your other controllers are about to fail too.

About 80–100 devices, and four flags built for Alexa's blind spots

Where the upstream documentation gives about 80–100 bridged devices as practical controller-scale guidance for Alexa, read it as a planning range. It is not a guaranteed figure, not an exact hard limit, and not the theoretical maximum number of endpoints Matter Hub itself can build. Real capacity depends on the Echo model and its software, how complex each endpoint is, the number of clusters, how many subscriptions are active, network quality, and whatever else already lives in that same Alexa home.

Read the device count as the number of bridged devices and endpoints Alexa actually builds — not a straight conversion from your Home Assistant entity count. A single composed device can carry several endpoints, and some HA entities will not map to Matter at all. When you write results down for your own records, keep counts and types only. Never write down an internal identifier.

Four flags, each one an Alexa-specific workaround

Change one flag at a time. Keep a secret-free record of the configuration before you save, and after the restart test the Alexa app, voice control, HA state, and every other fabric on that bridge. A workaround that changes device semantics — cover-as-light most of all — suits a separate, Alexa-only bridge best. If the same bridge also serves Apple Home or Google Home, an Alexa fix can quietly break how those other controllers render the same device.

Building and commissioning the core Alexa bridge

1. Step 1

   Reserve 5540 and the core contents

   In Matter Hub, create or edit the bridge you will hand to Alexa first. Confirm it uses 5540 with nothing else competing for that port, and keep the filter to a small set of known basic devices.

2. Step 2

   Run the Matter Hub preflight

   Confirm the bridge is running, that Devices shows no failed mappings, and that the underlying HA entities still respond normally. Back up the persistent data, then freeze the port, the names, and the structure for the duration of commissioning.

3. Step 3

   Open the commissioning window

   Display this session's QR code from the target bridge. Do not screenshot it, forward it, log it, or paste manual pairing data into anything you send to Amazon support.

4. Step 4

   Add a Matter device in the Alexa app

   Under Devices in the Alexa app, choose Add Matter device or whatever your current version calls that entry point, scan the local QR code, pick the target Home, and keep the app in the foreground.

5. Step 5

   Let discovery finish untouched

   Once onboarding completes, let Alexa finish discovering the bridged devices on its own. Do not run Force Sync, change the filter, or restart the Echo at this point. Confirm the small baseline set has appeared before doing anything else.

6. Step 6

   Test the app, voice, and HA state in both directions

   Operate one device from the Alexa app and one by voice, then operate one from HA and confirm Alexa updates. Record only types and results in your own notes — never an internal identifier.

7. Step 7

   Expand in small batches, or split the bridge

   Add a few same-kind devices at a time. If you need the cover-as-light or a vacuum workaround, test it on an Alexa-only bridge first, so the semantics for your other fabrics never change underneath them.

What to check first, before you touch commissioning again

Both ecosystems fail along the same shape of diagnostic path: was the device ever mapped, is its Matter device type actually on that controller's supported list, and only then is it worth touching commissioning a second time.

flowchart TD
  A["A device you expected
is missing from the app"] --> B{"Does it appear in
Matter Hub's Devices mapping?"}
  B -->|"no"| C["Fix the filter or the mapping first.
The controller never even saw it"]
  B -->|"yes, mapping succeeded"| D{"Is that Matter device type
on the controller's own
published supported-types list?"}
  D -->|"not listed, or only partial"| E["Record it unknown or partial.
A Matter Hub mapping is not a promise"]
  D -->|"listed"| F["Compare against the practical
scale, and test it in a small batch"]

The questions that come up on both ecosystems

Where to go from here