Aqara, SmartThings and controller compatibility
Plan Apple, Google, Alexa, Aqara and SmartThings with an auditable yes / partial / no / unknown matrix; keep what the protocol can map, how mature the product is and what the controller actually shows as three separate things, so you never promise support nobody has verified.
“Matter support” is not a boolean
Home Assistant Matter Hub can map a Home Assistant domain to a Matter device type, but whether a controller accepts the bridge, whether it shows the endpoint, whether it offers commands, whether it subscribes to state, and whether it supports a newer Matter version are five different questions. Apple Home, Google Home, Alexa, Aqara Home and SmartThings all speak Matter, and they still do not give you the same UI or the same cluster coverage.
The matrix in this chapter is a planning starting point, not a certification table. It combines the mappings v2.0.55 can reach, the feature manifest and the device types each controller publishes officially. “yes” only means the official evidence supports the basic path for that type; you still have to test it on your own controller version. “partial” means the type or the basic capability is reachable, but advanced features, how the bridge is presented, or the version have known limits. “unknown” means there is not enough pinned evidence, so you must not guess.
The evidence rules for yes, partial, no and unknown
| Mark | Meaning | What you still have to do |
|---|---|---|
| yes | The controller's official public material includes that Matter type or basic capability, and Matter Hub has a mapping path for it. | Test discovery, basic commands, state reporting and restart yourself; this is not a guarantee of full cluster support. |
| partial | Only some sub-types, commands or UI are there; it needs a newer platform version or a workaround; or the bridge-specific evidence is thin. | Record what is missing and split off a controller-specific bridge if you need to. |
| no | A pinned source excludes it explicitly, or the dedicated flag manifest marks that controller as no. | Do not try to turn a no into a yes by resetting or re-commissioning. |
| unknown | The official material is not enough to confirm this bridge and type combination, and there is no controlled test evidence. | Test on a small scale and report it conservatively; do not write it up as either supported or unsupported. |
The matrix works at the “basic device type” level; it does not mix every cluster into one cell. A light's on/off may be yes while color or transition is still partial; a vacuum may show up as partial while room cleaning and progress stay unknown. When that happens, mark the more conservative state.
Apply the three limit layers before you look at the controller
| Layer | Baseline for this guide | Effect on the matrix |
|---|---|---|
| Release channel | Home Assistant Matter Hub Stable v2.0.55 at an exact commit; the add-on pinned to a mirror commit. | Nothing from Alpha, Testing or later features goes in. |
| Product maturity | Standard bridges and most existing mappings are Stable; several entities in Server Mode, the Camera and Security plugins and some Matter 1.4 types are experimental inside Stable. | Even where the controller supports the type, an experimental product path still must not be written up as a settled promise. |
| Controller support | Follows each vendor's official supported-devices and Matter documentation; most controller cells in the upstream manifest are unknown. | Without type-by-type evidence, leave it unknown; do not promote it to yes on the strength of a marketing page. |
A yes in the matrix does not override maturity. A newer version of Apple's Home app may support some newer Matter type, but if Matter Hub's mapping for that type is still an experimental one inside the Stable channel, the overall recommendation is still a small trial. It works the other way round too: a settled Matter Hub mapping does not make a controller add UI on its own.
Controller compatibility matrix for all 52 Matter overrides
| Matter override identifier | Apple Home | Google Home | Alexa | Aqara Home | SmartThings |
|---|---|---|---|---|---|
air_purifier | no | yes | yes | yes | unknown |
air_quality_sensor | no | yes | yes | yes | unknown |
dishwasher | no | no | unknown | unknown | yes |
basic_video_player | no | no | no | yes | unknown |
battery_storage | no | no | no | yes | unknown |
carbon_monoxide_sensor | partial | no | partial | yes | unknown |
color_temperature_light | yes | yes | yes | yes | yes |
contact_sensor | yes | yes | yes | yes | yes |
dimmable_light | yes | yes | yes | yes | yes |
dimmable_plugin_unit | yes | no | yes | yes | yes |
door_lock | yes | partial | yes | yes | yes |
doorbell | no | no | no | no | yes |
electrical_meter | no | yes | no | unknown | yes |
electrical_sensor | no | no | unknown | unknown | yes |
electrical_utility_meter | no | no | no | unknown | yes |
evse | no | no | no | yes | unknown |
extended_color_light | yes | yes | yes | yes | yes |
fan | no | yes | yes | yes | partial |
flow_sensor | no | yes | no | unknown | unknown |
formaldehyde_sensor | no | no | partial | yes | unknown |
generic_switch | partial | no | yes | unknown | unknown |
humidifier_dehumidifier | unknown | no | yes | unknown | unknown |
humidity_sensor | yes | yes | yes | yes | yes |
light_sensor | yes | yes | yes | unknown | yes |
mode_select | no | no | no | unknown | unknown |
motion_sensor | yes | yes | yes | yes | unknown |
nitrogen_dioxide_sensor | no | no | partial | yes | unknown |
occupancy_sensor | partial | yes | yes | yes | yes |
on_off_light | yes | yes | yes | yes | yes |
on_off_plugin_unit | yes | yes | yes | yes | yes |
on_off_switch | yes | yes | yes | yes | yes |
mounted_on_off_control | no | no | no | yes | yes |
ozone_sensor | no | no | partial | yes | unknown |
pm1_sensor | no | no | partial | yes | unknown |
pressure_sensor | no | yes | no | yes | yes |
pump | no | yes | no | yes | unknown |
rain_sensor | no | no | no | yes | unknown |
radon_sensor | no | no | partial | yes | unknown |
robot_vacuum_cleaner | yes | yes | yes | yes | unknown |
robotic_lawn_mower | yes | unknown | yes | unknown | unknown |
smoke_co_alarm | yes | no | yes | yes | yes |
solar_power | no | no | unknown | unknown | yes |
speaker | no | yes | no | yes | unknown |
temperature_sensor | yes | yes | yes | yes | yes |
thermostat | yes | yes | yes | yes | yes |
tvoc_sensor | no | no | partial | yes | unknown |
water_heater | no | no | unknown | yes | unknown |
water_heater_management | no | no | unknown | unknown | unknown |
water_freeze_detector | no | no | no | yes | unknown |
water_leak_detector | yes | no | yes | yes | unknown |
water_valve | no | no | no | yes | unknown |
window_covering | yes | yes | yes | yes | yes |
on_off_switch means it is presented as a Matter On/Off Light, not as a native switch tile; the real wall-control type is the experimental mounted_on_off_control. “Can be presented” in the table is not the same as the UI name matching the identifier.Every row here lines up with one of the 52 MatterDeviceType identifiers in v2.0.55. Apple, Google, Alexa and Aqara follow the pinned picker snapshot, SmartThings follows the compatibility document at the same version, and anything without type-by-type evidence stays unknown. A no in this table is used only where the pinned v2.0.55 compatibility matrix or a controller's official type list gives evidence of exclusion; an unknown does not turn into a no because one commissioning attempt failed. There is also a controller-specific flag: alexaPreserveBrightnessOnTurnOn is yes for Alexa and no for Apple and Google — that is flag support, not a no for the whole light type.
What to reasonably expect from the 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 newer types against your Apple platform version; for No Response, check IPv6, mDNS, sessions and subscriptions first.
- Google Home: follow Google's official supported device types and its compatible hubs; the optimized template is a Matter Hub starting configuration, not a Google certification. A Google room and name are not the same thing as an HA area and name.
- Alexa: use 5540 for the first bridge you commission; the figure of about 80–100 is only upstream practical planning. Cover-as-light, brightness preservation and the vacuum flags are workarounds, so keep them on an Alexa-only bridge.
- Aqara Home: Aqara's official public list covers many types, and v2.0.55 does carry Aqara quirks; the matrix can mark a basic type yes where a source backs it, but types that are not listed stay unknown, and none of that promises full Matter Hub support for every type.
- SmartThings: the official documentation lists Matter support and compatible hubs, but how a third-party bridge's device types and clusters are presented still depends on the platform and the driver. Verify on a small scale first, and do not write “SmartThings supports Matter” up as “SmartThings supports all of Matter Hub”.
A controller's account, rooms, names, automations and sharing permissions are independent of every other controller's. Multi-fabric lets several fabrics manage the same bridge; it does not sync the management data of five ecosystems with each other.
Build your own compatibility evidence with small tests
List what you need, not every HA entity
List, by room and device type, the devices you genuinely want to operate from each controller, and mark which are safety-sensitive, which are read-only state and which need advanced features. Keep internal identifying data out of the record.
Apply the official limits
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, and do not extrapolate from your experience with another brand.
Build a minimal core bridge
Add only low-risk types such as lights and switches for which every target controller has basic evidence, back up, then onboard the first fabric.
Add fabrics one at a time
Reopen the commissioning window for each one and add a single controller; when it is done, verify display, commands, state and restart, and neither share nor keep the pairing data.
Test one special type at a time
Add one representative cover, fan, sensor or vacuum, and record each feature as yes / partial / no / unknown. Do not just record “commissioning succeeded”.
Split bridges according to the evidence
If one controller needs a different device type or flag, create a dedicated bridge; for example, do not let the Alexa cover-as-light workaround contaminate the cover semantics on Apple and Google.
Retest after a version upgrade
Controller firmware, an app or a Matter Hub update can all change the matrix. Keep the version and the date, but record no fabric or node internal values and no live network data.
A shared core bridge, or one bridge per controller
| Strategy | When it fits | Upside | Risk |
|---|---|---|---|
| One shared core bridge | A small number of basic lights and switches, with the basic types already verified on each controller. | One set of endpoints, a simple HA filter, and every fabric sees the same state. | A workaround for one controller can affect all of them; the blast radius is larger. |
| Split by controller | Alexa needs cover-as-light, or Aqara and SmartThings only accept a smaller subset. | You can choose types, flags, scale and maintenance windows independently. | You may expose the same HA entity twice, which confuses people and creates automation races. |
| Split by type | Vacuums, covers, locks, sensors and new Matter types need isolating. | A special type that fails does not drag basic lighting down with it, and the test evidence stays clear. | More bridges, more ports and more commissioning to manage. |
| Split by area | A large home or a small office needs to limit both the blast radius and the controller scale. | Naming and ownership are clear, and each bridge carries fewer endpoints. | Devices that span areas, and room naming, need one consistent rule. |
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 clearly.
Four actionable 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.
- 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 do not wait for the problem before you split.
- Risk trigger: locks, security, 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 in 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 at once; every stage needs a fallback point you can verify.
Common cross-controller pitfalls
The same bridge works in Apple Home but Aqara cannot see it
Keep the Apple fabric and do not reset. Mark the Aqara combination unknown, cross-check the Aqara hub model, region, firmware and the bridged device type, then try a dedicated bridge holding one basic light and nothing else.
SmartThings commissioning succeeds but there are few features
Mark that device type partial and compare SmartThings' official Matter support against the UI and driver you actually get; record commands and state separately instead of claiming overall support.
An Alexa workaround makes the Apple types wrong
This is a semantics conflict on a shared bridge. Roll that flag back and test on an Alexa-only bridge; do not delete the Apple fabric to accommodate Alexa.
Google has control, Apple only has state
Mark the command layer partial and cross-check which clusters Apple supports and on which platform version. Compare against a basic device of the same type first; do not change every mapping.
Discovery slows across the whole bridge after you add a special type
Roll back the last batch of filter and mapping changes, and split the special type off. Check the controller scale and the endpoint complexity; do not use a reset to wipe out your evidence.
You cannot tell whether to write no or unknown
Write unknown when there is no explicit official exclusion and no controlled failure evidence; one failure usually only proves it failed in that environment, which is not enough to declare a blanket no for the controller.
FAQ
The Aqara hub supports Matter — does that mean full support for a Matter Hub bridge?
If the SmartThings site lists a device type, can I mark it yes?
Will multi-fabric make all five controllers show exactly the same thing?
Is a yes in the matrix a product guarantee?
How do I record an experimental feature inside Stable?
Pinned-version and official controller sources
- 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
Official pages change as each ecosystem ships new versions; this chapter leaves any combination that the pinned upstream and the official type lists cannot jointly confirm as partial or unknown.