1028  Matter Interactions and Commissioning

1028.1 Matter Interaction Model and Commissioning Flow

15 min | Advanced | P08.C46.U03

NoteLearning Objectives

By the end of this section, you will be able to:

• Explain Matter’s five interaction primitives (Read, Write, Subscribe, Invoke, Timed)
• Design subscription strategies for different device types
• Understand the complete commissioning flow from discovery to operational
• Configure discovery methods for different deployment scenarios
• Troubleshoot common interaction and commissioning issues

1028.2 Prerequisites

Before diving into this chapter, you should be familiar with:

• Matter Protocol Stack and Data Model: Understanding nodes, endpoints, clusters, attributes
• Matter Architecture Overview: Introduction to Matter’s architectural concepts
• IoT Protocols Overview: Context for Matter’s position in the protocol landscape

NoteRelated Chapters

Architecture Deep Dives: - Matter Protocol Stack and Data Model - Layered architecture - Matter Fabric and Security - Multi-admin and encryption

Device Implementation: - Matter Device Types and Clusters - Complete cluster library - Matter Implementation - SDKs and development

Transport: - Thread Fundamentals and Roles - Thread mesh networking

1028.3 For Beginners: Understanding Matter Interactions

TipHow Controllers Talk to Devices

Think of Matter interactions like ordering at a restaurant:

• Read = “What’s on the menu?” (checking current state)
• Write = “I’d like to change my order” (modifying settings)
• Subscribe = “Let me know when my food is ready” (getting notifications)
• Invoke = “Please bring the check” (requesting an action)
• Timed = “I need this within 5 minutes” (time-sensitive actions)

When you ask your smart speaker to “turn on the kitchen light,” it: 1. Invokes the On command on the light’s On/Off cluster 2. The light reports back that it’s now on 3. If you’re subscribed, your phone app updates automatically

1028.4 Matter Interaction Model

1028.4.1 Interaction Types Overview

Matter defines how controllers interact with devices through five interaction primitives:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#7F8C8D'}}}%%
graph LR
    subgraph Interactions["Matter Interactions"]
        R[Read<br/>Get attribute values]
        W[Write<br/>Set attribute values]
        S[Subscribe<br/>Receive updates]
        I[Invoke<br/>Execute commands]
        T[Timed<br/>Time-bounded operations]
    end

    Controller[Controller] --> R
    Controller --> W
    Controller --> S
    Controller --> I
    Controller --> T

    R --> Device[Device]
    W --> Device
    S --> Device
    I --> Device
    T --> Device

    style Interactions fill:#2C3E50,stroke:#16A085
    style Controller fill:#16A085,stroke:#2C3E50,color:#fff
    style Device fill:#E67E22,stroke:#2C3E50,color:#fff

Figure 1028.1: Matter Interaction Model with five controller-to-device operation types

{fig-alt=“Matter Interaction Model diagram showing Controller in teal connecting to five interaction types (Read, Write, Subscribe, Invoke, Timed) in navy, all connecting to Device in orange. Illustrates the five ways controllers can interact with Matter devices.”}

Interaction	Purpose	Use Cases
Read	Get current attribute values	Check light state, read temperature
Write	Modify attribute values	Set thermostat setpoint
Subscribe	Receive automatic updates	Real-time sensor monitoring
Invoke	Execute commands	Turn on light, lock door
Timed	Time-bounded operations	Security-sensitive actions

1028.4.2 Read Interaction

Purpose: Retrieve current attribute values from a device

Flow: 1. Controller sends Read Request specifying attribute paths 2. Device responds with Report Data containing current values

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
    participant C as Controller
    participant D as Device

    C->>D: Read Request<br/>[Endpoint 1, OnOff Cluster, OnOff Attribute]
    D->>C: Report Data<br/>[OnOff = true]

Figure 1028.2: Read interaction sequence with attribute request and response

{fig-alt=“Sequence diagram showing Read interaction: Controller sends Read Request specifying Endpoint 1, OnOff Cluster, OnOff Attribute to Device, Device responds with Report Data containing OnOff equals true.”}

Attribute Path Format:

/Endpoint/Cluster/Attribute
Example: /1/0x0006/0x0000 (Endpoint 1, On/Off Cluster, OnOff Attribute)

