Zigbee/Thread support on the new upcoming ESP32-H2 variant?

[levihb]

Describe the problem you have/What new integration you would like

A new variant of the ESP32 was announced last month, the ESP32-H2. It supports 802.15.4 and therefore Zigbee and Thread, as well as BLE, and now runs on a RISC-V architecture which should be a lot more efficient. It also still supports WiFi.

This looks super interesting because it will finally give home users a way to easily build Zigbee/Thread versions instead of WiFi ones. I think ESPHome supporting this would be a brilliant step forward.

Please describe your use case for this integration and alternatives you've tried:

There are no alternatives to ESPHome for Zigbee as far as I know? Or really any simple development environments for home users.

Additional context

Of course the H2 isn't out yet. But I think it'd be good to get a discussion on this going before it is released. Zigbee is definitely a lot more friendly to larger home installations in many ways.

Support for battery operated end Zigbee devices would also be a huge leap forward. And I would think that should be possible on the new H2.

[oxan]

The big open question here is whether some group will port a Zigbee stack to the H2, as that's likely a too big task to do for ESPHome by itself.

[levihb]

The big open question here is whether some group will port a Zigbee stack to the H2, as that's likely a too big task to do for ESPHome by itself.

I asked on the ESP forums. Looks like they haven't released any information publicly yet.

But there will be an OpenThread implementation available. What about potential support for that?

[levihb]

@oxan Excellent news. They have confirmed that there will be a Zigbee stack available!

Hopefully this means we can have a Zigbee ESPHome.

[DelusionalAI]

With thread being IP based, would it be possible to connect it to a ESPHome thread device to a thread-border router and then control it over existing tools like MQTT and the Esphome API?
I believe the only "issue" would be that Thread is IPv6 only, which is being worked on

Controlling my devices over the existing APIs but without worrying about wifi would be amazing, and then you wouldn't be limited to the zigbee protocols.

[oxan]

I looked a tiny bit into this, and getting the API to run on Thread seems like it'll be fairly straighforward. Once devices start becoming available that's probably something we'll work to support.

As for Zigbee, examples using the Z-Boss 3.0 stack have started appearing in the IDF repository last week, so I bet that's what they're going with. There's actually an example of how to use an ESP as a lightbulb. It doesn't seem like it'll be too hard to integrate that into ESPHome as well, in case anyone is interested. I'm happy to help people implementing this, but probably won't work on it myself.

[Drizzt321]

Really interested in this myself! Would love to create a few battery sipping things for myself, particularly Zigbee 3.0.

[Hedda]

With thread being IP based, would it be possible to connect it to a ESPHome thread device to a thread-border router and then control it over existing tools like MQTT and the Esphome AP

That could indeed be possible if Espressif releases a documented CLI or open API for Zigbee NCP or a Zigbee SDK for RCP, and that is something that Tasmota already feature support for but only for Silicon Labs EZSP and Texas Instruments ZNP, see: https://tasmota.github.io/docs/Zigbee/

There is by the way a related similar request here for Silabs EZSP (EmberZNet Serial Protocol) -> #681

There is also a separate request for just pass-through serial stream server (ser2net tunnel) support for Zigbee MCU here -> #688

[kaystrobach]

Related?

https://community.home-assistant.io/t/announcement-esphome-running-on-adafruit-52840-over-thread-mesh-networking-using-zephyrrtos/363712

[HarvsG]

I would very happy to contribute to the esphome team getting an engineering sample ASAP (if it is a matter of $) - Apparently espressif are hoping to get them out in May 2022 according to this reddit post

[Hedda]

Espressif now looks to have released ESP ZBOSS 3.0 binary libraries supporting the Zboss Zigbee 3.0 stack for ESP32 series chips:

https://components.espressif.com/component/espressif/esp-zboss-lib

https://www.esp32.com/viewtopic.php?t=24624

FYI, Espressif has joined "ZBOSS Open Initiative (ZOI)" so chances are they will base is Zigbee stack on ZOI's ZBOSS stack by DRS:

https://dsr-iot.com/news/78

https://www.prweb.com/releases/espressif_joins_zboss_open_initiative_zoi_a_community_for_royalty_free_zigbee_pro_stack_software/prweb18263163.htm

ZOI (ZBOSS Open Initiative) ZBOSS stack look to be available as royalty-free for ZOI members like but not as open source code:

https://dsr-zoi.com/frequently-asked-questions/

https://www.prweb.com/releases/announcing_launch_of_zboss_open_initiative_zoi_for_royalty_free_zigbee_pro_stack_software/prweb16814352.htm

https://dsr-zboss.com/#!/updates/dsr-joins-cmgc-partnership-s2link

All support for it will need be handled though Espressif as implementer and not directly to ZOI or DRS.

There now also looks to be Zigbee examples in Espressif’s IoT Development Framework (ESP-IDF) but no news on SDK or docs?

https://components.espressif.com/component/espressif/esp-zboss-lib

ESP ZBOSS 3.0 Libraries

This repository contains binary libraries supporting the Zboss Zigbee 3.0 stack for ESP32 series chips.

