search

esphome / feature-requests

ESPHome Feature Request Tracker
https://esphome.io/
409 stars 26 forks source link

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

Open levihb opened 2 years ago

levihb commented 2 years ago

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.

micfogas commented 8 months ago

As far as I know no one is working on it for ESPHome as of yet, (at least not what I have seen so far). This is only a feature request.

I jumped on the discord a couple weeks ago and started a thread in the #dev channel about it, but I had a medical issue come up that resulted in 2 ER visits, a hospital admission, and 2 surgeries. I'm still recovering from that and my energy isn't very much still, but I want to focus on it again soon. That is, implementing 802.15.4 radio support for ESPHome. I have the Espressif OTBR Gateway/ZigBee board that has an H2 and an S3 on it for the host. Each have their own firmware. I haven't been able to get the host firmware to build with the RCP OTA Firmware option checked, but I didn't spend time with it. I probably have to define the location of the RCP firmware (or put it somewhere specific). The RCP (H2) firmware build example comes with ESP-IDF SDK, while the OTBR S3 build example is part of a separate repo called esp-thread-br. I personally built it using Ethernet instead of wifi but I'll focus on WiFi.

AFAICT, the H2 is specifically their 802.15.4 radio transceiver SoC while SoCs like the C6 have an 802.15.4 radio in the SoC. But for the C6, since the WiFi and 802.15.4 radios share the same processor, they can't share processor time, which means if one is active on any given cycle, the other is not. This translates to meaning that you it's a great integrated SoC for providing 802.11 and 802.15.4 as an option on the same board, but trying to use it as both at the same time will give you poor performance with both. It's possible to do but it'd be like listening to 2 songs at once with 1 radio, having to switch the station back and forth. The longer you spend on one, the more you miss on the other. And you don't know what you don't know.

Anyway I'm going to look at integrating the c6 first probably, because that's what most people would be using. The h2 is simply a co-processor that can be used with a host SoC, but that host has to be supported by ESP-IDF. In fact, the C6 requires ESP-IDF. essentially, the necessary action is to integrate ESP-IDF to ESPHome. The rest comes with it. I'll double check again and if no one has started, I'll set up foundation for a pull request. I can't imagine that the project leads haven't at least started on adding IDF, even if it's behind the scenes.

AllardKatan commented 8 months ago

I jumped on the discord a couple weeks ago and started a thread in the #dev channel about it, but I had a medical issue come up that resulted in 2 ER visits, a hospital admission, and 2 surgeries. I'm still recovering from that and my energy isn't very much still, but I want to focus on it again soon.

Thanks for taking the effort and I wish you a speedy recovery!

This translates to meaning that you it's a great integrated SoC for providing 802.11 and 802.15.4 as an option on the same board, but trying to use it as both at the same time will give you poor performance with both.

I understand that having a device that can communicate with both or translate one to the other might be important for some. For me, I prefer a system where anything with high data rate is on ethernet, and all the small sensors and actuators use Zigbee or (eventually, but not yet) Thread. So there is at least one user out there who is happy with a device that does only 802.15.4

Anyway I'm going to look at integrating the c6 first probably, because that's what most people would be using. The h2 is simply a co-processor that can be used with a host SoC, but that host has to be supported by ESP-IDF. In fact, the C6 requires ESP-IDF. essentially, the necessary action is to integrate ESP-IDF to ESPHome. The rest comes with it. I'll double check again and if no one has started, I'll set up foundation for a pull request. I can't imagine that the project leads haven't at least started on adding IDF, even if it's behind the scenes.

Good luck and thanks again!

TheRed-E commented 8 months ago

So there is at least one user out there who is happy with a device that does only 802.15.4

Also count me in on that! End device support or zigbee router support would greatly benefit the use for mee! Grab myself a ESP32-H2 dev board. So if there is some testing or help requierd, I might jump in to assist!

Tropaion commented 8 months ago

As someone who already made two zigbee devices with the c6, I wonder, with the current state of the sdk (with very few clusters supported), does it really make sense to invest workload to implement it currently? As far as I read about the zigee sdk, espressif doesn't intend to implement all cluster on it's own, only those which are requested one theyr repo. Four/five months ago I requested two clusters I needed for my device, which have finally been implemented about two weeks ago.

Hedda commented 7 months ago

Off-topic, but FYI, a new project by ffenix113 aims to provide similar functionality to ESPHome, but for Zigbee devices, (initially only based on nRF52840 Zigbee radio modules from Nordic Semiconductor, so there is no plan yet for ESP32 support today):

https://github.com/ffenix113/zigbee_home