Wildcard Reads: | Path | Description | |——|————-| | /*/0x0006/* | All attributes of On/Off cluster on all endpoints | | /1/*/* | All attributes of all clusters on Endpoint 1 | | /*/*/0x0000 | Attribute 0x0000 of all clusters on all endpoints |

1028.4.3 Write Interaction

Purpose: Modify writeable attribute values

Example: Setting Thermostat Setpoint

Write Request:
  Path: /1/0x0201/0x0012 (Thermostat, OccupiedHeatingSetpoint)
  Value: 2100 (21.00°C, scaled by 100)

Write Constraints: - Attribute must have Write access (RW in access field) - Value must be within defined constraints (min/max) - ACL must grant Write privilege to requesting node

1028.4.4 Subscribe Interaction

Purpose: Receive automatic updates when attributes change

Subscription Parameters: | Parameter | Description | Typical Value | |———–|————-|—————| | MinInterval | Minimum seconds between reports | 0-60 | | MaxInterval | Maximum seconds before heartbeat | 60-3600 | | FabricFiltered | Filter by requesting fabric | true/false |

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
    participant C as Controller
    participant D as Device

    C->>D: Subscribe Request<br/>[OnOff, MinInterval=1, MaxInterval=60]
    D->>C: Report Data (Initial)<br/>[OnOff = false]
    D->>C: Subscribe Response<br/>[SubscriptionId = 1234]

    Note over D: User presses switch

    D->>C: Report Data (Change)<br/>[OnOff = true]

    Note over D: 60 seconds pass

    D->>C: Report Data (Heartbeat)<br/>[OnOff = true]

Figure 1028.3: Subscribe interaction lifecycle with initial report, change updates, and heartbeats

{fig-alt=“Sequence diagram showing Subscribe interaction lifecycle: Controller sends Subscribe Request, Device responds with initial Report Data and SubscriptionId, then sends Report Data on attribute change when user presses switch, and sends heartbeat Report Data after MaxInterval timeout.”}

Subscription Strategy by Device Type:

Device Type	MinInterval	MaxInterval	Rationale
Motion sensor	0	300	Immediate detection, 5-min heartbeat
Temperature sensor	60	900	Slow-changing, 15-min heartbeat
Door lock	0	60	Security-critical, 1-min heartbeat
Smart light	1	300	Debounce rapid changes

Subscription for Battery Devices:

Sleepy End Devices (SEDs) in Thread networks require special handling: - Parent router queues subscription reports - Device polls parent on wake interval - Configure MaxInterval to exceed sleep period

1028.4.5 Invoke Interaction

Purpose: Execute commands on devices

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
    participant C as Controller
    participant D as Device

    C->>D: Invoke Request<br/>[MoveToLevel, Level=128, Time=10]
    Note over D: Device executes command<br/>Dims to 50% over 1 second
    D->>C: Invoke Response<br/>[Status = SUCCESS]

Figure 1028.4: Invoke interaction sequence for command execution with status response

{fig-alt=“Sequence diagram showing Invoke interaction: Controller sends Invoke Request with MoveToLevel command parameters (Level 128, Time 10), Device executes command dimming to 50% over 1 second, Device responds with Invoke Response Status SUCCESS.”}

Common Invoke Scenarios:

Cluster	Command	Fields
On/Off	Toggle	(none)
Level Control	MoveToLevel	Level, TransitionTime
Door Lock	LockDoor	PINOrRFIDCode (optional)
Thermostat	SetpointRaiseLower	Mode, Amount

1028.4.6 Timed Interaction

Purpose: Time-bounded operations for security-sensitive actions

Why Timed Interactions? - Prevents replay attacks (command must execute within window) - Required for security-critical operations (door locks) - Ensures atomic operation with timeout

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
    participant C as Controller
    participant D as Device

    C->>D: Timed Request<br/>[Timeout = 500ms]
    D->>C: Status Response<br/>[Ready]

    Note over C,D: Controller must send action within 500ms

    C->>D: Invoke Request<br/>[UnlockDoor, Timed]
    D->>C: Invoke Response<br/>[Status = SUCCESS]

