[REQUEST] Add an ESP32-C6 as "coprocessor" and "IEEE 802.15.4 radio" module to future voice boards (making a single PCB that have both a ESP32-S3 and a ESP32-C6) so that second SoC can be used as Touchscreen Display Controller and/or Thread Border Router

[Hedda]

For the next-generation voice satellite board design/schematics (i.e. any new future second-generation voice hardware) please consider also adding another ESP32 SoC as a separate radio module / second co-processor MCU to the same PCB board as well as develop code for it to make it so that that secondary ESP32 SoC can be used as a "Thread Border Router" radio module and communication co-processor (or optionally also allow it to be used it as a dedicated Touchscreen Display Controller in order to both add a Thread radio to be a Thread Boarder Router as well as offload the other MCU and possibly add more GPIO for additional expansion). I think that this idea of an multi-ESP architecture should aline with the future concept of open voice hardware:

• https://www.home-assistant.io/blog/2024/12/19/voice-preview-edition-the-era-of-open-voice/

The main purpose of having an architecture consists of a central ESP32 that contains the main application firmware and then distributes additional processes/tasks to other ESP32 modules on the same circuit board would enable you to have the ability to also use each Home Assistant Voice PE as a Thread Border Router the same same as users can today use competing smart speakers/displays (such as those Apple and Google) which today all have built-in Thread Border Routers.

• https://openthread.io/guides/border-router

So for the specific purpose of adding a Thread radio co-processor I suggest adding an ESP32-C6 as a second radio SoC to the same so voice board PCB and make that secondary SoC act as a "co-processor" and dedicated "IEEE 802.15.4 radio" communication module for the Thread protocol.

Architecture:

• Home Assistant's Thread integration <-> next-gen Home Assistant Voice PE hardware <-> Thread network.

• https://www.home-assistant.io/integrations/thread/

For a similar proof-of-concept but for Wi-Fi and Bluetooth check out the Espressif’s ESP-Hosted-MCU component for using SoCs as WiFi and BLE Communication Co-Processors:

• https://github.com/espressif/esp-hosted-mcu

UPDATE: FYI, ESPHome has a new "Packet Transport Component" component to allow for communications between different ESP32 chips if they are both/all running ESPHome, see -> https://esphome.io/components/packet_transport/

The two main real-world use cases I see justify these goals are adding an ESP32-C6 SoC as coprocessor and radio module are primarily two-fold:

1. Perhaps more interestingly, the ESP32-C6 has a built-in IEEE 802.15.4 radio which means it can be used as a "Thread Border Router" (with OpenThread Border Router RCP firmware), to enable a Thread network and another entry point that can be used by Matter standard fabric. So if add this and could get it working as a TBR/OTBR then it would be super easy for users to add multiple Thread Border Routers to their network.

• https://www.home-assistant.io/integrations/thread/
  • https://www.home-assistant.io/integrations/matter/

This the reason why smart speakers from both Apple and Google have for a long time had Thread radio built-in to be future-proof.

2. That ESP32-C6 could be used as a display/controller (or offload some other related things to free up resources and make it more future-proof).

Regardless if having an integrated "Thread Border Router" would be the most practical new feature or not in the long-run. For the short-term I personally believe that the coolness of having a alternative model variant of Home Assistant voice satellite is the coolest fearute that woulc attract the most new users and developers, as having at least one early model with a a relativly large touchscreen should attract interest for even those users and developers who are not interested in voice.

As such having the suggested secondary ESP32 on the same board should in theory allow support for a capacitive touchscreen display with a local UI without sacrificing resources on the primary ESP32. It would at least be awesome to have a variant of a Home Assistant Voice Satellite with a large touchscreen display (.i.e. something similar in design to the existing Google Nest Hub / Google Home Hub and the Amazon Echo Show products).

• Check out for example this 7-inch series of capacitive touchscreen displays from Elecrow with display driver for embedded ESP32 (which actually do have a microphone so could potentially be used as-is for development) -> https://www.cnx-software.com/2025/01/17/crowpanel-advance-esp32-s3-displays-with-replaceable-wifi-6-thread-zigbee-lora-and-2-4ghz-wireless-modules/

