65 Matter SDKs & Dev Environment

In 60 Seconds

Choosing the right Matter SDK depends on transport and power needs: ESP-Matter (ESP32-C6) for cost-effective Wi-Fi/Thread dual-transport, nRF Connect for ultra-low-power battery Thread devices, and Silicon Labs for Zigbee-to-Matter migration. Thread devices require a Thread Border Router (e.g., HomePod Mini, Nest Hub) in the development setup.

65.1 Matter SDKs and Development Environment

Time: ~10 min | Difficulty: Advanced | Unit: P08.C48.U02

Minimum Viable Understanding

Choosing the right Matter SDK depends on transport and power requirements: use ESP-Matter (ESP32-C6) for cost-effective Wi-Fi/Thread dual-transport, nRF Connect SDK for ultra-low-power battery-operated Thread devices, and Silicon Labs SDK for Zigbee-to-Matter migration. Thread-based devices require a Thread Border Router (e.g., HomePod Mini, Nest Hub) in the development setup for post-commissioning communication.

Learning Objectives

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

Evaluate and contrast the major Matter SDK options based on hardware platform, license, and use case
Select the appropriate SDK based on transport, power, and cost requirements for a given product scenario
Configure a complete Matter development environment including toolchain, SDK, and network infrastructure
Trace the iterative development workflow from code compilation through device commissioning and testing

65.2 Prerequisites

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

Matter Protocol Overview: Understanding Matter’s role and architecture
Matter Architecture and Fabric: Data model, security, and fabric concepts
Matter Device Types and Clusters: Device types and cluster library

For Beginners: What Do You Need to Build a Matter Device?

Building a Matter device requires three things:

Hardware: A microcontroller or processor that can run Matter (ESP32, nRF52, etc.)
SDK: Software libraries that handle all the Matter protocol complexity
Certification: Testing to prove your device works with all Matter controllers

Analogy: Building a Matter device is like opening a restaurant: - Hardware = Your kitchen and equipment - SDK = Recipes and cooking techniques (Matter provides the recipes) - Certification = Health inspection (proves you follow standards)

The good news: Most of the hard work (encryption, networking, commissioning) is done by the SDK. You focus on what makes your device unique - the application logic.

Try It: Matter Device Simulator on ESP32

Objective: Simulate a Matter-compatible smart light bulb demonstrating the Matter data model with clusters, attributes, and commands.

Paste this code into the Wokwi editor:

#include <Arduino.h>

// Simulated Matter device: On/Off Light (Device Type 0x0100)
struct MatterCluster {
  uint16_t id;
  const char* name;
};

struct MatterAttribute {
  uint16_t clusterId;
  uint16_t attrId;
  const char* name;
  const char* value;
};

// Matter clusters for an On/Off Light
MatterCluster clusters[] = {
  {0x0003, "Identify"},
  {0x0004, "Groups"},
  {0x0006, "On/Off"},
  {0x0008, "Level Control"},
  {0x001D, "Descriptor"},
  {0x0028, "Basic Information"},
  {0x003E, "Network Commissioning"},
  {0x0040, "General Diagnostics"}
};
const int NUM_CLUSTERS = 8;

// Device state
bool onOff = false;
uint8_t level = 254;  // 0-254
const char* deviceName = "Matter Light";
uint16_t vendorId = 0xFFF1;
uint16_t productId = 0x8001;
char fabricId[17] = "ABCDEF1234567890";
int commandCount = 0;

void printMatterDataModel();
void handleCommand(const char* cluster, const char* command);
void simulateCommissioning();

void setup() {
  Serial.begin(115200);
  delay(1000);

  Serial.println("==========================================");
  Serial.println("  Matter Smart Light Simulator");
  Serial.println("  Device Type: On/Off Light (0x0100)");
  Serial.println("==========================================\n");

  // Simulate commissioning
  simulateCommissioning();

  // Print data model
  printMatterDataModel();

  // Simulate commands
  Serial.println("\n--- Incoming Matter Commands ---\n");

  handleCommand("On/Off", "On");
  delay(1000);
  handleCommand("Level Control", "MoveToLevel(128)");
  delay(1000);
  handleCommand("On/Off", "Toggle");
  delay(1000);
  handleCommand("On/Off", "On");
  delay(1000);
  handleCommand("Level Control", "MoveToLevel(254)");
  delay(1000);
  handleCommand("Identify", "Identify(10)");
}