Figure 1028.5: Timed interaction for security-sensitive door unlock operation

{fig-alt=“Sequence diagram showing Timed interaction: Controller sends Timed Request with 500ms timeout, Device responds Ready, Controller must send UnlockDoor Invoke Request within timeout window, Device responds with SUCCESS.”}

1028.5 Commissioning Flow

1028.5.1 Complete Commissioning Sequence

Commissioning is the process of adding a new device to a Matter fabric.

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart TB
    Start[Device in<br/>Commissioning Mode]
    Discover[1. Discovery<br/>BLE/Wi-Fi/mDNS]
    PASE[2. PASE Session<br/>Using Setup Code]
    Config[3. Configure Networks<br/>Thread/Wi-Fi credentials]
    Certs[4. Install Certificates<br/>NOC from Fabric CA]
    CASE[5. CASE Session<br/>Verify new identity]
    ACL[6. Configure ACL<br/>Grant permissions]
    Complete[Device Commissioned]

    Start --> Discover
    Discover --> PASE
    PASE --> Config
    Config --> Certs
    Certs --> CASE
    CASE --> ACL
    ACL --> Complete

    style Start fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style Discover fill:#16A085,stroke:#2C3E50,color:#fff
    style PASE fill:#E67E22,stroke:#2C3E50,color:#fff
    style Config fill:#2C3E50,stroke:#16A085,color:#fff
    style Certs fill:#E67E22,stroke:#2C3E50,color:#fff
    style CASE fill:#16A085,stroke:#2C3E50,color:#fff
    style ACL fill:#2C3E50,stroke:#16A085,color:#fff
    style Complete fill:#27ae60,stroke:#2C3E50,color:#fff

Figure 1028.6: Complete Matter commissioning flow from discovery through PASE, CASE, to ACL setup

{fig-alt=“Complete Matter commissioning flowchart showing six sequential steps: Discovery via BLE/Wi-Fi/mDNS, PASE session using setup code, network configuration with Thread/Wi-Fi credentials, certificate installation from Fabric CA, CASE session to verify new identity, ACL configuration to grant permissions, ending with fully commissioned device.”}

1028.5.2 Step-by-Step Commissioning

Step 1: Discovery

Device advertises availability through one of three methods:

Method	Transport	Range	Use Case
BLE	Bluetooth LE	10m	Initial pairing, Thread devices
Wi-Fi Soft-AP	Wi-Fi	30m	Wi-Fi devices without internet
mDNS	IP multicast	LAN	Devices already on network

BLE Advertisement Format:

Service UUID: 0xFFF6 (Matter)
Service Data:
  - Discriminator (12-bit): Device identifier
  - Vendor ID (16-bit): Manufacturer
  - Product ID (16-bit): Device type

Step 2: PASE Session

Passcode Authenticated Session Establishment using setup code from QR/NFC:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
    participant C as Commissioner
    participant D as Device

    Note over C,D: PASE (SPAKE2+)

    C->>D: PBKDFParamRequest<br/>[Iterations, Salt request]
    D->>C: PBKDFParamResponse<br/>[PBKDF parameters]

    Note over C: Derives key from passcode

    C->>D: Pake1<br/>[pA commitment]
    D->>C: Pake2<br/>[pB commitment, cB proof]
    C->>D: Pake3<br/>[cA proof]

    Note over C,D: Session keys established

Figure 1028.7: PASE commissioning sequence with SPAKE2+ key exchange

{fig-alt=“PASE commissioning sequence showing SPAKE2+ exchange: Commissioner and Device exchange PBKDF parameters, Commissioner derives key from passcode (from QR code), three-message Pake exchange establishes session keys.”}

Step 3: Network Configuration

Commissioner provides network credentials:

Network Type	Configuration Data
Thread	Active Operational Dataset (network key, PAN ID, channel)
Wi-Fi	SSID, Password, Security type

Step 4: Certificate Installation

Fabric CA issues Node Operational Certificate (NOC) to device:

Certificate Contents:
  - Subject: Node ID + Fabric ID
  - Public Key: Device's operational key
  - Issuer: Fabric CA
  - Validity: 1 year (renewable)

Step 5: CASE Session

