FYI; ESPHome firmware now has a native Zigbee component with initial support for building DYI Zigbee end-devices using nrf52 microcontrollers

ESPHome
, , ,
1

FYI; ESPHome 2026.1.0 has now been released with a Zigbee End Device component based on nRF SDK supporting nRF52 platform:

“The zigbee component allows exposing supported ESPHome components over a Zigbee network to Home Assistant via Zigbee2MQTT or ZHA. Due to the limitations of the Zigbee protocol, only basic properties are exposed. Additional properties must be configured manually in Home Assistant. Each ESPHome entity consumes one Zigbee endpoint. Because of a limitation in Zigbee2MQTT, at least two endpoints are required. The maximum number of supported endpoints is eight.”

So far in ESPHome 2026.1 just adds initial support but it already features supports for sensor, binary sensor, and switch functions:

Quote below from the release notes:

Zigbee Support for nRF52

ESPHome now supports Zigbee on nRF52 platforms, bringing a new connectivity option alongside WiFi, Bluetooth, and Thread:

  • Binary sensor support - Expose GPIO states via Zigbee (#11535)
  • Sensor support - Expose ESPHome sensors via Zigbee’s Analog Input cluster with automatic unit mapping ([#12187](https://github.com/esphome/esphome/pull/12187))
  • Switch support - Control ESPHome switches via Zigbee as binary output (#13083)
    wipe_on_boot: once - Wipe network settings only on first boot, preserving connections after OTA updates
  • Framework version support - Configure nRF-SDK version with experimental support for SDK 2.9.2 and 3.2.0 (#12489)

Future of Zigbee End Device support in ESPHome:

Zigbee support in ESPHome is currently available only on nRF52 platforms but there is an open PR to also add ESP32 support as well:

Also be ware that both tomaszduda23 and luar123 also still have their previous work and and side-development with pulls requests open as drafts that offer much more extensive and comprehensive Zigbee device types (which also have much more information and better overview of the project scopes), but I guess that if the two pull requests linked above are accepted and merged into ESPHome mainline then each of their comprehensive work (linked below) will be partially rewritten to align with the new agreed upon standard and formatting.

See these for more background information:

and

To clearify, this whole concept is to allow you to built native Zigbee End Devices using ESPHome firmware, and when ens-users use them it does not use the ESPHome protocol to connect but instead use native Zigbee protocol. I understand this can be confusing for existing ESHome users, as in this scenario you will be developing the device configuration as with any ESPHome device but as the end-user you are using it as any Zigbee devices. So the IoT protocol and transport protocol will be pure Zigbee and can as such in theory be paired with any Zigbee gateway that allow third-party Zigbee devices to connect because it should follow the standard Zigbee specification, but from a development point of view the developers of each will device will use ESPHome configuration to build the device firmware. So, for all intents and purposes it is will be like using ESPHome as an SDK to develop Zigbee devices. The device will as such not function as an ESPHome device from an end users point of view, (so as an end-user you will not be able to use the ESPHome protocol to control it as it will instead function just like any Zigbee end device, and sooner or later this will also have native support for firmware updates via Zigbee OTA).

8 Likes
2

This is an exciting development! I’ve been trying to stick with Zigbee devices where I can, and ESPHome where Zigbee hardware isn’t available or appropriate.

I’ll have to learn more about that endpoint limitation, but I’m looking forward to the day I can develop my own Zigbee devices the same way I do my other ESP hardware.

I agree that some users will struggle to understand the difference between the ESPHome development environment and the way the devices talk to HA. This is not a new issue. Changing the add-on name to “Device Builder” was a good step toward helping people understand that the integration is separate from the development environment.

Once I learned I could do my ESPHome development right on my laptop, instead of on the HA host through the add-on, things became much easier. It’s always good to separate your development and production environments. Maybe with this new capability, more people will start to “get it.”

Thanks to all who made this possible!

1 Like
3

I successfully managed to switch on and off the onboard led of my Tenstar red nrf53840 board over zigbee. I used this yaml

nrf52:
  board: adafruit_itsybitsy_nrf52840
  bootloader: adafruit
  
esphome:
  name: supermini-nrf52840

logger:
  level: DEBUG

zigbee:
  on_join:
    then:
      - logger.log: "Joined network"


switch:
  - platform: gpio
    pin: P0.15
    name: "Board LED"
    id: board_led

I want to control a MeanWell LED PSU with dimming input.

Is it possible with the current zigbee implementation to control pwm output of nrf52?

4

FYI, the initial pull request by luar123 to add support for Zigbee binary sensors on ESP32 (specifically ESP32-H2 and ESP32-C6) has finally been merged to ESPHome mainline so should be included in next month’s ESPHome 2026.5.0 release (to be relesed some time in May of 2026):

Documentation for the upcoming ESPHome 2026.5.0 release has already been updated here:

Should be noted that a recent major change in Espressif’s upstream ESP Zigbee SDK will relativly soon require larger under-the-hood changes in the underlying zigbee_esphome component library that be built to enable this → GitHub - luar123/zigbee_esphome: External zigbee component · GitHub

_Originally posted by luar123 in [zigbee][core] Add support for Zigbee binary sensors on ESP32 H2 and C6 by luar123 · Pull Request #11553 · esphome/esphome · GitHub

I could bring forward more PRs for additional options, sensor, switch and number components quite fast. However, espressif released a version 2.0 zigbee sdk a few days ago. Currently I am implementing it in my external component to test it (this will probably take a few days). If it works well we should consider to update here, or in a separate PR, before the release because they change the zigbee partition type. Overall, changes are large, they dropped zboss in favor of their own stack and integration with esp-idf seems much better. Functional changes are small, so review effort should be low, but all functions/types/macros change names.

For reference see:

In summery:

  • v1.x is based on ZBOSS

    • LTS (Long-Term Support) version, which is under maintenance (bug fixes only, no new features).
    • It is stable for existing products.

  • v2.x is based on Espressif proprietary Zigbee stack

    • A fully self-developed Zigbee stack provides greater flexibility and better capability to meet the evolving requirements of the Zigbee market
    • Full control of the entire stack, enabling better hardware–software adaptation
    • Faster iteration for new features (e.g., Zigbee 4.0, direct) and bug fixes
    • Improved code efficiency and reduced code size

  • Espressif will provide an example demonstrating how to perform OTA from v1.x to v2.0 as soon as possible. In the meantime, you can review their migration guide to understand the differences between v1.x and v2.x.

  • The Zigbee 4.0 certification testing for v2.x is being planned and will be completed as soon as possible.