void simulateCommissioning() {
  Serial.println("--- Device Commissioning ---\n");
  Serial.println("  Step 1: BLE Advertising...");
  Serial.printf("    Discriminator: 3840\n");
  Serial.printf("    Setup PIN: 20202021\n");
  delay(500);

  Serial.println("  Step 2: PASE (Password Auth)...");
  Serial.println("    Spake2+ key exchange: OK");
  delay(300);

  Serial.println("  Step 3: Certificate provisioning...");
  Serial.printf("    NOC (Node Operational Certificate): Issued\n");
  Serial.printf("    Fabric ID: %s\n", fabricId);
  delay(300);

  Serial.println("  Step 4: Network credentials...");
  Serial.println("    Wi-Fi SSID: HomeNetwork (via Thread/Wi-Fi)");
  delay(300);

  Serial.println("  Step 5: CASE session established");
  Serial.println("    Encrypted channel: AES-CCM-128\n");
  Serial.println("  [COMMISSIONED] Device joined fabric!\n");
}

void printMatterDataModel() {
  Serial.println("--- Matter Data Model ---\n");
  Serial.printf("  Endpoint 0: Root Node\n");
  Serial.printf("  Endpoint 1: On/Off Light\n\n");

  Serial.println("  Clusters on Endpoint 1:");
  for (int i = 0; i < NUM_CLUSTERS; i++) {
    Serial.printf("    0x%04X: %s\n", clusters[i].id, clusters[i].name);
  }

  Serial.printf("\n  Key Attributes:\n");
  Serial.printf("    On/Off (0x0006):       %s\n", onOff ? "ON" : "OFF");
  Serial.printf("    Level (0x0008):        %d/254\n", level);
  Serial.printf("    Device Name (0x0028):  %s\n", deviceName);
  Serial.printf("    Vendor ID:             0x%04X\n", vendorId);
  Serial.printf("    Product ID:            0x%04X\n", productId);
}

void handleCommand(const char* cluster, const char* command) {
  commandCount++;
  Serial.printf("  [CMD %d] %s -> %s\n", commandCount, cluster, command);

  if (strcmp(cluster, "On/Off") == 0) {
    if (strstr(command, "On")) {
      onOff = true;
      Serial.println("    Result: Light ON (attribute updated)");
    } else if (strstr(command, "Off")) {
      onOff = false;
      Serial.println("    Result: Light OFF (attribute updated)");
    } else if (strstr(command, "Toggle")) {
      onOff = !onOff;
      Serial.printf("    Result: Light %s (toggled)\n", onOff ? "ON" : "OFF");
    }
  } else if (strcmp(cluster, "Level Control") == 0) {
    int newLevel = 128;
    sscanf(command, "MoveToLevel(%d)", &newLevel);
    level = newLevel;
    Serial.printf("    Result: Level set to %d/254 (%.0f%%)\n",
      level, 100.0 * level / 254);
  } else if (strcmp(cluster, "Identify") == 0) {
    Serial.println("    Result: Device blinking for identification");
  }
  Serial.printf("    State: %s, Level=%d/254\n\n",
    onOff ? "ON" : "OFF", level);
}

void loop() {
  delay(10000);
  commandCount++;
  // Periodic state report
  Serial.printf("[Status] Light: %s | Level: %d%% | Commands: %d | Fabric: %s\n",
    onOff ? "ON" : "OFF", level * 100 / 254, commandCount, fabricId);
}

What to Observe:

Commissioning follows the standard Matter flow: BLE pairing, PASE, certificate provisioning, CASE
The data model shows endpoints, clusters, and attributes matching the Matter specification
On/Off and Level Control commands update device state following cluster semantics
The fabric ID represents the Matter network the device has joined

65.3 Matter SDK Landscape

65.3.1 Official SDK Options

Matter SDK ecosystem showing three tiers: Official CSA Reference SDK (connectedhomeip) in teal at top, Silicon Vendor SDKs in orange (ESP-Matter, nRF Connect, NXP, Silicon Labs, SimpleLink, Telink) all derived from reference SDK, and Platform SDKs in navy (Apple HomeKit ADK, Google Home tools, Amazon Alexa integration). Arrows show reference SDK flowing to vendor implementations. — Figure 65.1: Matter SDK Ecosystem: Reference SDK, Vendor SDKs, and Platform Integrations

