ESP32-C6: concurrent Wi-Fi + Thread / Wi-Fi + Zigbee support roadmap?

[YuYang-ysy]

Hi, I'm evaluating ESP32-C6 for a product that needs to be both a Matter lighting device and a protocol bridge. A few questions:

1.Matter over Wi-Fi + Thread Border Router — any plans to provide an example that runs Matter (Wi-Fi) and OpenThread BR concurrently on C6? Is it supported at the SDK level today?

2.Matter over Wi-Fi + Zigbee Coordinator — is there official guidance for integrating esp-matter-sdk with esp-zigbee-sdk in a single C6 firmware? Any example of a Matter Bridge that bridges Zigbee child devices?

3.Thread + Zigbee DMP on C6's single 802.15.4 radio — is this on the roadmap, or is Espressif recommending against it?

4.Are there any other concurrent protocol combinations (e.g., Matter over Thread + Zigbee Bridge via external radio) that you'd recommend for a combo light controller + bridge product?

[chshu]

There is only one RF path in ESP32-C6, which means Wi-Fi and Thread/Zigbee can't receive simultaneously, it has a significant impact on performance. So we recommend the two SoCs solution for your use case. You can consider the combinations like (depends on your product requirement):

• C5+H2
• C61+H2
• S3+h2 (https://docs.espressif.com/projects/esp-thread-br/en/latest/hardware_platforms.html#wi-fi-based-thread-border-router)

[YuYang-ysy]

Thanks for the clarification on RF contention — that makes sense.
One more question: from the Matter spec side, a single device should be able to act as both a native Lighting endpoint and a Bridge at the same time (aggregating bridged endpoints alongside its own native ones). Does esp-matter-sdk support this pattern? For example, can I esp_matter_create_endpoint a Lighting endpoint and also use esp_matter_dynamic_endpoint_create for bridged BLE/UART child devices in the same firmware?
Is there any example or config that demonstrates mixing native and bridged endpoints on one node? Or are the light example and bridge example architecturally incompatible in the current SDK?

[chshu]

Yes, it works. You can achieve this by creating multiple endpoints, just combine these two into a single example:

https://github.com/espressif/esp-matter/blob/main/examples/bridge_apps/zigbee_bridge/main/app_main.cpp#L144
https://github.com/espressif/esp-matter/blob/main/examples/light/main/app_main.cpp#L199

[YuYang-ysy]

Hi ，support for adding Server models to BLE‑Mesh Bridge to act as a provisionable Node?

Thanks for the confirmation earlier — I’m trying to combine the Bridge example and the Light example so the same firmware can both:

act as a BLE‑Mesh Bridge/Provisioner that discovers and provisions other mesh devices (and bridges them to Matter), and
also expose Server models itself (e.g. Generic OnOff Server or Light Server) so it can be provisioned and controlled by a phone/app via PB‑GATT or accessed via GATT Proxy.
A few questions to confirm best practice:

Would simply adding the Server models to the bridge’s composition (root models/elements) be sufficient, or are there additional precautions to avoid conflicts with the existing Client/Provisioner behavior?
Runtime behavior: should the device avoid enabling provisioner mode on startup if we want mobile apps to provision it (PB‑GATT)? Or is a runtime init/deinit switch the recommended approach to support both roles safely?
Any recommended minimal patch or pattern you’d point me to that demonstrates combining these roles (provisioner + server) in one example? I was looking at these two code locations for guidance:
Bridge snippet: https://github.com/espressif/esp_matter/blob/main/examples/bridge_apps/zigbee_bridge/main/app_main.cpp#L144
Thanks for any guidance or pointers to a small example/PR.