What Is Matter?

Detailed Explanation

Matter is the smart-home interoperability standard developed by the Connectivity Standards Alliance (CSA) — the same organisation that maintains the Zigbee specification — with backing from Apple, Google, Amazon, Samsung SmartThings, and dozens of other manufacturers. The core problem Matter solves is fragmentation: before Matter, a smart lock from one vendor and a smart plug from another typically required separate apps, separate hubs, and offered no guarantee of working with a customer's chosen ecosystem. Matter standardises the application layer — what a device is and how it behaves — so any Matter-certified controller can operate any Matter-certified device regardless of manufacturer. For how Matter relates to the wireless protocols underneath it, see Bluetooth vs Wi-Fi vs LoRa vs Zigbee: which protocol should you use?

Matter Is an Application Layer, Not a Radio Protocol

This is the single most common point of confusion. Matter does not define a radio, a modulation scheme, or a network routing algorithm — it defines a data model (device types, clusters, attributes, and commands, conceptually similar to but distinct from Zigbee's Cluster Library) that runs entirely over IP. A Matter "device type" such as On/Off Light or Door Lock exposes a standard set of clusters that any Matter controller understands, but the bytes carrying that traffic travel over whichever IP transport the device uses underneath — Thread, Wi-Fi, or Ethernet. A device manufacturer chooses the transport based on power budget and infrastructure requirements; Matter itself is indifferent to which one is used.

Device Types and the Data Model

Matter defines a growing library of standard device types, each specifying the clusters (functional building blocks) a compliant device of that type must implement. Common device types at initial release included On/Off Light, Dimmable Light, Color Temperature/Extended Color Light, Smart Plug, Door Lock, Window Covering, Thermostat, Contact Sensor, Occupancy Sensor, and Bridge (a device type that exposes non-Matter devices, such as an existing Zigbee network, as Matter endpoints). Subsequent Matter releases have progressively broadened this device type library to cover additional categories — refrigeration and major appliances, air quality and environmental sensors, and energy management devices such as EV chargers and water heaters. Because the device type list is actively maintained by the CSA and expands with each release, check the current Matter specification for the authoritative, up-to-date device type list rather than treating any fixed list as permanent.

The Fabric Model and Multi-Admin

A fabric is a logical, cryptographically-scoped network of commissioned Matter devices and controllers, anchored by a root certificate authority. Critically, Matter supports multi-admin: a single physical device can be commissioned into more than one fabric at the same time, so the same smart bulb can be controlled by an Apple Home fabric and a Google Home fabric simultaneously, each unaware of the other's existence at the protocol level. This is a deliberate design choice to avoid vendor lock-in — a customer is not forced to choose a single ecosystem for their entire home.

Commissioning: QR Code, NFC, and BLE's Role

A new Matter device is commissioned using a setup code — typically an 11-digit numeric code encoding a discriminator and passcode, presented as a QR code on the device or its packaging, or via an NFC tag for tap-to-pair flows. The commissioning sequence generally runs: the controller (a phone app) scans the code, discovers the device over Bluetooth LE (used here purely for initial, low-power discovery and credential exchange — not for ongoing operation), transfers the device's IP network credentials (Wi-Fi SSID/password, or Thread network credentials via the local Thread Border Router), and the device then joins its operational IP network and completes fabric commissioning over IP. Devices that lack a BLE radio can alternatively use IP-based (Wi-Fi SoftAP) commissioning, though BLE commissioning is the more common consumer flow.

Matter Over Thread vs Wi-Fi vs Ethernet

A Matter device's transport choice is a product design decision made independently of the Matter application layer itself, driven by the same power and infrastructure trade-offs relevant to any embedded wireless design: Thread suits low-power, mesh-friendly devices (sensors, locks, battery-powered accessories) but requires a Thread Border Router somewhere in the deployment; Wi-Fi suits higher-power devices that benefit from existing home network infrastructure without needing a mesh; Ethernet suits mains-powered, latency-sensitive, or reliability-critical devices such as hubs and bridges. This transport decision has enough design implications to warrant its own dedicated comparison — see Matter over Thread vs Matter over Wi-Fi: which transport should you choose? for the full power budget and decision framework.

Ecosystem Support

Matter is supported natively by Apple Home (iOS 16.1 and later), Google Home, Amazon Alexa, Samsung SmartThings, and the open-source Home Assistant platform (via its Matter server integration). Each of these can act as a Matter controller and, in most cases, as a Thread Border Router when the underlying hardware includes a Thread radio — for example, recent Apple HomePod mini, Google Nest Hub, and Amazon Echo hardware. Ecosystem-specific certification and app support details change relatively often as vendors update their platforms, so confirm current support status against each ecosystem's own documentation before committing to a specific integration path.

Typical Hardware and SDKs

• Espressif ESP32 (esp-matter) — Espressif's Matter SDK built on ESP-IDF, supporting Matter over Wi-Fi natively and Thread on multiprotocol-capable ESP32 variants; a common choice for Wi-Fi-transport Matter accessories.
• Nordic nRF5340 / nRF52840 (nRF Connect SDK) — Nordic's Matter support targets Thread-transport devices, commonly paired with the nRF Connect SDK's OpenThread stack; the nRF5340's dual-core architecture separates the Matter/application stack from the Thread radio stack.
• Silicon Labs EFR32MG24 — multiprotocol Zigbee/Thread/BLE SoC with Matter support via Silicon Labs' Simplicity SDK, used in both Thread-transport Matter accessories and Matter Bridge products that expose existing Zigbee devices.

For product designs requiring Matter certification, firmware development on esp-matter or the nRF Connect SDK, or Thread/Wi-Fi transport and Border Router architecture, Zeus Design's electronics design team covers the full stack from radio selection through to production.

Design Considerations

• Choose the transport before choosing the SDK. Matter over Thread and Matter over Wi-Fi lead to materially different hardware (radio selection, antenna design, power budget) and firmware stacks (OpenThread vs Wi-Fi networking stack) even though both present the same Matter application layer to controllers.
• Certification is a separate process from implementation. Building on a vendor's Matter SDK does not itself grant Matter certification — formal CSA certification testing is required before a product can use the Matter trademark and be listed as certified, and this should be budgeted into the product timeline separately from firmware development.
• Plan for multi-admin from the start. Because Matter devices are commonly commissioned into more than one fabric, firmware should not assume a single controller "owns" the device — state changes need to propagate correctly to every fabric the device belongs to.
• A Bridge device type can extend a product line without a full protocol rewrite. Manufacturers with existing Zigbee product lines can add Matter interoperability via a Bridge device rather than reimplementing every end device as native Matter.

Common Mistakes

• Treating Matter as a radio protocol to choose instead of Wi-Fi or Thread. Matter is not an alternative to Thread or Wi-Fi — it runs on top of one of them. The actual radio decision (Thread vs Wi-Fi vs Ethernet) is a separate design choice made underneath the Matter application layer.
• Assuming BLE is used for ongoing Matter device communication. BLE's role is limited to the initial commissioning handshake. Confusing this with an always-on BLE connection leads to incorrect power budget and firmware architecture assumptions.
• Designing for a single ecosystem when multi-admin is expected behaviour. Products that hard-code assumptions about belonging to exactly one controller will behave incorrectly once commissioned into a second fabric — a realistic scenario for many consumer deployments.
• Skipping formal Matter certification and assuming SDK compliance is sufficient. Certification testing catches interoperability issues that pure functional testing against one ecosystem's app will not.
• Treating the current device type and cluster list as fixed. The CSA actively extends Matter's device type library with each specification release — verify against the current specification rather than assuming a device category from an earlier release remains complete for a new product design.

For MCU and radio platform selection guidance across Matter, Thread, Zigbee, and other wireless protocols, see how to choose a microcontroller for your project.