Please, do think about it 
Hereās more about it - a hint for you, maybe, Thanks for considering this option.
Hi again, and thanks once more for your insightful feedback.
Weāve been evaluating the BLE Proxy setup in more detail. According to the official Home Assistant documentation (Bluetooth Remote Adapters), only ESPHome and Shelly proxies are currently supported.
After some internal testing, we found that these remote adapters work by establishing a TCP connection via their respective integrations (e.g., esphome, shelly). When the adapter receives a BLE advertisement, it sends the data over TCP to the integration, which then forwards it to Home Assistant Core using an internal event bus mechanism.
However, this architecture means that add-ons do not have access to the BLE advertisements forwarded by these proxies, since the data is handled entirely within the HA Core process and never reaches the hostās Bluetooth stack or shared interfaces.
Given that, weāre curious: do you happen to know of any method or workaround that would allow an add-on to access BLE advertisement data forwarded by a proxy, either through ESPHome or some other channel?
If youāve come across a related project, workaround, or even an idea ā weād love to hear more. This is definitely something weāre interested in solving.
Hello,
Not exactly. With the use of something like ESPHome Bluetooth proxies, you can extend your Bluetooth network to cover your entire home. It is explained in this article: Getting picky about Bluetooth. From my experience, it works. I was able to connect a Bluetooth-capable Xiaomi E-Ink clock (LYWSD02).
You are right. If youāre trying to use an add-on that expects direct BLE access, it wonāt see the forwarded advertisements unless itās been specifically designed to integrate with HAās internal BLE stack. I did some research and found that there are a few clever workarounds and community-driven projects that help bridge the gap between BLE advertisements from ESPHome Bluetooth proxies and Home Assistant add-ons that canāt access them directly:
- Bermuda Integration This is a standout custom integration designed specifically for this limitation. Bermuda captures BLE advertisements from ESPHome or Shelly proxies and enables:
- Room-level presence detection
- Distance estimation
- Triangulation experiments Itās available via HACS and actively developed. You can find more on the Home Assistant Community thread.
- Dedicated MQTT BLE Gateways Instead of relying on HAās internal BLE stack, you can run ESPHome nodes that decode BLE advertisements and publish them via MQTT. This way, any add-on (like
ble_monitor) can subscribe to the data. Downsides: more YAML, more complexity. - Multiple ESPHome Devices with Scoped Roles Some users create dedicated ESPHome nodes for specific BLE devices or integrations. This avoids conflicts and allows more granular control over what data is forwarded and how itās processed.
- Custom BLE Client Components If youāre comfortable with ESPHome YAML, you can use the
ble_clientcomponent to actively connect to BLE devices and forward specific data via MQTT or HA API. This bypasses the passive advertisement limitation entirely. - Use HA Core Instead of Add-ons If possible, move your logic from an add-on to a custom integration that runs inside HA Core. That way, it can access the internal BLE stack and benefit from the proxy system.
All the ideas Iāve found are interesting, although they exceed my programming capabilities. However, I hope they might give you some inspiration. In my opinion, ideas 4 and 5 are promising.
1 Like
Thanks for getting back ā your thoughts have been really helpful and closely align with our own direction.
We agree that Option 4 (Custom BLE Client Components) and Option 5 (Use HA Core Instead of Add-ons) are currently the most promising paths to improve compatibility with Bluetooth proxies.
4. Custom BLE Client Components
Weāve tried building a custom ESPHome firmware that uses ble_client to actively connect to devices and forward their data over MQTT. This worked for our specific use case, but it only solves the issue for ESPHome-based proxies, and still requires device-specific configuration.
Since we aim to support a broader range of Bluetooth proxy types (e.g., Shelly), weāre more interested in aligning with Home Assistantās Bluetooth integrationās internal event flow rather than relying on proxy-specific MQTT workarounds.
5. Use HA Core Instead of Add-ons
We completely agree this is the most robust long-term solution. Building a custom integration inside HA Core would give us native access to the internal Bluetooth stack and seamless proxy support.
However, our current development team is focused on add-on (container-based) workflows and doesnāt yet include Python developers ā so for now, this path is out of reach for us technically. Still, weāre keeping it on our roadmap.
As a side note ā you mentioned that your remotes only worked reliably at about 1.5 meters on a Raspberry Pi.
In our iHost tests, the eWeLink Remote add-on performs stably within 10ā15 meters for BLE broadcast. Beyond 15 meters, packet loss does increase noticeably.
Weāll try to reproduce your scenario on Raspberry Pi 4 and 5 to see if thereās any hardware-specific signal degradation or interference.
Weāll continue tracking the evolution of Bluetooth proxy support in Home Assistant, and weāre always looking for more general-purpose solutions. Thanks again for the great discussion!
No, no. You misunderstood me
I have 5 eWeLink Remote devices in my place. One of them is about 1.5 meters from the Raspberry Pi. Only that one works properly and reliably. The others are farther away. For example, two are in the kitchen, about 10 meters away. And itās not looking great thereāthe performance is unstable. Thereās a thick wall and plenty of objects in the way that could seriously interfere with BLE transmission. On top of that, my Raspberry Pi is in a metal Argon case with passive cooling, which also limits signal strength. The two R5s in the kitchen ātalkā to the NSPanel and M5, which are only about 2ā3 meters away. Also, the radio space in my location is incredibly congested. By more that a 100 neighbouring networks. Myself, Iām running an extensive Wi-Fi mesh, Zigbee, DECT phones, and several BLE devices. Thatās what the setup looks like.
Thatās why I had high hopes for a proxy. If you plan to continue developing Home Assistant on iHost and add support for eWeLink Remote to the ZBBridge-U and the new Dongle (which I have the pleasure of testing), youāre going to have to address the range issue and open up to other platforms one way or another. I donāt think solving this through Matter would be the right approach.
At one point, I was worried Iād have big problems with the Xiaomi BLE thermometer. But in the end, it went smoothly. Thatās great, because the model with the e-ink screen canāt be converted to Zigbee. On a side note, I was hoping Sonoff would offer something similarāa weather station with e-ink display and the ability to show readings from external sensors. As it stands, no manufacturer offers anything like that. Well, maybe partially Aqara with the W100 model.
Thanks for your time and interest. Letās hope that somehow this can be worked out, right?
Thank you for providing such a detailed explanation. I fully understand the complexity of your home environment and how it presents real challenges for using the eWeLink Remote solution reliably. Iāve shared your feedback with our internal team to help guide future product design and technical planning.
As for the BLE range, the earlier test results I mentioned (where eWeLink Remote devices performed reliably within 10ā15 meters) were not obtained in a clean lab setting. Instead, they were measured in our office environment, which is quite saturated with wireless activity ā including a large number of BLE, Zigbee, and Wi-Fi devices. Of course, your results may vary depending on wall materials and the level of radio interference, so this data is just for reference.
Weāll continue to explore more robust technical solutions to better support users like yourself ā especially in dense and complex radio environments. Your insights have been truly valuable in guiding this ongoing work.
Iād be lying if I said I had any complaints about the range of eWeLink Remote when paired with something like the M5. It works well; very well, in fact. The tricky part is getting it to work smoothly with the Raspberry Pi. Thereās really no other way around it, since itās quite tricky to connect an external one and get Home Assistant to cooperate properly. Overall, the built-in Bluetooth module on the RPi isnāt impressive. You know that as well, I recon. Thatās why I tried to bypass it using a proxy.
And really, my goal was to move away from the cloud and the SonoffLAN add-on being in the middle. I only succeeded partially 