Verify device has valid certificate and establish operational session:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
    participant I as Initiator
    participant R as Responder

    Note over I,R: CASE (Sigma Protocol)

    I->>R: Sigma1<br/>[Initiator random, session ID, destination ID]
    R->>I: Sigma2<br/>[Responder random, NOC, signature]
    I->>R: Sigma3<br/>[Initiator NOC, signature]

    Note over I,R: Session established with AES-CCM encryption

Figure 1028.8: CASE session establishment using three-message Sigma protocol exchange

{fig-alt=“CASE session establishment sequence using Sigma protocol: Initiator sends Sigma1 with random values and destination ID, Responder sends Sigma2 with NOC and signature, Initiator sends Sigma3 with its NOC and signature, resulting in AES-CCM encrypted session.”}

Step 6: ACL Configuration

Commissioner grants appropriate privileges:

Privilege	Capabilities
View	Read attributes, subscribe
Operate	View + invoke commands
Manage	Operate + write attributes
Administer	Manage + modify ACLs

1028.5.3 Multi-Admin Commissioning

Adding a device to additional fabrics (ecosystems):

1. Open commissioning window from existing admin
2. Generate temporary setup code (or reuse original)
3. Commission from new ecosystem using standard flow
4. Device now belongs to multiple fabrics

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
    participant A as Apple Home<br/>(Fabric 1)
    participant D as Smart Lock
    participant G as Google Home<br/>(Fabric 2)

    Note over A,D: Already commissioned

    A->>D: OpenCommissioningWindow<br/>[Timeout=900s]
    D->>A: Response [OK]

    Note over D: Window open, advertising

    G->>D: PASE (setup code)
    G->>D: AddNOC (Google Fabric)
    G->>D: Configure ACL

    Note over D: Now in 2 fabrics

    A->>D: Control (Fabric 1)
    G->>D: Control (Fabric 2)

Figure 1028.9: Multi-admin commissioning adding device to second ecosystem

{fig-alt=“Multi-admin commissioning sequence: Apple Home opens commissioning window on Smart Lock, Google Home performs PASE and adds its NOC, device now responds to both fabrics independently.”}

1028.6 Worked Example: Matter Multi-Fabric Device Setup

NoteWorked Example: Setting Up Multi-Fabric Control

Scenario: You have a new Matter smart lock that you want to control from both Apple Home (used by family) and Google Home (used by your smart display). Configure the lock to work with both ecosystems simultaneously.

Given: - Device: Yale Assure Lock 2 (Matter-compatible, Thread transport) - Setup code (from QR): “34970112332” - Existing Thread network: Apple HomePod Mini as Border Router - Target fabrics: Apple Home Fabric + Google Home Fabric - Maximum fabrics supported by device: 5

Steps:

1. Initial commissioning to Apple Home (Fabric 1):
   • Open Apple Home app on iPhone
   • Scan lock QR code (extracts setup code “34970112332”)
   • iPhone establishes PASE session with lock using setup code
   • Apple Home Fabric CA issues Node Operational Certificate (NOC)
   • NOC contains: Node ID 0x0001, Fabric ID 0xFABRIC_APPLE
   • Lock stores Apple fabric credentials in Fabric Index 1
2. Configure multi-admin (open commissioning window):
   • In Apple Home app: Lock settings -> “Allow other apps to control”
   • This opens 15-minute commissioning window
   • Lock advertises availability via mDNS (Wi-Fi) and Thread MLE
   • Window timeout: 900 seconds (configurable)
3. Commission to Google Home (Fabric 2):
   • Open Google Home app on Android phone
   • Scan same lock QR code (original setup code still valid)
   • Google Home app discovers lock via mDNS/Thread
   • Establishes PASE session (separate from Apple session)
   • Google Home Fabric CA issues separate NOC
   • NOC contains: Node ID 0x0002, Fabric ID 0xFABRIC_GOOGLE
   • Lock stores Google fabric credentials in Fabric Index 2
4. Verify dual-fabric configuration:
   • Lock now has 2 entries in Fabric Table:
     • Fabric 1: Apple Home (NOC with Apple Root CA)
     • Fabric 2: Google Home (NOC with Google Root CA)
   • ACL grants both fabrics Operate privilege
   • Each fabric can independently: Lock/Unlock, Read status, Subscribe