Packages from this repository are uploaded to Espressif’s component serivce. You can add them to your project via idf.py add-dependency

More information about idf-component-manager can be found in Espressif API guide or PyPi registry.

There now looks to be some Zigbee examples in Espressif’s IoT Development Framework (ESP-IDF):

https://components.espressif.com/component/espressif/esp-zboss-lib

https://www.espressif.com/en/products/sdks/esp-idf

https://github.com/espressif/esp-idf

https://github.com/espressif/esp-idf/tree/master/examples/zigbee

Those examples include; Zigbee coordinator ("light coordinator"), "Zigbee RCP (radio co-processor"), and "Zigbee gateway":

https://github.com/espressif/esp-idf/tree/master/examples/zigbee/light_sample/light_coordinator

"light_coordinator is a light coordinator example demonstrating Zigbee Coordinator role. It provides a formation of the Zigbee network. It runs on an 802.15.4 SoC like ESP32-H2. For more details to see the example readme file."

https://github.com/espressif/esp-idf/tree/master/examples/zigbee/esp_zigbee_rcp

https://github.com/espressif/esp-idf/tree/master/examples/zigbee/esp_zigbee_gateway

Wondering if "RPC" works similar to Silicon Labs RPC which works like a dumb radio requiring external ESP ZBOSS 3.0 libraries?

https://components.espressif.com/component/espressif/esp-zboss-lib

"This test code shows how to configure Zigbee rcp (radio co-processor) device. Rcp doesn't function alone, it needs to work together with Zigbee gateway (see esp_zigbee_gateway example)"

"After rcp starts up, it will send its own MAC ieee address and Zigbee stack version number to the Zigbee gateway and start working together with Zigbee gateway via UART communication"

ESP32-H2 has apparently now also already been certified as a “Zigbee Compliant Platform” by CSA:

https://www.espressif.com/en/news/ESP32-H2_Thread_and_Zigbee_certified

https://www.espressif.com/sites/default/files/ESP32-H2%20Zigbee%20Compliant%20Platform%20Certification.pdf

Type of Device: Zigbee Compliant Platform
Zigbee PRO Feature Set (2017)
Manufacturer: Espressif Systems (Shanghai) Co., Ltd.
Model Identification: ESP32-H2
Firmware Version: V1.0
Hardware Version: V1.0
Certification Date: October 20, 2021
Certification ID Number: ZIG21030ZCP27315-24

PS: ESP32-H2 has also passed "Thread Certified Component” certification and will surely also be prioritizing Matter certification:

https://youtu.be/bS9Ch7k_GK0

PPS: They also say Espressif’s IoT Development Framework (ESP-IDF) feature a Thread SDK and that OpenThread is now supported:

https://github.com/espressif/esp-idf/tree/master/examples/openthread

[HarvsG]

@Hedda thanks for that information dump. Could I be bold and ask what the implications for esphome are? Sounds like many of the software stacks are already quite mature. Do you think that the team have enough to work with or do they need the SDK first?

[Hedda]

FYI, ESP-IDF (Espressif IoT Development Framework) look to now have posted an OpenThread RCP (Radio Co-Processor) example:

https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_rcp

I think that is needed for ESPHome to support OpenThread and Matter over Thread on ESP32-H2 with its IEEE 802.15.4 radio?

https://www.espressif.com/en/news/ESP32_H2

At least if that could be built so firmware provides OpenThread RCP (Radio Co-Processor) mode with SPI interface over the Spinel protocol (spinel+hdlc+uart serial protocol) and tunnel that serial stream to agners OTBR addon (OpenThread Border Router add-on via OpenThread adapter in RCP mode) from Home Assistant addons-development repository for testing Thread/Matter support inside Home Assistant:

https://community.home-assistant.io/t/chip-matter-support-including-thread/305633/88

https://github.com/home-assistant/addons-development/tree/master/openthread_border_router

https://github.com/openthread/ot-br-posix/

https://openthread.io/platforms/co-processor

https://github.com/agners

https://community.home-assistant.io/u/agners/summary

Matter upstream SDK also has support for ESP32 (but not sure if that is only over WiFi?):

https://github.com/project-chip/connectedhomeip/tree/master/examples/lighting-app/esp32

The main reason for OpenThread RCP (Radio Co-Processor) support in an "RPC" firmware with OTBR (OpenThread Border Router) support will make ESP32-H2 with its IEEE 802.15.4 radio compatible with the upcoming Thread stack / IEEE 802.15.4 radio based "Matter" (Project CHIP / Connected Home over IP) devices if used in Home Assistant with their other add-ons for the that is also in development. That addon by agners requires that the IEEE 802.15.4 radio have a OpenThread firmware in "RPC" mode instead of the no traditional "NCP" mode of OpenThread stack running on the IEEE 802.15.4 radio:

https://github.com/home-assistant/addons-development/tree/master/chip_controller_repl

https://github.com/home-assistant/addons-development/tree/master/chip_tool

https://github.com/project-chip/connectedhomeip

https://buildwithmatter.com

https://csa-iot.org/all-solutions/matter/

