A Paradigm Shift in Matter IoT Development
From Selecting a Device Type to Defining an Action
A Proposed Shift in Design Thinking for Developers
1. The Structural Problems with Matter Development Today
Problem 0. The Entry Barrier: Matter Development Is Hard
Before writing a single line of actual behavior code, implementing a Matter device from scratch requires clearing a long series of hurdles.
ESP-IDF setup → Matter SDK build → Manual cluster mapping → Commissioning logic
NVS storage structure → GPIO conflict management → State management → … then, finally, behavior
Even when starting from a reference firmware, any deviation quickly requires digging into the SDK internals. Infrastructure code overwhelms actual behavior code.
Problem 1. The Core Issue: Actions Have No Names
The typical Matter/IoT development workflow looks like this:
- Pick the closest match from the platform-defined Device Type list
- Combine the features available within the clusters and attributes that Type supports
- Fit the hardware (GPIO pins, sensors) into the Type’s structure
- Copy an existing example or reference firmware and modify it
This is not designing behavior. It is fitting hardware into a pre-existing template.
When a new behavior is needed, developers pick the closest existing Type and force-fit it. If the platform does not define it, you cannot build it.
Additional Problems in the Age of AI
Problem 2 — AI Does Not Know What a Device Actually Does → It Guesses
Without named Actions, AI has no way to know a device’s intent. It reads the Device Type and cluster structure and infers meaning. This is not understanding — it is guessing.
In practice, diverse behaviors get reduced to simple on/off control patterns — not because they are the same, but because the system has no better way to describe them. A heater, a fan, and an electric blanket can all be controlled identically, not because they are equivalent, but because there is no structural way to express what they actually mean.
In the current Matter implementation, UserLabel (0x0041) is a user-editable display label. It is not used as a trusted system-level identifier. There is no official way to communicate to the system what an endpoint actually does.
Problem 3 — Actions Have No Safety Boundaries → AI Issues Commands Without Knowing the Limits
Constraints like maximum run time, risk level, and auto-shutoff conditions are hardcoded inside the firmware. They cannot be read from the outside.
AI issues commands without knowing what is allowed. It controls a kitchen light and an electric blanket in the same way. Safety conditions are guessed, not known.
2. The Proposal: Define the Action First
Instead of starting by selecting a Device Type, consider a structure where you think through everything about a single Action from the very beginning.
2-1. Nine Questions to Define an Action
① What is the intended action?
② What physical effect occurs?
③ What boundaries must never be crossed? ← newly added question
④ In what context is this Action valid?
⑤ What event triggers the action?
⑥ What is the goal value?
⑦ What is the maximum execution time?
⑧ What conflicts must be checked before starting?
⑨ What protection conditions apply before stopping?
Once you can answer these questions, the Action has a name. A collection of named Actions becomes a device.
Devices that do not belong to any existing Device Type become possible.
Where conventional development starts with “Which Type should I pick and fit this into?”, this approach starts with “What is this Action?”
2-2. Simplifying the Execution Model
To keep the execution model simple and explicit, every Action maps to one of two fundamental units.
| Button (immediate execution) | Switch (state maintained) |
|---|---|
| Instantaneous pulse action | Persistent state maintained |
| e.g. doorbell, notification, one-shot trigger | e.g. light ON/OFF, keeping a heater running |
These two are the starting point. Additional clusters can be added as needed for more precise control.
This has a practical benefit as well: since all behaviors map to a simple ON/OFF model, only the OnOff cluster is needed on the Matter side as a baseline. This can significantly reduce certification costs and time, while preserving flexibility at the action level.
3. Implementation Within the Existing Matter Structure
Without any spec changes, reinterpreting existing Matter cluster structures is sufficient to address both AI-era problems.
3-1. Solving Problem 2 — The endpointLabel Pattern (UserLabel 0x0041)
The name of an Action needs to be communicated in a form the system can trust. UserLabel is user-editable, making it unsuitable as a system-level identifier.
Proposal: Introduce a pattern (endpointLabel) that embeds a manufacturer-defined identifier within the label field.
// UserLabel (0x0041) usage pattern
"UserLabel": "endpointLabel:keep-warm|display:Keep Warm"
// AI and automation systems can directly read the endpoint identity
// via the endpointLabel key -- no inference required
// -> No spec change needed; works within existing structure
This pattern has been proposed to the Matter SDK repository (issue #71521). It works within the existing structure without any spec changes.
3-2. Solving Problem 3 — Reinterpreting Fixed Label (0x0040)
The Fixed Label cluster (0x0040) is manufacturer-defined and read-only. Until now, it has only been used for physical orientation labels and UI labels.
By storing an Action’s safety boundaries declaratively in this cluster, the device itself can announce its own limits to the outside world.
// Fixed Label (0x0040) -- declaring safety boundaries
"FixedLabel": [
{ "label": "purpose", "value": "heating" },
{ "label": "risk", "value": "high" },
{ "label": "auto-off","value": "300s" }
]
// Safety conditions hardcoded inside firmware -> unreadable from outside
// Conditions declared in Fixed Label -> AI, automation systems, other devices
// can read them directly, without inference
Key point: Rather than safety conditions being hidden inside firmware, the action itself declares its own limits. Both of these work within the existing Matter structure, with no spec changes required.
4. Current Approach vs. Proposed Approach
| Current Approach | Proposed Approach |
|---|---|
| Starting point: Select a Device Type | Starting point: Define an Action |
| Design direction: Hardware → fit into template | Design direction: Intent → map to hardware |
| New behavior: Force-fit closest Type | New behavior: Add an Action directly |
| AI recognition: Infers from cluster structure | AI recognition: Reads endpointLabel directly |
| Safety boundaries: Hardcoded in firmware | Safety boundaries: Declared in Fixed Label (read-only) |
| Behavior change: Rewrite firmware + reflash | Behavior change: Update via configuration |
| Undefined device: Cannot be implemented | Undefined device: Can be implemented |
5. Why This Matters
The key outcomes of this proposal:
- Behavior is defined in units of Actions, not Device Types
- Safety boundaries stored declaratively via Fixed Label (0x0040) — readable by AI and automation systems without inference
- Stable endpoint identification via the endpointLabel pattern in UserLabel (0x0041)
- Action definitions are machine-readable — enabling AI/automation integration without hardcoding
This approach requires no Matter spec changes. Reinterpreting existing structures is sufficient.
Behavior is no longer code.
It becomes data that can be inspected and validated.
A Note on Execution
This is not about giving AI more control. AI does not decide actions. It validates predefined meaning and boundaries before execution.
Responsibility Model
To make this work in the physical world, responsibility must be clearly separated:
- Manufacturers define the meaning of actions and safety boundaries
- AI validates those definitions before execution
- Users decide what is allowed based on those rules
Every device built so far was designed to be operated by humans.
Devices built from now on should be designed to be understood by AI.
A device is not a type.
A device is a composition of actions.
It starts with giving Actions a name.