and

https://ffenix113.github.io/zigbee_home/

Still very early in development but that is good time to get started if want help provide feedback/input that shape the project.

Again, ESP32 is not yet supported, see feature request discussion about Zigbee support on Espressif ESP32-C6 and ESP32-H2:

https://github.com/ffenix113/zigbee_home/discussions/7

Other than following concept of ESPHome it also takes inspiration from PVTO (Zigbee Switch Configurable Firmware) project:

https://ptvo.info

FYI, ffenix113 has upstreamed patches to the Zigbee2MQTT project so it supports devices that can change features dynamically.

PS: ZHA integration might need something similar if want to use custom clusters and attributes, see -> https://github.com/zigpy/zigpy/discussions/1312

tomaszduda23 commented 6 months ago

I've started porting esphome to nRF52840 a few weeks ago https://github.com/esphome/esphome/pull/6075. It can be used with nrf-sdk which has some zigbee examples https://github.com/nrfconnect/sdk-nrf/tree/main/samples/zigbee. I've not looked in zigbee details. Maybe someone would be interested though.

Hedda commented 6 months ago

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

FYI, an Espressif developer has now posted an experimental version of zigpy-espzb available in this repo (but it is not yet on PyPI):

https://github.com/lhespress/zigpy-espzb (also dependent on https://github.com/zigpy/zigpy-cli/pull/45)

Note! That zigpy-espzb project is not meant to allow you to use ESP32-H2/ESP32-C6 as a Zigbee device (i.e. Zigbee End Device or Zigbee Router devices), instead, it will only enable you to use an ESP32-H2/ESP32-C6 flashed with a Zigbee NCP firmware image as a remote Zigbee Coordinator radio adapter (using Serial-over-IP proxy/relay) with a zigpy based Zigbee gateway application (such as Home Assistant's built-in Zigbee Home Automation integration component -> https://www.home-assistant.io/integrations/zha ).

This is related to this zigpy feature request asking to use ESP32-C6/ESP32-H2 as remote Zigbee Coordinator -> https://github.com/zigpy/zigpy/issues/1052

DNA99 commented 6 months ago

how about the esp32 c6? this has zigbee and is it going to be supported by esphome?

Hedda commented 6 months ago

how about the esp32 c6? this has zigbee and is it going to be supported by esphome?

Read or search all the posts in this whole thread for this feature request -> https://github.com/esphome/feature-requests/issues/1397

The original post at the top just says ESP32-H2 because only that model had been released at the time and the original poster has not updated the original post. But later when the ESP32-C6 model was announced it was mentioned loads of times.

Current status is that both are just supported by upstream from ESP-IDF 5.1 but not yet supported libraries for arduino-esp32:

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

ESP32-C6 and ESP32-H2 are supported in upstream Arduino Alpha 3 Release v3.0.0 based on ESP-IDF v5.1 (however not in stable release). But then libraries need to be updated in esphome before the HUGE job of actually implementing Thread and/or Zigbee.

See examples -> https://github.com/espressif/esp-zigbee-sdk/issues/228 and https://github.com/espressif/arduino-esp32/issues/9156

luar123 commented 5 months ago

I have created a simple esphome example of a zigbee sensor: https://github.com/luar123/esphome_zb_sensor

The zigbee part is currently hard-coded and included as a custom component including a task. Changing this to an external component with more configuration possibilities would be the next step.

lboue commented 4 months ago

@Hedda We are still awaiting approval of this PR: Add support for ESP32-H2 and ESP32-C2 #1347 because ESPHome is based on this package.

See this ESP32 Platform for platform_version variable.

Perhaps it's possible to compile ESPHome manually with this PR's patches.

Hedda commented 4 months ago

FYI, upcoming ESP32-H4 and ESP32-C5 MCU SoC models announced with 802.15.4 radio for Thread and/or Zigbee (+ Bluetooth).

image

As I understand, these should in the future eventually all be fully supported by the ESP-IDF framework as well as the ESP-Zigbee-SDK and ESP-Matter-SDK to add more flexibility in choice of model options.

PS: Also announced is the new ESP32-P4 which a very powerful high-performance MCU SoC without any radios at all, so it is designed to act as a general purpose host MCU that in combination with above SoC to make a 2-SoC solution with Ethernet PHY (like for example a Zigbee Gateway).

https://www.cnx-software.com/2022/09/13/esp-hosted-helps-adds-wifi-connectivity-to-legacy-linux-or-mcu-based-products/

https://docs.espressif.com/projects/esp-at/en/latest/esp32/Get_Started/What_is_ESP-AT.html

Hedda commented 3 months ago

I've started porting esphome to nRF52840 a few weeks ago esphome/esphome#6075. It can be used with nrf-sdk which has some zigbee examples https://github.com/nrfconnect/sdk-nrf/tree/main/samples/zigbee. I've not looked in zigbee details. Maybe someone would be interested though.

It looks like tomaszduda23 work on basic support for nRF52840 for ESPHome progressing very nicely and just yesterday he marked his pull request as ready for review and testing by developers (or advanced testers if can help with code reviewing):

FYI, I started an end-user discussion about his nRF52840 development in Home Assistant's community forum to not spam here:

https://community.home-assistant.io/t/fyi-a-developer-has-begun-porting-esphome-to-a-nrf5-platform-for-nrf52840/683997

Note! That is only indirectly related to this because a nRF5 (nRF52 and nRF53) platform could also support Thread and Zigbee.

xttlegendapi commented 3 months ago

Hello everyone! It would be really cool if we can have esphome communication over zigbee with the new esp32 variants like H2 and C6.

xttlegendapi commented 3 months ago

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

Sunsurfer89 commented 3 months ago

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

+50 €

haplm commented 3 months ago

Interesting concept :-). +20€