Also having optional OpenThread "NCP" border router firmware would allow users to alternatively use other existing OpenThread applications that use "NCP" mode instead of the newer "RPC" mode which require additional component running on the host. Ex:

https://github.com/openthread/wpantund

Note that as far as I read so far agners has only worked with Silicon Labs based adapter with OpenThread "RPC" firmware for Thread / EEE 802.15.4 radio based Matter (as well as ESP32-C3 based devkit for Matter over WiFi) and that is only because it is a Silabs EFR32MG21 chip based adapter that will ship inside the official Home Assistant Yellow (formerly Home Assistant Amber) hardware as well as the upcoming official Home Assistant SkyConnect USB Stick dongle:

zigpy/zigpy#894

https://github.com/home-assistant/addons-development/tree/master/silabs-multiprotocol

https://www.home-assistant.io/blog/2021/09/13/home-assistant-yellow/

https://www.crowdsupply.com/nabu-casa/home-assistant-yellow

https://community.home-assistant.io/t/home-assistant-skyconnect-usb-stick-announced-will-be-compatible-with-both-zigbee-and-thread-including-matter-chip-over-thread/433594

[Hedda]

FYI, see they now also released ESP ZBOSS 3.0 binary libraries (esp_zboss_lib) to support Zboss Zigbee 3.0 stack on chips like ESP32-H2:

https://github.com/espressif/esp-zboss-lib

Again that could be used with their "ESP" Zigbee RPC + Gateway examples with their ESP32-H2 DevKitC (ESP32-H2-DevKitC-1 V2.1) board:

https://github.com/espressif/esp-idf/tree/master/examples/zigbee/

https://github.com/espressif/esp-idf/blob/master/examples/zigbee/esp_zigbee_rcp

https://github.com/espressif/esp-idf/tree/master/examples/zigbee/esp_zigbee_gateway

Home Assistant's ZHA integration would need a ZBOSS (e.g. zigpy-zboss) radio library to be able to use it as a remote Zigbee Coordinator in serial pass-through mode.

https://www.home-assistant.io/integrations/zha

https://github.com/zigpy/zigpy

Compatible zigpy radio libraries

• Texas Instruments based Zigbee radios with all compatible Z-Stack firmware via the zigpy-znp library for zigpy.
• Silicon Labs (EmberZNet) based Zigbee radios using the EZSP protocol via the bellows library for zigpy.
• dresden elektronik deCONZ based Zigbee radios via the zigpy-deconz library for zigpy.
• ZiGate based ZigBee radios via the zigpy-zigate library for zigpy.
• Digi XBee based Zigbee radios via the zigpy-xbee library for zigpy.

[Hedda]

ESP32-C6 SoC, module and development board has now been launched with WiFi 6, BLE 5.0, and 802.15.4, ink. OpenThread and Zigbee! ...so think these could be perfect for ESPHome as either a Thread Board Router (for Matter) or as a Zigbee Router device.

https://www.espressif.com.cn/en/news/ESP32-C6_Available

https://espressif-docs.readthedocs-hosted.com/projects/espressif-esp-dev-kits/en/latest/esp32c6/esp32-c6-devkitc-1/index.html

espressif/esp-idf#10423

Espressif launched the ESP32-C6 WiFi 6, Bluetooth 5.0 LE, and 802.15.4 IoT microcontroller by making the ESP32-C6-WROOM-1 module:

https://www.cnx-software.com/2021/04/11/esp32-c6-wifi-6-and-bluetooth-le-risc-v-soc-for-iot-devices/

Espressif Systems has finally launched the ESP32-C6 WiFi 6, Bluetooth 5.0 LE, and 802.15.4 IoT microcontroller by making the ESP32-C6-WROOM-1 module available on Aliexpress for $14.25 for a pack of 5 modules as well as the ESP32-C6-DevKitC-1 development board that’s out of stock on the official store at the time of writing. but somehow listed in another store for $16.22 plus shipping.

Besides the availability announcement, another surprise is the 802.15.4 radio for Zigbee and Thread that was not part of the original ESP32-C6 announcement in April 2021. The ESP32-C6-DevKitC-1 development board comes with a module with 8MB flash, exposes most of the I/O’s from the ESP32-C3, and comes with two USB-C ports, two buttons, and an RGB LED.

ESP32-C6-DevKitC-1 development board specifications:

• Wireless module – ESP32-C6-WROOM-1 with
  • ESP32-C6 single-core 32-bit RISC-V clocked up to 160 MHz 320KB ROM, 512KB SRAM, low-power RISC-V core @ up to 20 MHz
  • Wireless – 2.4 GHz WiFi 6, Bluetooth 5.0 LE, 802.15.4 radio for Zigbee 3.0 and Thread. Matter compatible. PCB antenna
    8MB SPI flash
• USB – 1x USB Type-C host port, 1x USB Type-C port via UART console
• I/Os – 2x 16-pin headers with GPIO, UART, SPI, ADC, SDIO, USB, I2S, etc…
• Misc – Reset and BOOT buttons, RGB LED, J5 header/jumper for current measurement
• Power Supply (mutually exclusive options)
  • 5V via USB-UART port (recommended)
  • 5V and GND pin headers
  • 3V3 and GND pin headers
