Matter, Thread & Zigbee: What IoT Developers Need to Know Before Choosing

If you're building a connected product in 2026, you've almost certainly been asked: "Are you doing Matter or Zigbee?" The answer is less straightforward than the marketing suggests. Having recently built a working Matter pressure sensor on ESP32-C6 and gone through CSA certification on the Zigbee side, here are the practical differences that actually affect your development timeline, cost, and product viability.

First, the Terminology

This is where most confusion starts. Matter and Thread are not the same thing, and neither is a direct replacement for Zigbee.

Thread is a low-power IPv6 mesh networking protocol. It defines how data gets from device A to device B wirelessly. Think of it as the road.

Matter is an application-layer protocol that defines what the data means — "turn on the light," "report pressure is 0.04 kPa." It rides on top of Thread, Wi-Fi, or Ethernet. Think of it as the language spoken on that road.

Zigbee is both the road and the language in one stack. It has its own mesh networking layer (IEEE 802.15.4, same radio as Thread) and its own application layer (ZCL — Zigbee Cluster Library).

So the real comparison is:

• Zigbee (full stack) vs Matter-over-Thread (for battery/low-power devices)

• Zigbee (full stack) vs Matter-over-Wi-Fi (for mains-powered devices)

When someone says "we're switching from Zigbee to Matter," they usually mean Matter-over-Thread, since both use 802.15.4 radios and the hardware is often identical — an ESP32-C6 or ESP32-H2 can run either.

The State of Matter in 2026

Matter has come a long way since the 1.0 release in October 2022. We're now at Matter 1.5, with 30+ supported device types and growing. The multi-ecosystem promise is real: one firmware image, and your device works with Apple Home, Google Home, Amazon Alexa, Samsung SmartThings, and Home Assistant. That is genuinely powerful and was never achievable with Zigbee alone.

But there are significant rough edges.

The Hidden Border Router Requirement

Before getting to OTA, there's a more fundamental friction point: a Matter-over-Thread device is useless without a Thread Border Router in the home. Unlike Zigbee, where any Zigbee coordinator (a USB stick, a hub, a Home Assistant install with ZHA) gets you running, Thread requires a Border Router to bridge the 802.15.4 mesh to the home IP network.

In practice, the Border Router is built into a small set of consumer devices:

• Apple TV 4K (3rd gen) and HomePod mini / HomePod 2

• Google Nest Hub (2nd gen), Nest Hub Max, Nest Wi-Fi Pro

• Amazon Echo (4th gen) and select newer Echo devices

• A standalone option like the Home Assistant Yellow / SkyConnect, or an OpenThread Border Router on a Raspberry Pi

If your customer doesn't already own one of these, your "Matter-compatible" product won't work out of the box. Zigbee doesn't have this problem in the same way — a €30 USB coordinator works with any laptop. This is one of the quieter reasons Matter adoption has been slower than the marketing implied.

Matter-over-Wi-Fi avoids the Border Router issue entirely, but at the cost of significantly higher power consumption — not viable for battery devices.

OTA Firmware Updates: Not Ready

This is the one that catches most developers off guard. The Matter specification defines an OTA Provider/Requestor model, but real-world implementation is fragmented:

• Google Home reportedly still doesn't support anything beyond Matter 1.0 device categories for OTA.

• Apple Home supports OTA for Wi-Fi devices, but Thread device updates fail through Apple Border Routers in some configurations.

• Home Assistant can download OTA images for Thread devices but often fails to apply them, with IPv6 configuration issues being a common cause.

• SmartThings has announced a "controlled rollout" for Matter OTA — still being phased in.

There is no unified firmware distribution mechanism. Each manufacturer hosts their own update server, and each controller needs to know where to look per device type. If you're used to Zigbee OTA (which, while not perfect, has been working reliably for years through coordinators like ZHA and Zigbee2MQTT), the Matter OTA story will feel immature.

For production devices, plan to have an alternative update path. Do not assume Matter OTA will work across all ecosystems your customers use.

CSA Matter Certification: Expensive and Moving

If you're a small company or consultancy, the certification costs are significant (CSA quotes in USD; figures below converted at ~1 USD = 0.92 EUR):

