“Matter support” is not one question

Matter Hub can map a Home Assistant domain onto a Matter device type. That is one fact. Whether a given controller accepts the bridge, whether it shows the endpoint, whether it offers commands, whether it subscribes to state changes, and whether it supports whatever newer Matter version it needs — those are five separate facts, and Apple Home, Google Home, Alexa, Aqara Home and SmartThings answer each of them differently. All five speak Matter. None of them give you the same interface or the same cluster coverage once you actually commission a device.

The matrix later in this part is a planning starting point, not a certification. It combines what Matter Hub v2.0.55's mappings can reach, the feature manifest, and each ecosystem's own published device-type list. It does not combine test results from your specific hub, your specific firmware, or your specific home — only you can produce those.

Four marks, and the evidence each one actually requires

Every cell in the matrix carries exactly one of four marks. They are not a scale from bad to good — they are four different claims about what evidence exists, and mixing them up is how a “probably fine” guess turns into a written promise nobody checked.

The matrix works at the basic-device-type level, not the individual-cluster level. A light's on/off may be yes while its color or its transition effects are still partial; a vacuum may be partial overall while room cleaning and progress reporting stay unknown. When a type covers several clusters like that, the rule is to record the more conservative mark for the row, not the more flattering one.

flowchart TD
  A["Official material for this controller,
for one specific Matter device type"] --> B{"Is the type or basic
capability listed at all?"}
  B -->|"not listed anywhere"| U["Unknown"]
  B -->|"listed"| C{"Does Matter Hub v2.0.55
have a mapping path for it?"}
  C -->|"no mapping path"| U
  C -->|"a mapping exists"| D{"Does a pinned source or the
flag manifest exclude it?"}
  D -->|"explicit exclusion"| N["No"]
  D -->|"no exclusion found"| E{"Are advanced features, the UI,
or the platform version still limited?"}
  E -->|"limited in some way"| P["Partial"]
  E -->|"basic path fully covered"| Y["Yes"]

Apply these three limits before you even look at a controller

Before a single controller enters the picture, three layers already narrow what any mark in this matrix can honestly claim.

flowchart LR
  A["Release channel:
Stable v2.0.55,
one pinned commit"] --> B["Product maturity:
standard bridges are Stable,
some types stay experimental"]
  B --> C["Controller support:
each vendor's own
official device list"]
  C --> D["The mark you actually
write in the matrix"]

A yes in the matrix never overrides maturity. A newer version of a controller's own app may add support for some newer Matter type, but if Matter Hub's mapping for that type is still experimental inside the Stable channel, the honest recommendation is still a small trial. It runs the other way too: a fully settled Matter Hub mapping does not make a controller add UI for it on its own.

The controller compatibility matrix for all 52 Matter overrides

Every row below matches one of the 52 MatterDeviceType identifiers in v2.0.55. Apple Home, Google Home, Alexa and Aqara Home follow the pinned picker snapshot; SmartThings follows its own compatibility document at the same version. A no appears only where the pinned v2.0.55 compatibility matrix, or a controller's own official type list, gives explicit evidence of exclusion — one failed commissioning attempt on your own network does not turn an unknown into a no.

flowchart TD
  A["A physical wall switch
you want to bridge"] --> B{"Which Matter device type
do you map it to?"}
  B -->|"on_off_switch"| C["Shown as an On/Off Light tile.
Yes on all five controllers"]
  B -->|"mounted_on_off_control"| D["Shown as an actual switch tile.
Yes only on Aqara Home
and SmartThings"]

There is also a controller-specific flag worth knowing by name: alexaPreserveBrightnessOnTurnOn is yes for Alexa and no for Apple Home and Google Home. That is flag-level support inside a light type, not a no for the whole type — a different thing again from any of the four marks above.

What to reasonably expect from all five ecosystems

• Apple Home — the Home app and a home hub provide the Matter controller, and the basic types are where you build your baseline. Verify sensor cards, events, vacuums and any newer type against your own Apple platform version. For No Response, check IPv6, mDNS, sessions and subscriptions first.
• Google Home — follow Google's own supported device types and its list of compatible hubs. The optimized template is a Matter Hub starting configuration, not a Google certification. A Google room and an HA area are not the same object, even when they share a name.
• Alexa — use 5540 for the first bridge you commission. The figure of about 80–100 devices is upstream practical planning, not a hard ceiling anyone has measured. Cover-as-light, brightness preservation and the vacuum flags are workarounds, so keep them confined to an Alexa-only bridge.
• Aqara Home — Aqara's own public list covers many types, and v2.0.55 does carry Aqara-specific quirks. The matrix marks a basic type yes where a source backs it, but a type that is not listed stays unknown, and none of it promises full Matter Hub support for every type Aqara ships.
• SmartThings — the official documentation lists Matter support and compatible hubs, but how a third-party bridge's device types and clusters actually get presented still depends on the platform and the driver. Verify at small scale first, and do not write “SmartThings supports Matter” up as “SmartThings supports all of Matter Hub.”

One thing holds across all five: a controller's account, its rooms, its names, its automations and its sharing permissions are independent of every other controller's. Multi-fabric, covered in Part 8, lets several fabrics manage the same bridge — it does not sync the management data of five separate ecosystems with each other.

Seven steps to your own compatibility evidence

The matrix above tells you where official evidence exists. It cannot tell you what happens on your own hub, your own firmware, your own home. Building that evidence is a small, repeatable routine.

1. Step 1

   List what you need, not every entity you have

   List, by room and device type, the devices you genuinely want to operate from each controller. Mark which are safety-sensitive, which are read-only state, and which need advanced features. Keep internal identifying data out of the record.

2. Step 2

   Apply the official limits, one ecosystem at a time

   Go through the official Matter documentation from Apple, Google, Amazon, Aqara and SmartThings one at a time. Mark anything unlisted or vaguely described as unknown. Do not extrapolate from your experience with a different brand's implementation.

3. Step 3

   Build a minimal core bridge

   Add only low-risk types — lights and switches, typically — for which every target controller already has basic evidence. Back it up, then onboard your first fabric.

4. Step 4

   Add fabrics one at a time

   Reopen the commissioning window for each controller and add a single one. Once it is done, verify display, commands, state and behavior after a restart, and neither share nor keep the pairing data afterward.

5. Step 5

   Test one special type at a time

   Add one representative cover, fan, sensor or vacuum, and record each feature as yes, partial, no or unknown for your own setup. “Commissioning succeeded” on its own is not a result worth recording.

6. Step 6

   Split bridges according to the evidence you found

   If one controller needs a different device type or a different flag, create a dedicated bridge for it. Do not let, for example, the Alexa cover-as-light workaround contaminate cover semantics on Apple Home and Google Home.

7. Step 7

   Retest after every version upgrade

   Controller firmware, a controller's app, or a Matter Hub update can each change the matrix on their own. Keep the version number and the date with every result you record — but never record fabric IDs, node IDs, or any live network data.

A shared core bridge, or one bridge per controller

Do not put the same entity on a shared bridge and a controller-specific bridge at once, unless you are testing that deliberately and can live with duplicate cards and races. If you must duplicate it, verify with one device that is not safety-critical first, and name the source of each card clearly.

Four triggers for splitting a bridge

• Type trigger — the same Matter device type is partial or unknown on one controller, and it slows down or blocks discovery for the whole bridge.
• Semantics trigger — you need a workaround, such as cover-as-light or a simplified vacuum on/off, that changes the UI on other controllers too.
• Scale trigger — you are close to a controller's practical capacity, or onboarding, restart and subscription delays are climbing noticeably. Alexa's roughly 80–100 is a planning signal, so split before it becomes a problem, not after.
• Risk trigger — locks, security devices, experimental plugins and new Matter types should not share a blast radius with your core lighting.

Before you split, back up and export a configuration summary that contains no secrets. Exclude the target entities from the original bridge's filter, then settle how the old accessories will be handled on the controller side. Do not delete, reset, create a new bridge and join five fabrics all in one sitting — every stage needs a fallback point you can actually verify.

flowchart TD
  A["A shared core bridge,
already in production"] --> B{"Type trigger: is one Matter
type partial or unknown,
and slowing the whole bridge?"}
  B -->|"yes"| S["Split off a
dedicated bridge"]
  B -->|"no"| C{"Semantics trigger: does a
workaround change the UI
on other controllers?"}
  C -->|"yes"| S
  C -->|"no"| D{"Scale trigger: getting close
to a controller's practical
device ceiling?"}
  D -->|"yes"| S
  D -->|"no"| E{"Risk trigger: locks, security,
or an experimental plugin
on this bridge?"}
  E -->|"yes"| S
  E -->|"no"| K["Keep it on the
shared bridge"]

The pitfalls that actually happen across five controllers

Pinned-version and official controller sources

Every mark in this chapter traces back to one of the sources below, pinned at the same commit v2.0.55 uses. Official pages change as each ecosystem ships new versions; wherever the pinned upstream and a controller's own type list cannot jointly confirm something, this chapter leaves it partial or unknown rather than guessing forward.

• v2.0.55 Controller Compatibility Matrix
• Home Assistant domains supported in v2.0.55
• v2.0.55 bridge flags and controller-specific settings
• Pinned Stable add-on configuration
• Apple: Pair and manage Matter accessories
• Google: Supported Matter device types
• Amazon Alexa: Matter support
• Aqara's official Matter documentation
• SmartThings' official Matter documentation

Where to go from here