MatterCheck

Methodology

How cells are researched, scored for confidence, and kept current.

MatterCheck verification methodology

How MatterCheck researches, scores and maintains each cell.

Principles

1. Official docs first — Prefer each platform’s Matter device-type list and automation/routines help (Apple Support, Google Home Developers, Alexa developer docs, SmartThings partners, Home Assistant Matter integration). Official beats community when they conflict, unless the official page is clearly stale; record the conflict in notes.

2. High bar — confidence: High only with official confirmation or a reproducible public test. Anecdotes alone are never High.

3. Community → Med — If no official source: ≥2 independent community reports that agree → Med; a single community report → Low.

4. Unknown is valid — Absence of evidence is Unknown, not N. Do not infer from “similar” device types or chipsets.

5. Never invent — Every Y / N / Partial must trace to a cited URL. An official list *omission* alone supports N at Med at most. Apple 102135 omission was wrong for leak, smoke/CO, fan/purifier and air quality, so N at High needs explicit evidence such as a hands-on “not supported / not shown / not created” report or a platform mapping table (v0.60).

6. Changelog on change — Material cell edits update changed_from, change_date, and a line in data/changelog.md.

7. Stale > 60 days — If last_checked is older than 60 days (or missing), re-verify before treating High/Med as current. If re-verification fails, set affected fields to Unknown and note why.

8. Conflicting native tests stay Med — High needs an official platform statement covering the behaviour and ≥1 independent dated hands-on with a *native* (directly commissioned) Matter device. An interface-level platform statement (e.g. Amazon’s 2018 blog that contact/motion sensors start Routines) counts as the official half when the platform’s own Matter page maps the device type to that interface. Vendor guides/tables and aggregators are corroboration only. If independent native hands-on reports disagree on a field, confidence stays Med until a newer independent native test resolves it (v0.67).

What we verify per cell

| Column | Chip | Question |

|--------|------|----------|

| pairs | P | Does the platform’s Matter list include this device type (or an official equivalent)? |

| control | C | Can the user control it in the platform app / voice once paired over Matter? |

| automation_trigger | T | Can its state/event start a platform automation/routine? |

| automation_action | A | Can an automation/routine command it? |

P / C / T / A are independent. Trigger ≠ action (matrix chips color-code T vs A). A contact sensor may trigger but not be “controlled”; a plug may be both controllable and an action target. Hub / Thread border-router needs go in hub_required, not as silent assumptions. Switches and buttons follow a row-specific rule (below).

Switches and buttons (switch_button row)

Rule (v0.89, 2026-10-17). The switch_button row covers Matter switch-family device types that send presses or commands but cannot be commanded: Generic Switch (0x000F) buttons and remotes, and On/Off Light / Dimmer / Color Dimmer Switch (0x0103–0x0105), which control bound lights.

Sensor rows keep C = Y because they show a current reading. A button has no current state to show (a latching switch reports a position but still cannot be operated).

Evidence hierarchy

1. Platform Matter supported-device list (official)

2. Platform automation / routines documentation (official)

3. Platform release notes / blogs (release-note)

4. Reproducible public test write-up (test)

5. Independent community reports (community) — Med/Low only

Every cell that can cite a URL does. The “Will this do X?” filter shows those sources as clickable links (same as type pages).

Inventory (current)

As of 2026-10-18 SGT:

Counts are generated from the published matrix and SKU data files.

Living data UX (stale + Δ)

Stale (>60 days). Cells with last_checked older than 60 days (SGT) or missing get: ⏱ marker + amber dashed outline on the matrix, a “Stale · Nd” badge on filter and type pages (fresh cells show “Nd ago”), a home stale-count stat, and a “Stale only” toggle. Filter verdicts on stale cells carry an unconfirmed warning.

Recent cell changes (Δ). Cells with a recorded change_date get a blue Δ badge (blue outline when recent). The home Recent cell changes strip lists value or confidence flips in the last 30 days, driven by change_date / changed_from. Expansions that only add new device types are not listed there — only re-checks that flipped an existing cell. Full history: changelog.

SKU directory (also_device_types)

Each SKU has one primary device_type plus optional also_device_types for secondary Matter types the product also exposes. The SKU filter and cards honour both. Examples in the current pack:

Do not invent secondary tags without brand or CSA evidence.

Adding device types

Add a matrix row only when ≥2 of the five platforms name that type on their official Matter supported-device / category lists. One-platform-only candidates stay out (logged, not invented). Examples that failed the bar: doorbell, flow sensor (Google only each); rain sensor (SmartThings only). Facet splits (e.g. fan direction, blinds tilt) are not separate types unless official lists name them as distinct device types.

How we differ

Honest framing (2026-10-16): MatterCheck is a living, docs-based Matter guide organized by device type, with trigger/action separation (P/C/T/A) and Home Assistant as a 5th platform column. We do not claim to be the only Matter automation table.

What MatterCheck still does differently:

1. Unit of row — Matter device types (24) rather than capability/feature rows.

2. Four fields per cell — pairs · control · automation_trigger · automation_action tracked separately (trigger ≠ action; both shown as P/C/T/A chips).

3. Home Assistant as 5th platform — first-class column on the type matrix, alongside Apple Home, Google Home, Alexa and SmartThings.

4. Living ops UX — stale-cell flags (>60 days), cell/site changelog, Δ recent-changes strip (30d), and a “Will this do X on my platform?” filter with clickable source URLs.

We do not copy third-party matrix content wholesale. Competitor structure may inform *questions* we ask; every MatterCheck cell is re-sourced from primary platform docs and carries our own last_checked, confidence, and changelog.

Hardware testing

Some cells (especially Alexa routine triggers, Apple types omitted from Support but claimed in iOS release notes, HA leak mapping) need hands-on or multi-source confirmation. Mark Unknown / Low until then — do not fake High. No hardware test bench yet; documentation-first until resources allow.

Weekly loop

Monday ~09:00 SGT: platform release notes + community → update cells + changelog; flag stale rows; skim SKU certs/exclusions.

Quality checks