• CSA Adopter membership: ~€6,500/year (minimum tier for self-certification)

• Lab testing: ~€6,500–€9,300 per product

• Certificate application: ~€1,850–€2,800

That's roughly €14,800–€18,500 for your first certified product. And the specification moves quickly — 1.0, 1.1, 1.2, 1.3, 1.4, 1.5 in under four years. Each revision can introduce test harness changes and new mandatory clusters. The test harness itself has dependency management issues; version mismatches cause unexpected failures that cost you lab time.

The CSA has introduced some mitigations: the Certification Transfer Program (CTP) for white-labelling certified platforms, and FastTrack/Rapid Recertification for products built on a certified platform like Espressif's. These help, but the baseline cost remains high compared to Zigbee certification.

Zigbee: The Pragmatic Choice (With Caveats)

Zigbee has over 4,000 certified devices and a decade of production deployments. The tooling is mature, the certification path is well-understood, and sleepy end devices running on coin cells for years are routine.

But Zigbee has its own problems:

• Interoperability is hub-dependent. Cross-brand pairing typically requires a universal coordinator like Home Assistant with ZHA or Zigbee2MQTT. The Zigbee "works with everything" promise requires that middleman.

• Proprietary extensions are rampant. Many manufacturers extend ZCL with custom clusters, breaking cross-vendor compatibility.

• Smart Energy Profile (SEP) is locked down. SEP 1.4a is the latest ratified version with over 250 million deployed devices (mostly utility meters). However, full SEP compliance requires Certicom/Blackberry cryptographic certificates — licensed per-device through Certicom's Device Certificate Authority. This is a separate certification path and adds per-unit cost. It's a significant barrier for smaller players wanting to build energy monitoring products on Zigbee.

Silicon Vendor Support: Espressif vs Silicon Labs

If you're choosing a platform, the silicon vendor matters as much as the protocol. Espressif and Silicon Labs are the two dominant players in 802.15.4 IoT, and they take very different approaches.

Espressif

Here's the practical picture from working with both stacks on Espressif silicon:

Matter (esp-matter / esp-lowcode-matter)

Espressif's Matter support is solid and improving. The esp-matter SDK supports ESP32, ESP32-C3, ESP32-S3, ESP32-C6, and ESP32-H2 with 30+ device types. Their LowCode framework (which I used for the pressure sensor demo) provides an Arduino-like abstraction that significantly reduces time-to-first-device.

Limitations: Matter requires substantially more flash and RAM than Zigbee. The LowCode framework is still in beta and currently ESP32-C6 only. Some newer Matter device types (cameras, energy management) are very recent additions and less battle-tested.

Zigbee (esp-zigbee-sdk)

The esp-zigbee-sdk supports ESP32-H2 and ESP32-C6 as coordinators, routers, and end devices, with 40+ standard ZCL clusters. It works, but the stack is proprietary (unlike the open-source Matter SDK).

The notable gap: Smart Energy. Espressif supports SE-related ZCL clusters at the protocol level, but does not provide full Smart Energy Profile compliance. This is almost certainly because of the Certicom certificate requirement — it's impractical for a silicon vendor to bundle per-device SE certificates in a dev kit. If you need SE, you'll need to handle the Certicom licensing yourself.

Silicon Labs

I've used Silicon Labs' Zigbee stack (EmberZNet) for a CSA-certified sleepy end device on the EFR32MG24, so I can speak to the Zigbee side from direct experience. Their Matter/Thread offering I haven't used first-hand, but the architecture is well-documented.

Zigbee (EmberZNet PRO, GSDK): This is the most mature 802.15.4 Zigbee stack on the market — 15+ years of production deployments. EmberZNet v8.x supports the EFR32MG21, MG24, and the newer Series 3 parts (MG26/MG30). Sleepy end device support is solid and well-documented. Critically, Silicon Labs fully supports Smart Energy with CBKE using Certicom ECC certificates (163k1 for SE 1.0, 283k1 for SE 1.2). This is one of their key differentiators — if you need SE for energy/utility products, SiLabs is the path of least resistance.