Alternative View: SDK Selection Decision Matrix

This matrix view helps you quickly identify the right SDK based on your primary constraints (transport, power, cost).

Quadrant Guide:

Thread + Battery (top-left): nRF Connect SDK for ultra-low-power sensors
Thread + Mains (top-right): Silicon Labs for powered Thread devices
Wi-Fi + Mains (bottom-right): NXP for high-performance gateways
Wi-Fi + Battery: ESP-Matter for cost-effective battery Wi-Fi (challenging use case)

65.3.2 SDK Comparison

SDK	Platform	License	Best For
connectedhomeip	Linux, RTOS, embedded	Apache 2.0	Reference, custom platforms
ESP-Matter	ESP32 series	Apache 2.0	Cost-effective Wi-Fi/Thread
nRF Connect SDK	nRF52/53/91	Nordic license	Low-power Thread devices
Silicon Labs SDK	EFR32 series	Proprietary	Zigbee to Matter migration
NXP Matter	i.MX, K32W	BSD	High-performance edge

65.3.3 Choosing the Right SDK

SDK selection decision tree: Starting with transport choice (Thread/Wi-Fi/Both), Thread path branches on battery (nRF Connect for battery, Silicon Labs for mains), Wi-Fi path branches on cost (ESP-Matter for cost-sensitive, NXP for performance), Both path branches on existing ecosystem (Silicon Labs for Zigbee migration, ESP-Matter otherwise). Orange endpoints show recommended SDKs. — Figure 65.2: Matter SDK Selection Decision Tree Based on Transport and Requirements

65.4 Development Environment Setup

65.4.1 Hardware Requirements

Minimum Development Setup:

Component	Purpose	Example
Development board	Run Matter device	ESP32-C6-DevKitC
USB cable	Programming/debug	USB-C
Thread Border Router	Network connectivity	Apple HomePod Mini
Controller device	Testing	iPhone/Android phone

Recommended Additions:

Component	Purpose	Example
Second dev board	Controller testing	Nordic nRF52840-DK
Sniffer	Protocol debugging	Nordic nRF52840 Dongle
Logic analyzer	Signal debugging	Saleae Logic 8

65.4.2 Software Setup (ESP-Matter Example)

1. Install Prerequisites:

# Ubuntu/Debian
sudo apt-get install git wget flex bison gperf python3 python3-pip \
    python3-venv cmake ninja-build ccache libffi-dev libssl-dev \
    dfu-util libusb-1.0-0

# macOS
brew install cmake ninja dfu-util python3

2. Clone ESP-IDF and ESP-Matter:

# ESP-IDF (Espressif's IoT Development Framework)
mkdir -p ~/esp
cd ~/esp
git clone --recursive https://github.com/espressif/esp-idf.git
cd esp-idf
git checkout v5.1.2  # Check for latest compatible version
./install.sh esp32c6
source export.sh

# ESP-Matter
cd ~/esp
git clone --recursive https://github.com/espressif/esp-matter.git
cd esp-matter
./install.sh
source export.sh

3. Build and Flash Example:

cd ~/esp/esp-matter/examples/light
idf.py set-target esp32c6
idf.py build
idf.py -p /dev/ttyUSB0 flash monitor

Show code

InlineKnowledgeCheck({
  question: "After cloning ESP-IDF and ESP-Matter, which command sets up the build toolchain for the ESP32-C6 target?",
  answer: "./install.sh esp32c6",
  hint: "Look at step 2 of the ESP-Matter setup — it runs an install script specifying the target chip.",
  successMessage: "Correct! The install.sh script downloads and configures the cross-compilation toolchain, CMake build files, and Python dependencies needed to build firmware for the ESP32-C6.",
  explanation: "The ./install.sh esp32c6 command in the ESP-IDF directory downloads the Xtensa/RISC-V cross-compiler, configures CMake, and sets up Python virtual environments. The source export.sh command that follows adds these tools to your PATH for the current shell session."
})

65.4.3 Development Workflow

Development workflow cycle: Write Code in teal leads to Build, Flash Device, Commission in orange, Test with App in orange, then decision point Working? If no, Check Logs loops back to Write Code. If yes, Add Features loops back to Write Code. Shows iterative development process. — Figure 65.3: Matter Device Development Workflow: Build, Flash, Commission, Test Cycle

