Native Zigbee End Devices with ESP32-C6 and ESP32-H2: esp-zigbee-sdk vs. Bridging Through Zigbee2MQTT

Most of the ESP32 home automation content on this site talks to Zigbee gear indirectly — running Zigbee2MQTT on a Raspberry Pi and letting an ESP32 sensor report over WiFi or MQTT into that ecosystem. That works, but it isn't the same thing as your ESP32 being a Zigbee device. With the radio-equipped ESP32-C6 and ESP32-H2, Espressif's esp-zigbee-sdk lets a board join a Zigbee mesh directly as a router or end device, appearing to your coordinator exactly like a commercial Zigbee sensor or bulb would. This guide covers when that's actually worth doing instead of just bridging over WiFi, and walks through bringing up a first native Zigbee end device.

Why Bother With Native Zigbee Instead of WiFi/MQTT?

WiFi-based ESP32 sensors (the kind covered in our ESPHome and Home Assistant guides) are easier to set up and easier to debug, and for most projects that's the right call. Native Zigbee earns its complexity in three specific situations: battery-powered sensors where WiFi's power draw is unacceptable (Zigbee's IEEE 802.15.4 radio and mesh sleep behavior sip power compared to associating with a WiFi AP on every wake), dense sensor deployments where you don't want to add another 20 devices to your 2.4GHz WiFi channel, and situations where you want the device to keep working and mesh-repeat traffic even if your home network or MQTT broker is down, since Zigbee traffic never touches your LAN at all.

ESP32-C6 vs ESP32-H2 for Zigbee

ChipRadiosBest For ESP32-H2802.15.4 (Zigbee/Thread) + BLE only, no WiFiPure battery-powered Zigbee end devices — lowest power, cheapest BOM, ideal for sensors that never need WiFi ESP32-C6802.15.4 + WiFi 6 + BLEDevices that need to be a Zigbee router (mains-powered, always-on) or that also need WiFi for local UI, OTA staging, or dual-protocol experiments

If the end device is going to run off a coin cell or AA batteries and just report sensor data, the H2 is the better fit — the WiFi radio on the C6 sits idle silicon you're paying power budget for. If it's mains-powered (a repeater, a bridge, a plugged-in sensor) the C6's extra WiFi capability is worth having.

Setting Up the Toolchain

Install esp-idf (v5.1 or later) following Espressif's standard setup — the Zigbee SDK is an IDF component, not an Arduino library, so this is ESP-IDF territory, not the Arduino IDE.
Clone esp-zigbee-sdk from Espressif's GitHub and add it as a component, or use the idf.py create-project-from-example flow against one of the SDK's example projects (HA_on_off_light and HA_temperature_sensor are the two most useful starting points).
Set your target chip with idf.py set-target esp32h2 (or esp32c6) before the first build — Zigbee support will not build against a plain ESP32, S2, S3, or C3, since only the C6 and H2 have the 802.15.4 radio.

Building a Minimal Temperature/Humidity End Device

The SDK's Home Automation (HA) profile ships a Zigbee Cluster Library (ZCL) implementation, so you're not hand-rolling the Zigbee stack — you're populating clusters. For a temperature sensor:

Start from the HA_temperature_sensor example and confirm it builds and flashes as-is before changing anything.
Wire your sensor (an SHT4x or BME280 over I2C is a clean pairing) and replace the example's simulated readings with real I2C reads, writing the result into the Temperature Measurement cluster's attribute.
Set the device to join as an End Device (not Router) in esp_zb_cfg_t if it's going to sleep — routers are expected to stay awake and forward mesh traffic, and a sleeping router breaks the mesh for everything routed through it.
Enable deep sleep between reporting intervals using the SDK's sleep hooks; a Zigbee end device that wakes, reports, and sleeps again can realistically run a year or more on a pair of AAs, well beyond what an equivalent WiFi sensor achieves on the same battery.

Pairing With Home Assistant

If your coordinator is a Zigbee2MQTT/ZHA setup (see our Raspberry Pi Zigbee2MQTT guide for the coordinator side), your ESP32 end device joins exactly like a commercial Zigbee sensor: put the coordinator into pairing mode, and the ESP32 will associate on its next boot if it isn't already joined to a network. Zigbee2MQTT will usually flag a fully custom ZCL device as "unsupported" until you either match it against a close-enough existing device definition or write a small external converter — the device still works over MQTT once matched, it just doesn't get pretty naming for free.

Zigbee vs Thread on the Same Silicon

It's worth knowing that the same 802.15.4 radio on the C6/H2 also runs Thread (see our Matter/Thread ESP32-C6 guide) — but not both protocols on the same running firmware at the same time. You choose Zigbee or Thread at build time depending on which ecosystem you're targeting. If you're deciding between the two for a new project: Zigbee has the far larger installed base of commercial sensors and a mature open coordinator story (Zigbee2MQTT/ZHA); Thread is the newer, IPv6-native mesh that Matter is standardizing around and is the better bet if long-term ecosystem direction matters more than compatibility with your existing Zigbee bulbs today.

Common Pitfalls

Building against the wrong target. Forgetting idf.py set-target esp32h2 and having IDF silently build for whatever the last project's default was is the single most common first-timer error — you'll get a binary that flashes fine and does nothing.
Router/end-device confusion. Setting a battery device to Router mode will keep the radio awake to relay mesh traffic, killing your battery life in days instead of months.
Antenna layout. The C6/H2 dev boards have a PCB trace or chip antenna tuned for a specific ground-plane clearance — if you're moving the radio onto a custom board, follow Espressif's reference layout closely, since 802.15.4 range is noticeably more layout-sensitive than the ESP32's WiFi radio.

Native Zigbee on the ESP32-C6/H2 is still a smaller, rougher community than the Arduino/ESPHome WiFi path, and documentation leans heavily on reading the SDK's example source rather than polished tutorials. But for battery-powered sensor nodes where months of runtime actually matters, it's a meaningfully different power budget than anything WiFi-based can offer on the same cell, and it's worth the extra ESP-IDF setup friction to get there.

Related Guides

Loading_