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