Sensor Squad: Setting Up Your Matter Workshop

Max the Microcontroller is ready to help you build your first Matter device! Think of it like setting up a cooking workshop:

The Hardware is your kitchen equipment. You need a microcontroller (like an ESP32) – that is your oven. Different ovens are good for different dishes:

ESP32-C6 – the versatile home oven (does both Wi-Fi and Thread, affordable)
nRF52840 – the energy-efficient slow cooker (amazing for battery-powered devices on Thread)
Silicon Labs EFR32 – the professional kitchen (great if you are upgrading from Zigbee recipes)

The SDK is your recipe book. Matter is complicated, but the SDK handles all the hard parts (encryption, networking, commissioning) so you only write the fun part – what makes YOUR device special!

Lila the LED adds: “If I am a Wi-Fi smart light that is always plugged in, ESP-Matter is perfect. But if Bella the Battery is powering a door sensor, nRF Connect is better because it sips power like a hummingbird.”

Sammy the Sensor reminds you: “If you are building a Thread device, you also need a Thread Border Router in your setup – like a translator that helps Thread devices talk to your Wi-Fi network. Apple HomePod Mini or Google Nest Hub can do this job.”

65.5 Worked Example: Choosing SDK for a Battery-Powered Smart Lock

Worked Example: SDK Selection for a Smart Door Lock with 1-Year Battery Life Target

Scenario: You’re designing a Matter-compatible smart door lock for residential use. The lock must operate for 12+ months on 4 AA batteries (6V, 2850 mAh total capacity), respond to lock/unlock commands within 500 ms, and work with Apple Home, Google Home, and Amazon Alexa.

Requirements:

Battery life: 12 months on 4× AA batteries (2850 mAh capacity)
Latency: <500 ms response to unlock command (security requirement)
Usage: 20 lock/unlock operations per day
Connectivity: Thread (for Matter over low-power mesh)
Ecosystems: Apple + Google + Amazon (multi-admin)
Cost target: <$5 for wireless chip

SDK Evaluation:

Option 1: ESP-Matter with ESP32-C6

Pros: Low cost ($3-4), dual Thread + Wi-Fi, good community support
Cons: Higher sleep current (10-50 µA), less optimized for ultra-low-power
Sleep current: 50 µA (ESP32-C6 deep sleep with RTC)
Active current: 95 mA (Thread RX), 140 mA (Thread TX)
Battery life calculation:
- Sleep time: 24 hours - (20 operations × 3 sec) = 86,340 seconds
- Sleep energy: 50 µA × 86,340 s = 4,317 mAh·s = 1.2 mAh/day
- Active time per operation: 500 ms wake + 2.5 sec lock mechanism = 3 sec
- Active energy per operation: 95 mA × 3 s = 285 mAh·s = 0.08 mAh
- Daily active energy: 0.08 mAh × 20 = 1.6 mAh
- Total daily: 1.2 + 1.6 = 2.8 mAh → Battery life: 2850 / 2.8 = 1,018 days ✅
Verdict: Meets 12-month requirement with margin

Putting Numbers to It

Battery lifetime for IoT devices follows $\text{Battery Life (days)} = \frac{\text{Battery Capacity (mAh)}}{\text{Average Daily Current (mAh/day)}}$. Worked example: ESP32-C6 door lock with 2,850 mAh battery, 20 daily operations (3 sec each), 50 µA sleep current. Sleep: $(50 \times 10^{-3}) \times \frac{86,340}{86,400} = 1.2$ mAh/day. Active: $95 \times \frac{60}{86,400} = 1.6$ mAh/day. Total: $1.2 + 1.6 = 2.8$ mAh/day → $\frac{2,850}{2.8} \approx 1,018$ days (2.8 years).

Option 2: nRF Connect SDK with nRF52840