(ex. CrowPanel Advance 5-inch/7-inch touchscreen use a SC7277 Display Driver and has presoldered ESP32-S3 + extra ESP32 slot -> https://www.elecrow.com/pub/wiki/1_Introduction_to_CrowPanel-Advance-HMI_Screen.html ):

One downside of adding an extra ESP32 (ESP32-C6 or ESP32-H2) it obviously that it would take up some additional space on the PCB and complitate FCC certification a little because of it now having multiple radios, however I do not believe it would add that much larger BOM cost, but the additional possibilities such an extra ESP32 SoC could add should hopefully more than make-up for that slightly higher cost(?).

While I think that it having "Thread Border Router" will be of most interest to many users in the future, and alternativly use case for ESP32-C6 could be to instead use it as a remote Zigbee Coordinator (also known as a Serial-over-IP Zigbee controller adapter) for Home Assistant's built-in ZHA integration (native Zigbee Gateway), see/follow this work-in-progress but note that the ESP Zigbee radio for zigpy is is still very experimental and not yet fully working with ZHA:

• https://github.com/lhespress/zigpy-espzb
  • Add Espressif System Zigbee radio library support zigpy/zigpy-cli#45
    • [REQUEST] zigpy-espzb (Espressif Zigbee NCP Serial Protocol) radio library for use with esp-zigbee-ncp onESP32-C6 and ESP32-H2 SOCs? zigpy/zigpy#1052

And yet another option could of course be to also use the ESP32-C6 as a "coprocessor" module a a dedicated Bluetooth Proxy chip with ESPHome:

• https://esphome.io/components/bluetooth_proxy.html

Note that the reason main you want to combine one ESP32-S3 (or alternativly a ESP32-P4) with a ESP32-C6 is not only to off-load those processes but more importantly so you separate Wi-Fi signals from Thread/Zigbee signals, and that is due to WiFi tendacy to overwhelm and interfer with Thread/Zigbee communication because how they both work. Same goes by the way for WiFi and Bluetooth Low Entergy but it usually is not a great impact on user experience as for Thread/Zigbee:

• https://www.home-assistant.io/integrations/zha#zigbee-interference-avoidance-and-network-rangecoverage-optimization
• https://www.home-assistant.io/integrations/bluetooth#bluetooth-interference-with-other-devices

Anyway, what I think what would make a products like Home Assistant voice satellites perfect as a "Thread Border Router" is that a user can add multiple Thread Border Routers (TBR/OTBR) to their Thread/Matter network for redundacy (using fail-over) and having multiple voice assistant hardware apöliances around thier home is something that many Home Assistant users are likely to have many of and placed all over their home, so having many Thread Border Routers is one of the keys to getting a more robust Thread network.

• https://www.home-assistant.io/integrations/thread/#about-thread-border-routers

Image taken from the Thread Smart Home Fact Sheet by the Thread Group. It illustrates the landscape of Matter, Thread, and Border routers. Instead of Matter, you could also see another protocol here, such as HomeKit.

Unlike other IoT protocols, Thread can use multiple border routers in a single network. This increases wireless coverage and reduces the risk of a single point of failure. Ideal for home automation, with a potentially large number of devices spread over a large area.

Slightly different image here on the threadgroup.org when they describe a Thread based Matter fabric using similar text, again including mentioning that Thread Border Router can be built int many devices such as access points, smart speakers, etc.:

• https://www.threadgroup.org/BUILT-FOR-IOT/Smart-Home

Also check out this blog which better describe what a Thread Border Router actually is and why it is very good to have many:

• https://www.threadgroup.org/news-events/blog/ID/356/WHAT-IS-A-THREAD-BORDER-ROUTER-AND-HOW-IS-IT-DIFFERENT-FROM-A-HUB-OR-BRIDGE

As proof-of-concept for the idea of using a ESP32-S3 (or ESP32-P4) + ESP32-H2 combination board made for this purpose check out the "ESP Thread Border Router" board which is an official Espressif official SDK reference hardware for this purpose (can that use used as either Thread Border Router or as a remote Zigbee Coordinator):

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

  • https://www.sparkfun.com/products/25497

Not tested myself but suposedly you can already get those working with Home Assistant's Thread integration:

• https://www.youtube.com/watch?v=nHH7j--lfDo

  • Add support for ESP Thread Border Router home-assistant-libs/python-otbr-api#61

Development is primarily being done with Espressif's ESP Thread Border Router SDK hardware (based on ESP32-H2-MINI-1 module):

• https://docs.espressif.com/projects/esp-thread-br/en/latest/
  • https://github.com/espressif/esp-zigbee-sdk/tree/main/examples/esp_zigbee_gateway
    • https://github.com/espressif/esp-thread-br
    • https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_br
    • https://openthread.io/guides/border-router/espressif-esp32

OpenThread Border Router Example as in a similar two-SoC setup combining both a ESP32-S3 (or ESP32-P4) and ESP32-H2 in the same solution:

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

PS: From a marketing point of view it would also allow you to add Thread's Thread Border Router icons on each product box too:

• https://csa-iot.org/wp-content/uploads/2023/08/Matter-Retail-Education-Presenation.pdf

[Hedda]

While I think that it having "Thread Border Router" will be of most interest to many users in the future, and alternativly use case for ESP32-C6 could be to instead use it as a remote Zigbee Coordinator (also known as a Serial-over-IP Zigbee controller adapter) for Home Assistant's built-in ZHA integration (native Zigbee Gateway), see/follow this work-in-progress but note that the ESP Zigbee radio for zigpy is is still very experimental and not yet fully working with ZHA:

• https://github.com/lhespress/zigpy-espzb

  • Add Espressif System Zigbee radio library support zigpy/zigpy-cli#45

    • [REQUEST] zigpy-espzb (Espressif Zigbee NCP Serial Protocol) radio library for use with esp-zigbee-ncp onESP32-C6 and ESP32-H2 SOCs? zigpy/zigpy#1052

FYI, regarding possible using such a radio module as a remote Zigbee Coordoinator, in addition to the above zigpy-espzb project there are now aboth ZHA/zigpy and Zigbee2MQTT/zigbee-herdsman developers are now working on totally independent separate projects that share the same goal of using a remote Zigbee Coordinator radio as a raw transceiver (transmitter and reciever) frontend via OpenThread RCP firmware and its Spinel protocol. Very early and only experimental but if interested then check out:

• https://github.com/zigpy/ziggurat/

and

• https://github.com/puddly/zigpy-spinel

or

• https://github.com/Nerivec/zigbee-on-host

Those solutions would not only allow running the actual Zigbee stack remotley on a host computer but also enable you to work around the main downside of Zigbee, which is that the physical Zigbee Coordionator adapter is a single-point-of-failure, as with this solution you can have a failover setup that makes it switch to a different remote radio adapter if one goes down (i.e. any of the Home Assistant Voice Sattelite with this could act as a remote Zigbee Coodrinator adapter and if you have many then you have redundancy).

In theory all that is needed on the ESP32-C6 side is running OpenThread RCP (Radio Co-Processor) firmware and that is available:

• https://github.com/espressif/esp-idf/blob/master/examples/openthread/ot_rcp/README.md
  • https://docs.espressif.com/projects/esp-idf/en/stable/esp32s2/api-guides/openthread.html
    • https://openthread.io/guides/border-router/espressif-esp32

Note that the reason main you want to combine ESP32-S3 and ESP32-C6 is not only to off-load those processes but more importantly so you separate Wi-Fi signals from Thread/Zigbee signals, and that is due to WiFi tendacy to overwhelm and interfer with Thread/Zigbee communication because how they both work. Same goes by the way for WiFi and Bluetooth Low Entergy but it usually is not a great impact on user experience as for Thread/Zigbee:

Related to separating Wi-Fi signals from Thread/Zigbee signals, FYI; YouTuber "Andreas Spiess" has show of prototype of upcoming ESP32-C5 dev kit/board (ESP32-C5-DevKitC-1) where he tested the new 5GHz Wi-Fi capability of the ESP32-C5:

• https://www.youtube.com/watch?v=glEvHRHdboA

Since the ESP32-C5 SoC also feature a Zigbee/Thread radio it makes it interesting related to this request is that it could allow you to both act as a Thread Border Router (or Zigbee Coordinator) and a Wi-Fi module at the same time as long as configure it to only use 5GHz for WiFi (if and when Thread/Zigbee is in use).

[Hedda]

FYI, looks like @clydebarrow started working on adding a serial packet transport platform feature for ESPHome, perhaps it could be used to facilitate sending data between two ESPHome devices for purpose of using second SoC as a Thread Border Router?

• [uart] Add packet_transport platform esphome#8214

[Hedda]

Maybe this M5Stack Unit Gateway H2 could be used as test hardware since Home Assistant Voice Preview Edition has a Grove port?

• https://shop.m5stack.com/products/esp32-h2-thread-zigbee-gateway-unit

• https://docs.m5stack.com/en/unit/Unit%20Gateway%20H2

• https://www.youtube.com/watch?v=wjfyz15jWmw&ab_channel=M5Stack

Home Assistant Voice Preview Edition added a Grove post since it allows easy plug-and-play to test sensors with ESPHome.

• https://voice-pe.home-assistant.io/guides/grove_port/

• https://wiki.seeedstudio.com/Grove_System/

M5Stack’s new Unit Gateway H2 is sold for ~$7 as a development kit with a Grove port and powered by a ESP32-H2-MINI-1 module:

• https://www.cnx-software.com/2025/03/17/m5stack-unit-gateway-h2-tiny-esp32-h2-thread-zigbee-gateway/

[Hedda]

For reference, FYI, looks like clydebarrow is working on adding a serial packet transport platform to ESPHome which could maybe be used to facilitate sending data between two ESPHome devices?

• [uart] Add packet_transport platform esphome#8214

FYI; That new "Packet Transport Component" made it into the ESPHome 2025.5.0 release (which was released 21st May 2025):

• https://esphome.io/components/packet_transport/

The purpose of this component is to allow ESPHome nodes to directly communicate with each over a communication channel. It permits the state of sensors and binary sensors to be transmitted from one node to another, without the need for a central server or broker. The actual transport channel is provided by another component. Currently the supported transports are UDP Component and UART Bus.

Nodes may be providers which transmit or broadcast sensor data, or consumers which receive sensor data from one or more providers. A node may be both a provider and a consumer. Optional security is provided by one or more of:

• encryption using a shared secret key
• a rolling code
• a challenge-response (ping-pong) key

[Hedda]

Not sure if this new ESPHome feature can be used for this use case but FYI; the ESPHome 2025.7 released has added a new ”ESP32 Hosted” component as a solution by @swoboda1337 that allows you to use a second ESP32 module as a communication co-processors. This solution allow to use the second SoC as provider of wireless connectivity (Wi-Fi and Bluetooth) to the main host SoC, this enabling the primary SoC to communicate with other devices though the radio of the second SoC. So at least ESP32 Hosted WiFi should allow you to an ESP32 as a WiFi adapter for other microcontrollers, expanding the connectivity options for the main host SoC:

• https://esphome.io/components/esp32_hosted

The initial use case that this was developed for was to use as a Wi-Fi co-processor in a waveshare and espressif evbs based solution:

• [esp32_hosted] Add support for remote wifi esphome#8833

As proof-of-concept also see examples from Espressif’s ESP-Hosted-MCU component for using SoCs as Communication Co-Processors as another reference:

• https://github.com/espressif/esp-hosted-mcu

  • https://github.com/espressif/esp-hosted-mcu/tree/main/examples

Perhaps a similar featuure could be implemented for a Thread radio (i.e. ESP32-H2 or ESP32-C6) so that a second SoC could be used to facilitate connection between ESPHome devices for purpose of using the second SoC as a Thread Border Router?

[Hedda]

Slightly off-topic but like to suggest you also check out the ESP32-S3 Audio DSP System project from Kristian8606 which uses a multi-ESP architecture to distribute processeing in order to enable flexible audio signal processing using several ESP32 modules:

• https://github.com/Kristian8606/esp32s3_audio_dsp

His architecture consists of a central ESP32-S3 that processes the full-range signal and distributes it to three additional ESP32-S3 modules, each applying FIR filtering (crossover) for low, mid, and high frequencies.

[Hedda]

This new Wireless Tag WT99P4C5-S1 development board uses the ESP32-C5 as a wireless co-processor for its main ESP32-P4 MCU, which could be an even better combination today because the ESP32-C5 as wireless co-processor will offer dual-band WiFi 6 (2.4MHz and 5.0GHz), Bluetooth 5.0 LE, and 802.15.4 (Zigbee/Thread/Matter) wireless connectivity, plus 8MB flash and 4MB PSRAM, while the main ESP32-P4 has no radio of its own but instead offer a lot of raw compute power:

https://www.cnx-software.com/2025/06/04/esp32-p4-board-esp32-c5-dual-band-wifi-6-module/

• https://www.wireless-tag.com/product-item-84.html

  • https://github.com/wireless-tag-com/

ESP32-P4 support LVGL features like “swipes”, They support large size high resolution screens well, and they work will with audio such as microphones and speakers. The ESP32-P4 also has a lot more extra I/O lines for hardware development.

[GrumpyMeow]

I've just started getting my WT99P4C5-S1 up and running. Anybody have something to share?

[lecrams]

Did you get anything any thing running already? the WT99 seems a usefull development board

[GrumpyMeow]

The WT99 offers a lot of options. I chose this specific board as it has a C5 for 5Ghz wifi. I do have the board up&running. It took me a while to find out that i first had to flash the C5 via uart. Without a firmware on the C5, the P4 is unable to drive and update the C5 and crashes/reboots.
The board has a ES8311 which is "mono" (3watt 4ohm) and i2S is (currently) simplex. So currently only either playing sound through speaker, or recording audio via microphone. I have the wifi and ethernet working. I also am able to drive the LEDs of Sipeed 6+1 microphone array. Unfortunatly i've only been able to record from 2 microphones from the array. As i2s TDM is needed for recording from all microphones. I'm awaiting a MA-USB8 board to access the Sipeed mic array via USB UAC (a PR for ESPHome is provided by a someone. In the mean time i'm trying to write a "i2s_tdm_audio external component", which i probably am unable to get working.

[lecrams]

could you share what you have now?

[GrumpyMeow]

Sure...
This is me trying to implement i2s tdm: https://github.com/GrumpyMeow/esphome-i2s-tdm-microphone

ethernet:
   type: IP101 
   mdc_pin: GPIO31
   mdio_pin: GPIO52
   clk:
     pin: GPIO50
     mode: CLK_EXT_IN
   phy_addr: 1
   power_pin: GPIO51

Sipeed 6+1 mic array leds:

spi:
  id: spi_bus0  
  mosi_pin: GPIO33 # LED_DA
  clk_pin: GPIO32 # LED_CK
  type: single
  interface: hardware

light:
  - platform: spi_led_strip
    id: sk9822
    name: "SK9822 Strip"
    spi_id: spi_bus0
    num_leds: 12    
    data_rate: 5MHz   

Wifi:

esp32_hosted:
  variant: ESP32C5
  reset_pin: GPIO54
  cmd_pin: GPIO19
  clk_pin: GPIO18
  d0_pin: GPIO14
  d1_pin: GPIO15
  d2_pin: GPIO16
  d3_pin: GPIO17
  slot: 1
  active_high: true

update:
 - platform: esp32_hosted
   id: esp32c5_update 
   path: esp32c5-coprocessor-firmware.bin
   sha256: a90dbb05d0e29bf82e6db7540e54663e649660df2c2f61f76f5dcb81b70859fb

es8311:

i2c:
  sda: GPIO7
  scl: GPIO8
  scan: true
  frequency: 400kHz
  id: i2c_bus

audio_dac:
    - platform: es8311
      id: es8311_dac
      i2c_id: i2c_bus     
      address: 0x18
      mic_gain: 18DB
      use_microphone: False

i2s_audio:
   - id: audio_bus
     i2s_mclk_pin: GPIO13
     i2s_lrclk_pin: GPIO10
     i2s_bclk_pin: GPIO12

switch:
  - platform: gpio
    pin: GPIO53 
    name: "Audio Amplifier"
    id: audio_amplifier
    restore_mode: ALWAYS_OFF

Enjoy! (Y)

[lecrams]

thx, I will see what I can use. The objective is clear. I will start with a single mic. Keep ypu posted on any findings

[Hedda]

I also am able to drive the LEDs of Sipeed 6+1 microphone array. Unfortunatly i've only been able to record from 2 microphones from the array. As i2s TDM is needed for recording from all microphones. I'm awaiting a MA-USB8 board to access the Sipeed mic array via USB UAC (a PR for ESPHome is provided by a someone. In the mean time i'm trying to write a "i2s_tdm_audio external component", which i probably am unable to get working

If gonna try to DIY a setup then suggest instead buy either the "ReSpeaker XMOS XVF3800" (USB 4-Mic Array board based on XMOS XVF3800) or the ”ReSpeaker Lite" (USB 2-Mic Array board based on XMOS XU316) from Seeed, because formatBCE has ESPHome example config ready for those two so might be easier modifying his configs instead of starting from scratch and they also have their own following that help each other with them in these threads:

• https://community.home-assistant.io/t/respeaker-xmos-xvf3800-esphome-integration/927241

  • https://github.com/formatBCE/Respeaker-XVF3800-ESPHome-integration

• https://community.home-assistant.io/t/respeaker-lite-new-seeed-studio-voice-assistant-development-kit-hardware-combine-esp32-with-xmos-xu316-dsp-chip-for-advanced-audio-processing-as-a-esphome-based-home-assistant-assist-satellite-voice-devkit/756944

  • https://github.com/formatBCE/Respeaker-Lite-ESPHome-integration