5. Operational behavior:
   • Apple Home: iPhone -> HomePod (Border Router) -> Thread mesh -> Lock (Fabric 1 session)
   • Google Home: Android -> Nest Hub (Border Router) -> Thread mesh -> Lock (Fabric 2 session)
   • Lock maintains separate CASE sessions per fabric (concurrent)

Result: Lock responds to commands from both Apple Home and Google Home. Each ecosystem has independent access through its own fabric with separate certificates and ACLs.

Key Insight: Matter’s multi-fabric architecture enables true multi-vendor control without cloud bridging. Each ecosystem operates independently with its own certificate chain and access controls.

1028.7 Common Pitfalls

CautionPitfall: Subscription Overload on Constrained Devices

The Mistake: Controllers subscribe to many attributes with MinInterval=0 on battery-powered devices, causing excessive wake cycles and rapid battery drain. The device may also run out of subscription slots (typically limited to 3-5 concurrent subscriptions on constrained devices).

Why It Happens: Developers assume immediate updates are always desirable without considering device constraints. Each subscription requires memory for tracking and triggers reports on every change.

The Fix: Design subscriptions based on device capabilities and use case requirements:

// For battery sensors
MinInterval: 60   // Allow 1-minute batching
MaxInterval: 900  // 15-minute heartbeat sufficient
Attributes: Only essential (e.g., Occupancy, not LastMotionTime)

// For mains-powered devices
MinInterval: 0    // Immediate updates OK
MaxInterval: 300  // 5-minute heartbeat
Attributes: Can be more inclusive

Query device’s MaxSubscriptionsPerFabric capability before creating multiple subscriptions.

CautionPitfall: Commissioning Window Timeout During Multi-Admin Setup

The Mistake: Opening a commissioning window, then taking too long to scan QR code in the second ecosystem app. The 15-minute (900 second) default window expires, and commissioning fails with “Device not in commissioning mode” error.

Why It Happens: Users switch between apps, get distracted, or encounter app issues while the window timer continues running on the device.

The Fix: 1. Have the second ecosystem app ready before opening the window 2. Use longer timeout if available: OpenCommissioningWindow(Timeout=1800) for 30 minutes 3. If window expires, simply re-open from the first ecosystem’s app 4. Some apps show remaining time - watch for expiration warnings

1028.8 Knowledge Check

WarningQuick Assessment

NoteAuto-Gradable Questions

Question 1: For occupancy sensors that should notify immediately on state change but also provide periodic heartbeats, which subscription settings are most appropriate?

B. A MinInterval of 0 enables immediate reporting on change, while a nonzero MaxInterval (300s = 5 minutes) provides periodic heartbeat even if value does not change, confirming device is still responsive.

Question 2: Why are Timed Interactions required for security-sensitive operations like door locks?

C. Timed Interactions prevent replay attacks by requiring the actual command to be sent within a short window after the Timed Request. An attacker cannot replay a captured command because the time window has expired.

Question 3: What happens during Step 4 of Matter commissioning (Certificate Installation)?

D. The commissioning fabric’s Certificate Authority issues a Node Operational Certificate (NOC) to the device, containing the device’s Node ID and Fabric ID. This certificate enables the device to participate in the fabric with a verifiable identity.

1028.9 Key Takeaways

TipSummary

1. Five interaction types enable all controller-device communication: Read, Write, Subscribe, Invoke, and Timed

2. Subscriptions provide real-time updates with configurable min/max intervals - design based on device power and use case

3. Timed Interactions protect security-sensitive operations from replay attacks

4. Commissioning has six steps: Discovery, PASE, Network Config, Certificates, CASE, ACL

5. Multi-admin allows one device to belong to multiple ecosystems (fabrics) with independent control

6. Discovery methods include BLE (Thread devices), Wi-Fi Soft-AP, and mDNS (already-networked devices)

1028.10 What’s Next

Continue your Matter architecture deep-dive with:

• Matter Fabric and Security - Understand fabric architecture, CASE/PASE details, and encryption
• Matter Device Types and Clusters - Explore the complete cluster library
• Matter Implementation - Learn about SDKs and building Matter products