Pros: Industry-leading low power, optimized Thread stack, excellent battery performance
Cons: Higher cost ($5-7), Thread-only (no Wi-Fi fallback)
Sleep current: 2 µA (nRF52840 System OFF with RTC)
Active current: 5.3 mA (Thread RX), 10.5 mA (Thread TX at 0 dBm)
Battery life calculation:
- Sleep energy: 2 µA × 86,340 s = 173 mAh·s = 0.05 mAh/day
- Active energy per operation: 8 mA (avg) × 3 s = 24 mAh·s = 0.007 mAh
- Daily active energy: 0.007 × 20 = 0.14 mAh
- Total daily: 0.05 + 0.14 = 0.19 mAh → Battery life: 2850 / 0.19 = 15,000 days ✅✅
Verdict: Far exceeds requirement (40× longer), but overkill and more expensive

Option 3: Silicon Labs SDK with EFR32MG24

Pros: Zigbee co-existence (if migrating from Zigbee locks), good power optimization
Cons: Higher cost ($4-6), proprietary SDK (less community support)
Sleep current: 1.7 µA (EM2 with RTC)
Active current: 6.2 mA (Thread RX), 9.6 mA (Thread TX at 0 dBm)
Battery life: Similar to nRF52840, ~12,000 days
Verdict: Excellent choice if migrating existing Zigbee product line

Decision: ESP-Matter with ESP32-C6

Rationale:

Meets battery requirement: 1,018 days >> 365-day target
Cost-effective: $3-4 vs $5-7 for Nordic
Dual-transport: Thread primary, Wi-Fi fallback (future-proofs if Matter-over-Wi-Fi needed)
Development velocity: Larger community, more examples, faster time-to-market
Matter certification: ESP-Matter has reference designs with pre-certified modules

Real-World Validation:

Yale Assure Lock 2 (Matter): ESP32-C6, 12-month battery life ✅
Level Lock+ (Matter): nRF52840, 12-month battery life ✅ (overkill)
August Wi-Fi Smart Lock: ESP32 (Wi-Fi only), 3-month battery life ❌ (too short)

Key Insight: For a door lock with 20 daily operations, ESP32-C6 sleep current (50 µA) is acceptable because the device spends 99.9% of its time sleeping. The sleep current dominates battery life, not the active current. nRF52840’s 2 µA sleep would provide 15× longer battery life, but that’s unnecessary when 3 years already exceeds the 1-year requirement. Save the cost difference for better lock mechanism hardware.

Common Pitfalls

1. Not Pinning the SDK Version

The Matter SDK (project-chip) undergoes frequent breaking changes between releases. Cloning latest HEAD for a production project without pinning a specific release tag leads to unexpected compilation failures and behavior changes.

2. Missing Python Dependencies for Build Scripts

Matter SDK build scripts depend on specific Python packages and versions. Skipping bootstrap.sh or using a system Python instead of a virtual environment frequently causes cryptic build failures that are hard to diagnose.

3. Insufficient Disk Space for SDK Build

A full Matter SDK build including all platforms requires 10–15 GB of disk space for toolchains, libraries, and build artifacts. Attempting to build on a VM with insufficient storage leads to partial compilation failures.

🏷️ Label the Diagram

Code Challenge

Order the Steps

Match the Concepts

65.6 Summary

Key Takeaways

Choose SDK based on transport and power requirements - ESP-Matter for Wi-Fi/Thread dual-transport, nRF Connect for ultra-low-power battery devices, Silicon Labs for Zigbee migration
Hardware selection drives SDK choice - ESP32-C6 for cost-effective dual-transport, nRF52840 for battery optimization, EFR32 for Zigbee ecosystem compatibility
Development environment requires network infrastructure - Thread devices need a Border Router (HomePod Mini, Nest Hub, Echo 4th gen) in addition to the development board
Iterative workflow is essential - Code, build, flash, commission, test, debug, repeat until the device works correctly with ecosystem apps

65.7 Knowledge Check

Quiz: Matter SDKs and Development Environment

65.8 What’s Next

Topic	Chapter	Key Concepts
Device Implementation	Matter Device Implementation and Commissioning	Building device logic, endpoint configuration, commissioning flows
Testing & Certification	Matter Testing and Certification	Test harnesses, interoperability testing, CSA certification process
Matter Architecture	Matter Architecture and Fabric	Data model deep dive, fabric security, multi-admin
Matter Device Types	Matter Device Types and Clusters	Cluster library, device type requirements, attribute definitions
Thread Networking	Thread Network Architecture	Mesh topology, router roles, border router operation
Matter Simulation Lab	Matter Simulation Lab	Hands-on Matter protocol simulations and exercises