It is still in very early development and only have some basic functionality, but FYI, “Zigbee Home” (also refered to as “zigbee_home”) is a new open-source DIY Zigbee firmware project by @ffenix113 that aims to (eventually) provide similar ease-of-use and customizability features to ESPHome to allow users to use its CLI application for generating custom firmware their own DIY Zigbee devices (based on nRF52840):
If you can program code in Go programming language (or in C) then suggest check if can help out:
The initial goal of the project is to support nRF52840 microcontroller SoC based devices (with expansion to nRF53 series) and currently has basic support for some inexpensive development boards:
Other than following the ESPHome concept it also seems to take inspiration from PVTO (Zigbee Switch Configurable Firmware) which also allows users to make DIY Zigbee devices but is closed source:
Hello Hedda,
I am the creator of this project, hank you for noticing it! I was not expecting it to get traction so soon, but I welcome new people and ideas that they bring.
If you want to ask or propose anything - I would be glad to answer!
Fun fact: this project started because I wanted to measure CO2 level in our apartment
Yes, battery operated ”sleepy end devices” is one of the major benefit with Zigbee (as well as Z-Wave and Thread) over WiFi, however note that it is not always suited to try to make a battery powered devices for every scenarios/purpose as they are not meant to recieve command messages and reply directly on demand, because their radio ”sleep” so only wake up when they need to send an message and it is only then that they can also recieve a message back (which should just be for things like command to change Zigbee channel or perform OTA firmware upgrade).
Sleepy battery powered Zigbee end devices (Rx is off when idle) are great for sensors that only report in when there is a state change (like for example a door/window sensor or remote) and decices that just report in on a timed intervall (like for example a temperature sensor that simply report in once every 5 minutes).
Tip when making such devices is that it is generally a good idea two use either several lithium batteries or larger high-capacity types lithium batteries. So instead of just a single CR2032 button cell you can either stack multiple of such batteries or use larger ones, so at least use CR2450 or CR2477 (instead of the more common CR2032 which has very low capacity), or batter yet if there is room enough in the device then use CR2 (CR-2/3AZ) or CR123A, all of which are still commonly available. Alternativly stack alkaline batteries like LR14 if there is more room. If making a rechargable device then of course try to go with replacable 18650 batteries.
Newer sleepy Zigbee end devices based on modern radio chip (like nRF52840 or newer) and properly configured power profile do normally only need their batteries replaced every other year or so depending how often they need to wake up and report state updates.
Remeber that also need to add battery reporting, which is something that can be extremly tricky to trim in with lithium batteries because of their battery drain profile.
PS: I personally hate replacing batteries so prefer mains-powered devices, but when it have to to be a battery powered device then I think the batteries must last two years or more before needing replacement, otherwise it is a pain when uou have more than a few battery powered devices.
Very nice project. Would be awesome to be able to build zigbee devices with the same ease ESPHome offers.
I’m building my own rotary dimmer switch and used a TI chip with firmware based on their SKD for the first version (GitHub - dagroe/zigbee-rotary-dimmer-switch: a rotary dimmer switch). Now since there is the ESP C6 available I am looking into that but it seems I should also check out the nRF52840 based on this project.
@ffenix113 have you followed the discussion over at ESPHome regarding the C6 chip?
I might have to rephrase my question
Would i get an extended battery life by just flashing the firmware on the zigbee chip or would it require extra components on the pcb to achieve that?
Hello dagroe,
No, I don’t think that I saw it. Though in discussions of my project @Hedda also asked about ESP support. To sum it up: for now I am focusing on making project good enough for use based on nrf52840 devices, and in the future support for other platforms might be discussed as well.
Would i get an extended battery life by just flashing the firmware on the zigbee chip or would it require extra components on the pcb to achieve that?
It would depend on the previous firmware. The board configuration would define absolute minimum power consumption, while firmware would define ability of the device to achieve that lowest power consumption.
My project will be in lowest power consumption state all the time, except when polling the sensors, which is made possible by Zephyr. For router device this might be different, but routers are not battery powered, so it is not applicable here.
Not directly to other Zigbee devices, but maybe with the help of Zigbee2Mqtt it could be configured to control another device directly.
That should as an example allow one to make a DIY Zigbee flower and plant sensors for soil moisture with configurations can in theory be more easily customized and tweaked via the YAML configuration:
Slightly off-topic but FYI, the pull request that adds an initial native Zigbee component to ESPHome for Zigbee end device support for the nRF52 platform has now been merged into ESPHome, see:
That means that the next upcoming ESPHome release (scheduled for release as ESPHome 2026.1.0 in a couple of weeks from now) will have have initial Zigbee end device support for the nRF52 platform.
Hi,
Could someone explain this at a high level?
My thinking is that ZigBee is both networking and device management/control (via Clusters) and device-discovery/joining.
whereas ESPHome is a bit networking independent (can run over WiFi, Thread) but has its own protocol for device management/control and device-discovery/joining.
So I’m scratching my head on how ZigBee and ESPHome play together.
Both those statements are correct, and I understand why that is confusing, as in this scenario you are 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 because it will follow the Zigbee specification, but from a development point of view the developers of each will device will use ESPHome configuration to build the device firmware. In an intence and purpose 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).