• Dimensions – 51.8 x ~20 mm

The new ESP32-C6 module and development board work with the ESP-IDF v5.1, currently under development (see progress report), and some basic documentation can be found on read the docs.

If you can’t purchase an ESP32-C6 module or board just yet due to limited supplies, don’t despair as more are coming very soon as Espressif tells us to expect more products on Adafruit, Akizuki, Digikey, and Mouser.

[MiguelAngelLV]

The C6 board can be a perfect board for esphome. Wifi, BLE, Zigbee and Thread in only one board!

[Hedda]

The C6 board can be a perfect board for esphome. Wifi, BLE, Zigbee and Thread in only one board!

Well almost. I understand Zigbee and Thread are currently mutually exclusive, so can not use Zigbee and Thread at the same time.

At least it should allow having many separate ESPHome-based devices with different functions utilizing either Thread or Zigbee.

• "WiFi to Thread Board Router" device as an OpenThread Border Router (OTBR) managed by ESPHome.
• "Zigbee Router" device as a Zigbee repeater/extender managed by ESPHome.
• "Zigbee End Device" device as a Zigbee sensor that can be managed by ESPHome.
• "Zigbee Coordinator", ei.. a dumb remote radio adapter for Home Assistant's ZHA integration (requires radio library in zigpy).
• "Zigbee Gateway" native bridge device (like the Zigbee 2 Tasmota project).

I especially think that ESPHome devices could be perfect as a "Thread Board Router" (for Matter) or as a "Zigbee Router" device.

• The new Matter standard) need many "Thread Board Router" (OpenThread Border Router, a.k.a. OTBR) to connect to a Thread network in order to make it both more redundant and more stable, as a Thread Board Router acts as a network bridge to connect your normal LAN network to the Thread network and it also uses network mesh technology so having more Thread devices will add better range and coverage. See -> https://github.com/espressif/esp-idf/tree/master/examples/openthread

• "Zigbee Router" device support to make it work like a Zigbee router/extender as Zigbee also uses network mesh technology so simply adding more "Zigbee Router" devices to your Zigbee network will improve range and coverage for the whole Zigbee network. See -> https://github.com/espressif/esp-idf/tree/master/examples/zigbee/

• "Zigbee End Device" device can be a Zigbee sensor that can be managed by ESPHome. See -> https://github.com/espressif/esp-idf/tree/master/examples/zigbee/

• "Zigbee Coordinator" adapter based on ESPHome using other Zigbee chips that can simply tunnel/passthrough the serial connection to Home Assistant's ZHA integration are already popular, like tube gateways from tube0013, but then you would need to add radio library for zigpy) that has support for ESP ZBOSS. see -> esp-zboss-lib and esp_zigbee_rcp

• "Zigbee Gateway" as a stand-alone Zigbee gateway/bridge/hub with native support to pair other Zigbee devices directly like the Zigbee 2 Tasmota project which is probably more complex? See -> https://github.com/espressif/esp-idf/tree/master/examples/zigbee/esp_zigbee_gateway

[linkedupbits]

I am starting to work on at least getting native esphome support for the esp32-c6-DevKitC-1.
I have created a pull request to add support to espressive's esptool-js for this board - this library is used by esp-web-tools to flash the board.
I have successfuly uploaded a zigbee espressive sample firmware to the esp32-c6-DevKitC-1 via my local build of esptool-js (but binaries built via esp-idf).
Then I a local tar.gz of the esp-web-tools library, and dropped it into my local esp-web-tools , and was able to connect to the serial log output, but not able to upload a firmware built by ESPHome.

Where would I find an esp-idf project file for any of the "standard" new device firmwares eg esphome-web-esp32c3.bin or esphome-web-esp32s2.bin for bootstrapping into ESPHOme?
I could then adapt this to build a base new device firmware for this board.

[Hedda]

Where would I find an esp-idf project file for any of the "standard" new device firmwares eg esphome-web-esp32c3.bin or esphome-web-esp32s2.bin for bootstrapping into ESPHOme?

Probably best if you start a new dedicated issue for that question

https://github.com/esphome/feature-requests/

https://github.com/esphome/esp-web-tools/

https://esphome.github.io/esp-web-tools/

https://web.esphome.io/

[rotilho]

I am starting to work on at least getting native esphome support for the esp32-c6-DevKitC-1.
I have created a pull request to add support to espressive's esptool-js for this board - this library is used by esp-web-tools to flash the board.
I have successfuly uploaded a zigbee espressive sample firmware to the esp32-c6-DevKitC-1 via my local build of esptool-js (but binaries built via esp-idf).
Then I a local tar.gz of the esp-web-tools library, and dropped it into my local esp-web-tools , and was able to connect to the serial log output, but not able to upload a firmware built by ESPHome.

Where would I find an esp-idf project file for any of the "standard" new device firmwares eg esphome-web-esp32c3.bin or esphome-web-esp32s2.bin for bootstrapping into ESPHOme?
I could then adapt this to build a base new device firmware for this board.