bo0tzz commented 3 months ago

Bounties are generally a somewhat dangerous concept (see https://ondsel.com/blog/software-bounties-are-a-dumb-idea/ for a great writeup), so I would argue caution here.

That said, if the esphome maintainers are on board with a bounty being set and can coordinate it to prevent duplicate effort, I would like to add €50 as well.

Hedda commented 3 months ago

Bounties are generally a somewhat dangerous concept (see https://ondsel.com/blog/software-bounties-are-a-dumb-idea/ for a great writeup), so I would argue caution here.

I agree that trying to crowdfound open-source bounties in advance is generally a bad idea, better to donate to developers that are already contributing code/projects to the community. Regardless a funding campaign for open-source bounties does not belong here under issues on GitHub as it will just spam everyone until they be forced to close issue ruining for everyone else so it would be much appriciated if you guys wanting to fund such bounty efforts would do so on a different platform, just not here.

Sunsurfer89 commented 3 months ago

I believe that @xttlegendapi had a positive mindset while posting, and juat wanted to emphasize the wish of the community to have Zigbee in ESPhome.

Yeah, maybe a bounty campaign is not the right mean, especially not in an Git issue, as @Hedda said. So yeah, let's stop that bounty topic here.

Nevertheless, if there is a way to incent for those development activities, I appreciate and support any centralized and coordinated campaign if it helps. 'Cause I have the same dream of having my own zigbee devices in future.

micfogas commented 3 months ago

Just want to chime in that I have all of these boards and was working on it, but real life took a priority and I haven't had a chance to get back into it yet. I'll be in court soon as the Plaintiff as well, and self representing, so it's eating a lot of time. If I have time and the urge, I'll get back into it sooner.

I definitely want to, and ESP-IDF seems to provide a good solid framework, but I believe that is the main part before much of anything else can happen. It's a new SDK for the newer devices, and it's a different structure as well.

There's a few ways to approach this but the most logical would be to select either IDF or legacy PlatformIO when creating a project. Due to things having to be done a different way, we'll have to create a middle layer framework (I'm not 100% sure that all the current integrations can be translated equally, which bring us to...) or port each integration.

There's definitely going to be some new features that can be integrated over time, but I think any full IDF implementation for the newer ESP32's will be experimental for quite a while.

If I can remember, I'll get back to tearing through the docs during toilet time instead of doom scrolling X 😂

Here's a page with some information about the structural differences that most people posting here should be able to follow, at least enough to get the idea. PlatformIo: ESP-IDF Structure

Hedda commented 2 months ago

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?

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:

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/

PS: Espressif has still not created a Arduino wrapper library on top of the Zigbee SDK, they are however at least providing libraries:

https://github.com/espressif/esp-zigbee-sdk/issues/228

P-R-O-C-H-Y commented 2 months ago

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 :)

MiguelAngelLV commented 2 months ago

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 :+1:

Hedda commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 https://github.com/tomaszduda23/esphome/pull/2

What does this implement/fix?

zigbee support

Screenshot from 2024-06-05 21-12-08

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 commented 2 months ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 2 weeks ago

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:

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 commented 2 weeks ago

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:

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

Hedda commented 1 week ago

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:

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 https://github.com/espressif/arduino-esp32/discussions/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.

For additional information, please refer to these GitHub links:

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?

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:

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 commented 2 days ago

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 commented 1 day ago

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:

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: