FAQ
TL;DR: Early ESP32‑C3 BT Proxy for OpenBeken boots on ESP‑IDF v5.5.2 with 4 MB flash; “Proof of concept is working…”. It targets coordinator‑style BLE relaying, but author paused pending real use cases. [Elektroda, DeDaMrAz, post #21846290]
Why it matters: Makers testing BLE gateways on low‑cost ESP32‑C3/RTL8720D need clear build notes, limits, and quick fixes.
Quick Facts
- Stack used on ESP32‑C3: Bluedroid (ESPHome‑compatible baseline). [Elektroda, DeDaMrAz, post #21846587]
- Observed working environment: ESP‑IDF v5.5.2; detected SPI flash 4 MB. [Elektroda, DeDaMrAz, post #21846290]
- Suggested Wi‑Fi/BLE coexistence split tested: 40% Wi‑Fi / 60% BT. [Elektroda, DeDaMrAz, post #21847063]
- RTL8720D minimal build size example: ~1053 KB without Berry (≈1157 KB with). [Elektroda, insmod, post #21847067]
- 2 MB flash targets may be excluded due to BT proxy binary footprint concerns. [Elektroda, DeDaMrAz, post #21846290]
Quick Facts
- Stack used on ESP32‑C3: Bluedroid (ESPHome‑compatible baseline). [Elektroda, DeDaMrAz, post #21846587]
- Observed working environment: ESP‑IDF v5.5.2; detected SPI flash 4 MB. [Elektroda, DeDaMrAz, post #21846290]
- Suggested Wi‑Fi/BLE coexistence split tested: 40% Wi‑Fi / 60% BT. [Elektroda, DeDaMrAz, post #21847063]
- RTL8720D minimal build size example: ~1053 KB without Berry (≈1157 KB with). [Elektroda, insmod, post #21847067]
- 2 MB flash targets may be excluded due to BT proxy binary footprint concerns. [Elektroda, DeDaMrAz, post #21846290]
What is OpenBeken?
OpenBeken is a lightweight open-source firmware for smart devices, focused on Wi‑Fi/IoT control and driver extensibility. The ESP32‑C3 BT Proxy test runs inside an OpenBeken build, identified in boot logs as Project “OpenBeken.” [Elektroda, DeDaMrAz, post #21846290]
Does the ESP32‑C3 BT Proxy proof of concept actually work?
Yes. The author confirmed, “Proof of concept is working…”. It boots on ESP‑IDF v5.5.2 and exchanges API messages, indicating a functional handshake and entity listing. This is an experiment parked until clear use cases appear. [Elektroda, DeDaMrAz, post #21846290]
Which Bluetooth stack is used: NimBLE or Bluedroid?
Bluedroid. The author chose Bluedroid because ESPHome was the base and easiest to integrate for this prototype. “bluedroid as ESPHome was the base and easiest to implement.” [Elektroda, DeDaMrAz, post #21846587]
Where can I get the experimental code?
A work‑in‑progress branch is shared: a BT_proxy branch on the author’s fork. It’s noted as messy but usable for experimentation pending cleanup. [Elektroda, DeDaMrAz, post #21846593]
I miss BLE advertisements once Wi‑Fi connects—how do I fix that?
This symptom was observed. Tuning Wi‑Fi/BLE coexistence and BLE scan timing helped on ESP. Try a 40/60 Wi‑Fi/BT split and adjust scan intervals/windows to recover advertisements. “play around with that ratio.” [Elektroda, DeDaMrAz, post #21847084]
What coexistence ratio worked during tests?
A 40% Wi‑Fi and 60% BT split was reported during ESP tests. This improved advertisement capture under contention. Treat as a starting point and validate in your RF environment. [Elektroda, DeDaMrAz, post #21847063]
How big is the RTL8720D build, and does flash size matter?
A minimal RTL8720D build measured ~1053 KB without Berry, about 1157 KB with it. Devices with only 2 MB flash may struggle once BT components inflate binaries. Leave overhead for OTA and filesystem. [Elektroda, insmod, post #21847067]
Will 2 MB flash devices be supported?
The author warns BT proxy binaries are often large, likely excluding 2 MB targets. Treat this as a constraint until further optimization or feature trimming lands. [Elektroda, DeDaMrAz, post #21846290]
Can I build RTL8720D firmware with parallel make jobs?
Avoid make -j on RTL8720D. Builds fail when parallelized. Use single‑job builds to stabilize toolchain behavior in current snapshots. [Elektroda, insmod, post #21847083]
Is MQTT required, or can I adapt the ESPHome API?
An alternative using the ESPHome API was proposed. This can simplify discovery and state sync versus MQTT, especially for Home Assistant setups. Evaluate API throughput against BLE scan load. [Elektroda, insmod, post #21847083]
How do I try the ESP32‑C3 BT Proxy build? (3 steps)
- Clone the author’s fork and checkout the BT_proxy branch.
- Build for ESP32‑C3 with ESP‑IDF v5.5.2, enabling the BT proxy flag.
- Flash, connect Wi‑Fi, then verify BLE handshake logs over UART.
[Elektroda, DeDaMrAz, post #21846593]
I saw a MAC address issue—what’s the status?
One tester hit a MAC display issue initially and fixed it first. Ensure correct SDK config and init order when enabling BT coexistence. Validate with fresh logs after changes. [Elektroda, insmod, post #21847064]
Is there a Dockerized local build to speed iteration?
Yes. The author recommends the Docker local build from the fork to accelerate compile‑flash cycles. This helps when testing BTProxy and TCPuart combos. [Elektroda, DeDaMrAz, post #21847075]
What’s the project status and roadmap?
Development is paused due to cost‑benefit concerns. The test device will keep collecting stability data. A port to RTL8720D is planned when the dev board is available. [Elektroda, DeDaMrAz, post #21846290]
Will this use case extend to RTL8720D Zigbee gateways?
Yes, the initial goal was restoring BT proxy on a Zigbee gateway with RTL8720D. Work began on ESP32‑C3 first due to availability and prior hurdles. [Elektroda, DeDaMrAz, post #21846587]
Any other tuning tips beyond coexistence?
Yes. Tweak BLE scan timing (interval/window) for better capture under Wi‑Fi load. This improved results in ESPHome contexts during testing. [Elektroda, DeDaMrAz, post #21847088]