You may be interested in this fork. @stintel managed to flash a C6.

https://github.com/stintel/esphome/tree/esp32c6

[Hedda]

FYI, 01Space is sell a tiny ESP32-C6 IoT dev board based on ESP32-C6-WROOM-1 wireless module with two 10-pin headers + USB-C for power:

https://www.aliexpress.us/item/3256805225446433.html

ESP32-C6 Arduino support will require ESP IDF 5.1 framework which is still under development:

espressif/arduino-esp32#7713

espressif/arduino-esp32#7852

[sandervandegeijn]

• ZHA integration

Don't forget zigbee2mqtt, this is one of the most mature solutions when it comes to interface with zigbeestuff through mqtt :)

[Hedda]

Don't forget zigbee2mqtt

Zigbee2MQTT support is off-topic here as zboss adapter (esp-zboss) support would have to be implemented into the zigbee-herdsman library it depends on and that has nothing to do with ESPHome or Home Assistant, so you would instead have to post a request there instead -> https://github.com/Koenkk/zigbee-herdsman

[Hedda]

Espressif now looks to have released ESP ZBOSS 3.0 binary libraries supporting the Zboss Zigbee 3.0 stack for ESP32 series chips

FYI, indirectly related; you can now use a Nordic Semi nRF52840 dongle as a Zigbee Coordinator inside ZHA via zigpy-zboss:

https://github.com/kardia-as/zigpy-zboss

This ZBOSS radio library for zigpy is unofficial and still experimental so testers need to manually it to ZHA in Home Assistant:

zigpy/zigpy#394

That should for now at least make it usable to use either nRF52840 USB dongle or nRF52840 dev kits with the correct firmware.

https://www.nordicsemi.com/Products/Development-hardware/nrf52840-dongle

nRF52840 Dongle only costs about $10 USD so great value for people looking to test Zigbee. nRF52840 DK cost about $60 USD:

https://www.nordicsemi.com/Products/Development-hardware/nrf52840-dk

Perhaps more interesting for ESPHome developers is that if and when this zigpy-zboss library gets developed further then it could possibly enable users to use an ESP32-C6 (or ESP32-H2) module with ESPHome as a remote Zigbee Coordinator adapter for ZHA.

https://www.home-assistant.io/integrations/zha

[wombat70]

Espressif announced their ESP Thread BR dev platform:
https://www.hackster.io/news/espressif-launches-a-kit-to-turn-its-esp32-modules-into-certified-thread-border-routers-for-matter-c61db0fce050

[Hedda]

Espressif announced their ESP Thread BR dev platform:
https://www.hackster.io/news/espressif-launches-a-kit-to-turn-its-esp32-modules-into-certified-thread-border-routers-for-matter-c61db0fce050

Nice! That is a new ESP32-H2 + ESP32-C3 combo development board kit and ESP Thread Boarder Router SDK which as been certified as a Thread Border Router (TBR) / OpenThread Border Router (OTBR) which can be used for Matter based on the Thread 1.3 standard, alternatively be used as an as Zigbee gateway/hub or bridge, and they also got an optional Ethernet Sub-Board

https://www.cnx-software.com/2023/06/20/espressif-esp-thread-border-router-board-combines-esp32-h2-esp32-c3-wireless-chips/

https://github.com/espressif/esp-thread-br

https://docs.espressif.com/projects/esp-thread-br/en/latest/esp32/

https://www.aliexpress.us/item/1005005688193617.html

PS: An earlier two-board ESP Thread Border Router solution was previously available as an example project for reference:

https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_br

https://openthread.io/guides/border-router/espressif-esp32

and optional Optional Ethernet Sub Board

[MiguelAngelLV]

Hello @Hedda and all others,

I just want to inform you all that I am now investigating/working on a wrapper for Zigbee to make it simple to use in Arduino. For now we have provided Zigbee libraries + 4 ported IDF examples, which are huge and not that easy to use for someone new to Zigbee.

The wrapper is still in early stage of development, when there are news or some draft, I will keep you updated and link the PR here in a comment :)

With a few simples examples (light, switch...) anyone could be create a custom component for EspHome 👍

[Hedda]

FYI, also noticed their Zigbee examples in the arduino-esp32 repository looks updated to work with the latest libraires, check out:

https://github.com/espressif/arduino-esp32/tree/master/libraries/ESP32/examples/Zigbee

For reference, those exampled seems to have been cherry-picked and synchronized from a few of the esp-zigbee-sdk examples:

https://github.com/espressif/esp-zigbee-sdk/tree/main/examples/

PS: For more simple Zigbee examples check out this directory for "Zigbee HA" profiles (ZHA profile specs) in the esp-zigbee-sdk:

https://github.com/espressif/esp-zigbee-sdk/tree/main/examples/esp_zigbee_HA_sample

[luar123]

Here is the first version of the external component: https://github.com/luar123/zigbee_esphome
For now support is limited to sensor/actor end devices and the whole zigbee structure needs to be defined in the yaml. Lambdas are used for setting or receiving attribute changes.