A word of caution on SiLabs examples: Having taken a Simplicity Studio Zigbee end device example through to CSA certification, I'm fairly confident the out-of-the-box examples would not pass certification as-is. They're useful as a starting point for learning the API, but there is a real gap between "example that compiles and runs" and "firmware that passes the CSA test harness." You should budget significant engineering time for certification hardening on top of the example code.

This is where Espressif's LowCode approach has an edge. The LowCode runtime is designed to be certification-ready out of the box — the Matter stack, commissioning, transport, and data model are pre-built and (in principle) pre-certified. Your custom code sits on top as application logic. You're not responsible for making the protocol stack pass certification; Espressif is. With SiLabs, you're building on a certified SDK, but the integration is your problem — and subtle issues in event handling, attribute reporting, or sleep behaviour can and do cause certification failures.

Matter (SiLabs Matter SDK): Built on connectedhomeip (same open-source base as Espressif's), currently at v2.8.0 targeting Matter 1.5. Supports Matter-over-Thread on MG24/MG26/MG30 and Matter-over-Wi-Fi on the SiWx917. Less mature than their Zigbee stack but actively developed. SiLabs adds value on top of the open-source base with OTA integration, manufacturing token support, and project generation tooling.

Multiprotocol — SiLabs' trump card: Silicon Labs supports running Zigbee + Thread + Bluetooth concurrently on a single EFR32 radio using the Co-Processor Communication Daemon (CPCd) with a Linux host. This is production-grade and is exactly what Home Assistant's multiprotocol add-on uses under the hood. Thread RCP (Radio Co-Processor) mode with OpenThread Border Router is well-documented (AN1256). Espressif has nothing comparable — an ESP32-C6 can do Wi-Fi + Thread but not concurrent Zigbee + Thread.

Simplicity Studio — the elephant in the room: SSv5 (Eclipse-based) is painful. Slow startup, enormous install footprint, heavyweight UI, and poor CI/CD integration. Anyone who has used it knows the frustration. The good news: SSv6 went GA in October 2025 and is VS Code-based. The Simplicity Studio VS Code Extension hit v2.0.0 in January 2026 and dropped SSv5 support entirely. If you've been avoiding SiLabs because of the tooling, SSv6 is worth a fresh look — though it's still early days and not everything has been ported across yet.

Head-to-Head

My take

If you need to ship a reliable product this quarter with predictable certification costs, Zigbee is still the pragmatic choice — especially for battery-powered devices and energy monitoring.

If you're building for multi-ecosystem interoperability and your timeline allows for the certification overhead, Matter is the strategic bet. The industry investment is undeniable, and the multi-admin fabric model (one device, multiple controllers) is something Zigbee simply cannot do.

For many products, the answer in 2026 is honestly both. Espressif's Matter-Zigbee bridge (ESP32-H2 + ESP32-S3) exists precisely because the transition period is going to last years, not months.

Demo

I've published a Matter pressure sensor implementation using Espressif's LowCode framework as a reference: esp-lowcode-matter (pressure sensor fork). It demonstrates a WSEN-PDUS differential pressure sensor reporting over Matter's Pressure Measurement cluster (0x0403) on an ESP32-C6.

To give a sense of just how minimal the application code is, here's the entire periodic measurement-and-report function:

void app_driver_read_and_report_feature(system_timer_handle_t timer_handle, void *user_data)

{

    float pressure_kpa = 0.0f;

    int ret = pressure_sensor_wsen_pdus_get_kpa(I2C_PORT, &pressure_kpa);

    if (ret != 0) {

        return;

    }

    int16_t matter_value = (int16_t)(pressure_kpa * 10.0f);  // 0.1 kPa units

    low_code_feature_data_t update_data = {

        .details = { .endpoint_id = 1,

                     .feature_id  = LOW_CODE_FEATURE_ID_PRESSURE_SENSOR_VALUE },

        .value   = { .type      = LOW_CODE_VALUE_TYPE_INTEGER,

                     .value_len = sizeof(int16_t),

                     .value     = (uint8_t *)&matter_value },

    };

    low_code_feature_update_to_system(&update_data);

}

That's it. No Matter cluster registration, no commissioning code, no OTA setup, no fabric management — LowCode handles all of that under the hood. Compare that to a few thousand lines of integration glue you'd typically write directly against connectedhomeip, and the appeal of the certification-ready runtime model becomes clear.