HOME TECHCOMPATIBILITY

Feature-level compatibility

Matter-compatible does not mean feature-identical

Why a Matter device can show different controls in Apple Home, Google Home, Alexa, SmartThings, Home Assistant or its own app.

Illustration
Updated: Review due:

This page is out of date. It was due for another look on and has not been re-checked since. The sources below are still listed with the date each one was read — open them before relying on anything here.

Overview

  • Matter support is where the question starts, not where it ends.
  • The platform, the type of device, the app's design, firmware and bridges can all change what you actually see.
  • We publish a claim about one feature only when a dated source covers that exact control.

Compatibility has to go down to the feature

A broad claim can hide what actually affects a household: which controls, routines, alerts and setup steps exist in the app you use. If a source confirms only the type of device, the page should not suggest that every control is there.

Original evidence

Compatibility needs a feature layer

A broad compatibility claim can hide the detail that actually affects a household: which controls, automations, alerts, and setup paths are available in the app they use.

The safe editorial posture is to separate device-category support from feature-level behavior. If a source only confirms the category, the page should not imply that every control is available.

Platforms do not all show the same controls

Platforms can build and show support differently, and the maker's own app may offer controls Matter alone does not. That is why we avoid a single yes-or-no column and record the platform, the feature, the limits, our confidence and the date separately.

Original evidence

Ecosystems may not expose the same surface

Different ecosystems can implement or present support differently. A manufacturer app can also expose controls that are not visible through a generic Matter path.

This is why the matrix should avoid a single yes/no compatibility column and use source-backed fields for ecosystem, feature, caveat, confidence, and date checked.

How to read a compatibility row

A row should answer the question you actually asked: not just whether the device joins, but what you can do once it has, and what is still unknown.

Original evidence

How to read future compatibility rows

A future row should answer the exact question asked: not just whether a device joins, but what the user can actually do after it joins and what remains unknown.

Decision matrix

What to check

Each row names what to confirm and why it can change the answer in your home.

0 / 3 checked
Checked Question What to check Why it matters
Category support Does the ecosystem documentation list the device category? This is the top-level gate before deeper feature claims.
Feature support Does a dated source confirm the specific control or behavior? Feature parity is where buyer surprises often appear.
Caveat support Is firmware, region, bridge path, or setup path part of the answer? A true answer can change depending on these conditions.

Check: Does the ecosystem documentation list the device category?

Why: This is the top-level gate before deeper feature claims.

Check: Does a dated source confirm the specific control or behavior?

Why: Feature parity is where buyer surprises often appear.

Check: Is firmware, region, bridge path, or setup path part of the answer?

Why: A true answer can change depending on these conditions.

Source ledger

Sources and dates

The public pages behind this guide, with the date each one was checked. Open them before relying on a claim.