@P-R-O-C-H-Y: Also have a look at https://github.com/Muk911/esphome/blob/main/esp32c6/hello-zigbee

I want to donate 50 eur to the person(s) that can get this working (with most components working and working with home assistant)

To make this just work without any additional setup (like mqtt/HA api) there is a lot of work needed. For simple sensors or e.g. lights where we have support from default zigbee clusters it should be rather simple. But to support all types of components also custom clusters needs to be defined and integrated into the coordinator software (z2m, ZHA, etc).

[micfogas]

Here is the first version of the external component:

I haven't looked at your code yet but nice job creating something.

This made me realize an important detail though, which I think Jesse will have to answer on. Should efforts still be made to implement zigbee on this new hardware, or would time be better spent on creating the components for the Thread layer and Matter layer?

Obviously, the ESP32-H2, TBRG, and the thread-capable dev boards like the C6, will need the thread sublayer component. Matter can work over WiFi, Ethernet, Thread... Jesse is probably aware of the HA efforts with Matter (I haven't had time to keep up on it myself), and Matter will be able to replace the API (eventually ....).

Jesse would really be the one to comment about his plans and direction regarding Matter. With a Matter-compatible backend (whether he plans to add another layer under the API to translate to Matter, create a separate project that will use ESPHone yaml on the front end and Matter on the back end, or just ignore Matter). There's not much point in the Thread sublayer if there's no plans to use Matter.

Maybe it's best to find out what his plans are.

[Hedda]

Here is the first version of the external component: https://github.com/luar123/zigbee_esphome For now support is limited to sensor/actor end devices and the whole zigbee structure needs to be defined in the yaml. Lambdas are used for setting or receiving attribute changes.

@P-R-O-C-H-Y: Also have a look at https://github.com/Muk911/esphome/blob/main/esp32c6/hello-zigbee

@luar123 @Muk911 also check out Zigbee PoC for ESPHome on nRF52/nRF53 by @tomaszduda23 in tomaszduda23/esphome#2

What does this implement/fix?

zigbee support

Types of changes

Related issue or feature (if applicable): fixes esphome/feature-requests#1397

Example entry for config.yaml:

switch:
  - platform: zigbee
    output: gpio_15
    id: zigbee1
  - platform: zigbee
    output: gpio_15
    id: zigbee2

[tomaszduda23]

esphome is based on just only 17 different entity types. You could cover a lot of use cases with just those.

3.14.2 Analog Input (Basic)
3.14.3 Analog Output (Basic)
3.14.5 Binary Input (Basic)
3.14.6 Binary Output (Basic)

There is Description and ApplicationType which could be used to distinguish different entities. Probably it would be good enough for most people.

Matter sounds cool. It requires IPv6 though. If there is IPv6 you could also just use native API.

[thardie]

Here is the first version of the external component:

I haven't looked at your code yet but nice job creating something.

This made me realize an important detail though, which I think Jesse will have to answer on. Should efforts still be made to implement zigbee on this new hardware, or would time be better spent on creating the components for the Thread layer and Matter layer?

Obviously, the ESP32-H2, TBRG, and the thread-capable dev boards like the C6, will need the thread sublayer component. Matter can work over WiFi, Ethernet, Thread... Jesse is probably aware of the HA efforts with Matter (I haven't had time to keep up on it myself), and Matter will be able to replace the API (eventually ....).

Jesse would really be the one to comment about his plans and direction regarding Matter. With a Matter-compatible backend (whether he plans to add another layer under the API to translate to Matter, create a separate project that will use ESPHone yaml on the front end and Matter on the back end, or just ignore Matter). There's not much point in the Thread sublayer if there's no plans to use Matter.

Maybe it's best to find out what his plans are.

I've used Zigbee a lot, and it's just not super reliable. I've started to use thread recently with Home Assistant, and it's immediately more reliable than Zigbee. Yes, Thread requires IPv6, but it's not the same as IPv6 over WiFi. WiFi takes a LOT more power to keep active, whereas Thread needs way less radio time and is much more power efficient.

I use ESPHome a LOT and am super looking forward to developing things that can run on batteries with ESPHome. Right now, the power requirements for WiFi make that infeasible. (Think AA batteries you would want to last for several months at least)

[gudvinr]

WiFi takes a LOT more power to keep active, whereas Thread needs way less radio time and is much more power efficient.

Do you have the data to corroborate that?

[thardie]

WiFi takes a LOT more power to keep active, whereas Thread needs way less radio time and is much more power efficient.

Do you have the data to corroborate that?

WiFi needs to continually respond to an access point, and if an endpoint sends a packet to a WiFi station and it's not available (IE, in sleep) the packet is dropped. In Thread (and the underlying zigbee transport) the system has a way to deal with nodes being asleep for long periods of time. Here's an interesting article talking about it

[gudvinr]

Here's an interesting article talking about it

This might explain "way less radio time" but doesn't cover "much more power efficient" part. How efficient is "much more"? For which use case?
Without numbers it doesn't mean anything. If your argument implies quantitative improvement you either back it using real data or don't say it at all.

Not to mention that this particular article as well as source of the data doesn't even have numbers for WiFi.

What you say is kinda sorta "common knowledge" but in reality, for the user, "a LOT more power to keep [WiFi] active" should not matter that much if you only turn on the radio once in a very long while while using ULP coprocessor to do most of the work.
If you don't turn off the radio or use it frequently, it could improve battery life but that is different use case. But again, it is a very big question how much. Because it might not matter at all if sensors and/or ESP itself being active could draw even more power.

So it is not as simple as Zigbee is more betterer.

[Hedda]

Here's an interesting article talking about it

This might explain "way less radio time" but doesn't cover "much more power efficient" part. How efficient is "much more"? For which use case? Without numbers it doesn't mean anything. If your argument implies quantitative improvement you either back it using real data or don't say it at all.

Not to mention that this particular article as well as source of the data doesn't even have numbers for WiFi.

@gudvinr @thardie (update: and @gsgxnet) please take that whole discussion elseware as such discussions does not belong here under this feature request issues tracker. This is only a feature request for native ESPHome support, as such any discussions about Zigbee versus Thread versus WiFi are only spam people following this and it brings nothing to contibuting to making any these features actually being added to ESPHome. Suggest that you instead post such under the discussion section in the esphome repo instead -> https://github.com/esphome/esphome/discussions or better yet post Home Assistant’s community forum instead. Not here under the issues section which is just for feature requests, not protocol pros and cons discussions.

[gsgxnet]

I use ESPHome a LOT and am super looking forward to developing things that can run on batteries with ESPHome. Right now, the power requirements for WiFi make that infeasible. (Think AA batteries you would want to last for several months at least)

Shelly has some battery & USB powered WiFi devices which can be run for longer time on batteries. They mostly use the ESP-32 deep sleep option to get more than a year runtime one one set of 4 AA batteries. And an epaper display. Still Thread might have lower power consumption. Would have to look into details where most of the power goes when an ESP-32 device is not in deep sleep.

[Hedda]

FYI, you should also be aware that recently Espressif's employee/developer @P-R-O-C-H-Y istarted working on a Zigbee Wrapper for Arduino for Espressif's esp-zigbee-sdk with a simpler API in Arduino added to the arduino-esp32 library, and he wrote that other developers can post additional feature request related to that in the same issue there for tracking. See:

• Implement Zigbee in Arduino espressif/arduino-esp32#10135

His upstream work with that Zigbee Wrapper for Arduino (arduino-esp32) is in turn is something that will quite possibly make it easier to implement Zigbee support for it in ESPHome (and Tasmota) or other ESP32 firmware projects as they are depending on APIs like that for easier implementations downstream.

[DNA99]

FYI, Espressif developer @P-R-O-C-H-Y is now working on a Zigbee Wrapper library with an simpler API in Arduino for arduino-esp32 and he wrote that other developers can post additional feature request related to that in the same issue there for tracking:

• Implement Zigbee in Arduino espressif/arduino-esp32#10135

Do you know if they have any plans to make zigbee available in Esphome? And how about ESP-Now?

[Hedda]

FYI, some other project developers (including Tasmota's lead developer) have decided to fork Platformio's platform-espressif32 library due to lack of official PlatformIO development because of this conflict that they PlatformIO have with Espressif that have now made them even refuse to review and merge community patches to Platformio's platform-espressif32 library:

• pioarduino and Tasmota developers felt forced to fork Platformio's platform-espressif32 ( Espressif ESP32 Arduino Core development platform) in order to add support for Arduino ESP32 v3.0 and later esphome#7334

Since it is now clear that there will be no official support for Arduino core 3.0.x from Platformio team, (Issue No. 1225 in repo https://github.com/platformio/platform-espressif32/issues) i decided to fork the needed repo(s) and build a community version to support core 3.0.x (starting with core 3.0.3)

(Originally posted by Jason2866 in espressif/arduino-esp32#10039)

Thus if you want to use Espressif Arduino 3.0.x and IDF 5.1.x with newer ESP32 SoCs like ESP32-C6 and ESP32-H2 then you might need to consider using pioarduino's fork of the platform-espressif32 instead of the "official" platform-espressif32 from Platformio.

• https://github.com/pioarduino/platform-espressif32

For additional information, please refer to these GitHub links:

• Community Platformio support for Arduino core 3.0.3 and 3.0.4 espressif/arduino-esp32#10039
• Support Arduino ESP32 v3.0 based on ESP-IDF v5.1 platformio/platform-espressif32#1225
• Documentation - Update supported IDEs and general improvements espressif/arduino-esp32#8606

FYI, Espressif released "stable" version 3.0.0 Arduino ESP32 Core based on ESP-IDF v5.1.4 with support for ESP32-H2 and ESP32-C6

https://github.com/espressif/arduino-esp32/releases/tag/3.0.0

(Arduino ESP32 core v3.0.0 was first announced over 7-months ago but this updated version is now finally been marked as stable).

However, we still need PlatformIO to add Arduino v3.0.0 support for it in platform-espressif32 too which might never happen?

• Support Arduino ESP32 v3.0 based on ESP-IDF v5.1 platformio/platform-espressif32#1225

There is already an open pull request but PlatformIO is refusing to merge it and claim that Espressif's lack of support is at fault:

• Support Arduino ESP32 alpha/RC v3.0.0 based on ESP-IDF v5.1 platformio/platform-espressif32#1281

  • Track Arduino ESP32 Alpha Release v3.0.0 based on ESP-IDF v5.1 Support Arduino ESP32 v3.0 based on ESP-IDF v5.1 platformio/platform-espressif32#1211

Short term the only workaround for that drama is to fork platform-espressif32 from platformio and apply that patch yourself.

So for now all can do is report non-PlatformIO problems and feature requests related to ESP32-H2/ESP32-C6 as new issues here:

https://github.com/espressif/arduino-esp32/issues/

[dwhitlow]

Is there any downside to switching esphome to use the pioarduino fork of platform-espressif32 by default? Are there any blockers for doing so that I can assist with?

[Hedda]

Is there any downside to switching esphome to use the pioarduino fork of platform-espressif32 by default? Are there any blockers for doing so that I can assist with?

For your personal development probably not but in the main esphome repositoey it could affect other things so need a broader considerations, regardless suggest take that up in the existing separate discussion about that in the main esphome repository instead as that dependency library is only indirectly related here, see:

• pioarduino and Tasmota developers felt forced to fork Platformio's platform-espressif32 ( Espressif ESP32 Arduino Core development platform) in order to add support for Arduino ESP32 v3.0 and later esphome#7334

Since such changes can affect so many other things they should really not be discussed here in this feature request but in the main ESPHome repository:

• https://github.com/esphome/esphome/discussions

[mrene]

I've gotten this to work by cobbling different pieces together (the ot_cli example, and the zephyr component) - this is a proof of concept running on an ESP32C6 if it helps anyone else.

https://github.com/mrene/esphome-openthread-poc

[mrene]

Turns out getting esp32h2 to work was easier than I thought, just needed to switch to pioarduino's fork which has a board definition for it, and fix a few compile errors in esphome.

Example config

[baudneo]

Turns out getting esp32h2 to work was easier than I thought, just needed to switch to pioarduino's fork which has a board definition for it, and fix a few compile errors in esphome.

Example config

How do the sensors and such work via zigbee? Same as before? Just define them and they show up on Hass via esphome? Or are they exposed via zigbee2mqtt or equiv?

[mrene]

This is using Thread, not Zigbee. Thread devices are bridged to your normal network (via a border router), and have an IPv6 address. You can use the HA esphome integration, mqtt, or anything that works over ipv6.

[Hedda]

Originally posted by @P-R-O-C-H-Y in #1397 (comment)

I just want to inform you all that I am now investigating/working on a wrapper for Zigbee to make it simple to use in Arduino. For now we have provided Zigbee libraries + 4 ported IDF examples, which are huge and not that easy to use for someone new to Zigbee.

The wrapper is still in early stage of development, when there are news or some draft, I will keep you updated and link the PR here in a comment :)

FYI, sounds like initial PR for Zigbee API / library wrapper might soon be merged into Espressif's upstream Arduino core for ESP32:

• feat(zigbee): Add Zigbee library espressif/arduino-esp32#10265

Again, that is Espressif's first implementation of Zigbee in Arduino so no guarantees it will even be used by ESPHome developers:

• Implement Zigbee in Arduino espressif/arduino-esp32#10135

[Hedda]

Originally posted by @P-R-O-C-H-Y in #1397 (comment)

I just want to inform you all that I am now investigating/working on a wrapper for Zigbee to make it simple to use in Arduino. For now we have provided Zigbee libraries + 4 ported IDF examples, which are huge and not that easy to use for someone new to Zigbee.
The wrapper is still in early stage of development, when there are news or some draft, I will keep you updated and link the PR here in a comment :)

FYI, sounds like initial PR for Zigbee API / library wrapper might soon be merged into Espressif's upstream Arduino core for ESP32:

• feat(zigbee): Add Zigbee library espressif/arduino-esp32#10265

Again, that is Espressif's first implementation of Zigbee in Arduino so no guarantees it will even be used by ESPHome developers:

• Implement Zigbee in Arduino espressif/arduino-esp32#10135

FYI, looks like P-R-O-C-H-Y's Zigbee API (Zigbee library wrapper) for Arduino on ESP32 (arduino-esp32) is being working on very activly right now and initial (basic) Zigbee library support has been merged into both master and release/v3.1 branches of upstream arduino-esp32, so initial support and a few examples will be included in upcoming 3.0.6 and 3.1.0-rc2 releases of arduino-esp32. See:

• Implement Zigbee in Arduino espressif/arduino-esp32#10135

Note that even though this initial Zigbee API support is merged into upstream arduino-esp32 is still in relatively early development so I would not expect it to be feature complete or cover all use cases needs as of yet, however this new Zigbee API is potentially the beginning of something that could become awesome of it grows and more developers join P-R-O-C-H-Y in the development of it.