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 
@jam3 Hi again! Just wanted to share a technical update regarding Bluetooth Proxy support.
Weāve successfully developed a custom integration that listens to Bluetooth advertisement events within Home Assistantās internal Bluetooth stack (via hass.bluetooth), and forwards these packets to our add-on through a WebSocket API. This effectively overcomes the limitation that prevents add-ons from receiving BLE advertisements when using Bluetooth proxies (e.g., ESPHome).
With the core mechanism now in place, weāre proceeding with end-to-end validation and compatibility testing across common use cases.
If everything goes well, weāre planning to release a beta version in August for early access.
Thanks again for your valuable insights ā your use cases have been instrumental in guiding our direction.
1 Like
Thatās fantastic news! 
Solving the BLE advertisement limitation with a WebSocket-based integration is a clever breakthrough. Itās exciting to see things progressing toward validation and a beta release in August!
Huge kudos to the team. And thanks for turning user feedback into real innovation.
Hey, just wanted to give you a quick update since itās been a while.
Weāre still on track and aiming for the endāofāAugust timeline we mentioned before, and we expect to wrap things up right around that window.
Over the past month weāve been busy with:
-
Compatibility checks ā confirmed the integration works smoothly on Raspberry Pi 4/5 and VirtualBox on Windows.
-
Proxy testing ā validated the experience with both Shelly and ESP32 Bluetooth proxies.
-
Adapter coverage ā made sure the addāon works with all three adapter types (builtāin Bluetooth, USB Bluetooth dongle, and Bluetooth proxy adapter).
At this point, the overall experience and architecture are pretty much validated. Whatās left is just wrapping up some coding details and running through software testing.
Weāre very close now ā and if youād like, we can prepare a dev build for you to try ahead of the beta release. That way, you can check firstāhand whether it fully resolves your issue and share any feedback before we finalize everything.
Thank you!
Great news.
Iād be very happy to test it and perhaps help with the final touches.
@jam3
Thanks so much for your support! We just need to do a bit of prep work on our side, and it should be ready sometime next week. Iāll post an update here once itās ready so you can give it a try.
2 Likes
Hi @jam3 ,
We have prepared a beta environment for you to try out the new Bluetooth Proxy support with the eWeLink-Remote Gateway add-on.
You can follow the steps below to install and test it. If you encounter any issues during setup or use, please feel free to share your feedback with us.
Please note:
-
The eWeLink-Remote Gateway add-on in this beta release is hosted in a personal repository for testing purposes.
-
In the future, this add-on will be merged into the official repository once the feature is stable.
Usage Steps
1. Install the ble_passthrough Custom Integration
-
Make sure HACS is installed.
-
Open HACS ā top-right menu ā Custom repositories.
-
Add the repository URL:
https://github.com/iHost-Open-Source-Project/ble_passthroughSelect Integration as the category.
-
Search for BLE Passthrough in HACS and install it.
-
After installation, add the following to your
configuration.yaml:ble_passthrough: -
Save the file and restart Home Assistant.
2. Install the eWeLink-Remote Gateway add-on
-
Go to Home Assistant ā Settings ā Add-ons ā Add-on Store.
-
Click the top-right ā® menu ā Repositories.
-
Add the repository URL:
https://github.com/H1355054467/ha-test -
Go back to the Add-on Store, search for eWeLink-Remote Gateway, and install it.
-
Once installed, start the add-on and optionally enable Start on boot.
3. Verify Operation
-
Make sure your Bluetooth Proxy device is connected to Home Assistant and receiving BLE advertisements.
-
In Home Assistant Developer Tools ā Events, listen to the
ble_passthrough.adv_receivedevent and confirm that advertisement data is updating. -
Start the eWeLink-Remote Gateway add-on and add/pair your sub-devices.
-
Operate the sub-device button (single-click/double-click/long-press) and confirm that automations are triggered.
Good morning,
Thanks for the information and the opportunity to test. Unfortunately, despite following all the steps from the instructions, itās not working as intended. The eWeLink-Remote Gateway add-on doesnāt detect the proxy.
Additionally, unless you enable Passive scanning for the built-in Bluetooth module in the Raspberry Pi, adding an eWeLink Remote device isnāt possible, and the add-on shuts down after a short while. When Passive scanning is enabled for the internal Bluetooth, pairing is possible ā but not through the proxy.
The Bluetooth visualization shows that the proxy is active and detects nearby Bluetooth devices. Iām attaching the add-on log. Is there anything else you need?
Regards,
Marek
Hi,
Just to double-check a few things to help us troubleshoot:
- Add-on Version
Could you please confirm that youāve reinstalled the eWeLink-Remote Gateway add-on from our beta repository?
Repository: https://github.com/H1355054467/ha-test
Expected Version: 0.2.5
This beta version includes the necessary updates to support forwarding BLE advertisements from Bluetooth Proxies via WebSocket. Itās required for the new setup to function properly.
- Verification Steps
It would also be helpful to know how far you got with the following checks:
Is your Bluetooth Proxy device connected to Home Assistant and actively receiving advertisements?- In Developer Tools ā Events, if you listen for
ble_passthrough.adv_received, do you see BLE advertisement messages appearing? - After starting the add-on, were you able to add/pair eWeLink Remote sub-devices?
Let us know which parts are working and where the process might be getting stuck ā that will help us pinpoint the issue quickly. Thanks again for testing!
Soooā¦ turns out I was running version 0.2.4 and totally missed the beta repo address 
. Blame it on the error message chaos. I grabbed the old link like a panicked squirrel hoarding last seasonās acorns.
Big sorry for the confusion! Switched to 0.2.5 and boom
everything works like a dream. Lesson learned: always double-check before hitting 
.
1 Like
Great ā sounds like everything is working as expected now, thatās fantastic to hear!
Weāre also looking forward to your feedback after some extended use. In particular, weāre interested to know whether this new solution improves the whole-home coverage of eWeLink Remote devices in Home Assistant ā especially when using Bluetooth Proxies over TCP.
Thanks again for testing and sharing your experience!
Hi,
Here are my first impressions. I have to admit, for a beta version, the whole setup runs very stably. I do have a few comments, but theyāre mostly unrelated to the actual functioning of the add-on via BLE proxy and MQTT. Iāve been comparing it with the eWeLink Remote support on the DongleM, which Iāve been testing with wild enthusiasm for the past few weeks.
One thing is certain: the BLE proxy solution using an ESP32 undeniably provides better range than the DongleM. I moved the ESP32 around various spots in my apartment, and except for one location, the performance of any R5 device was noticeably more reliable and free of connection drops. Despite the DongleMās rod antennas, which offer considerable gain, it simply canāt compete in this regard with a cheap ESP32 development board using a printed antenna.
This isnāt meant as a criticism of the DongleM ā just an observation. I had hoped the DongleM would be the stronger contender in this area, but since youāve managed to add BLE proxy supportā¦ well done. As a side note, maybe this could be an idea for a future product ā a BT/BLE proxy/mesh by Sonoff?
And now, a portion of the promised non-hardware observations. To improve the integration of the R5 with Home Assistant, it would be beneficial to standardize the format of MQTT payloads (e.g. {ābuttonā: 1, āactionā: āsingleā}), provide complete documentation of topics and events, and consider native integration of the eWeLink-Remote Gateway with Home Assistant. Additionally, sample blueprints and an integration guide would greatly help users in building automations.
Iāve spent a lot of time trying to create a working blueprint to avoid manually configuring 18 separate actions and getting lost in the intricacies of automation logic and YAML scripting. I eventually got it working ā but not entirely ā because due to inconsistencies and limitations in MQTT and HA blueprints, not everything is possible and/or within my skill set.
Time for more details. The current issues with R5 support via MQTT stem from the fact that the R5 does not communicate directly over MQTT ā it requires the intermediary eWeLink-Remote Gateway add-on.
The format of MQTT messages is ambiguous and difficult to parse in automations.
Thereās no official documentation for MQTT topics or payload structure.
The Gateway isnāt natively integrated with Home Assistant, as it functions as an add-on without full compatibility.
Users are left to manually analyze topics and payloads, which complicates the creation of blueprints and automations.
What could be improved?
Technically:
- Standardize the MQTT payload format ā for example, { ābuttonā: 1, āactionā: āsingleā } instead of descriptive strings like āSingle pressā.
- Provide complete MQTT documentation ā including topic structure, data format, and sample events.
- Add the ability to configure MQTT topic prefixes ā allowing users to better filter and organize events.
- Emit events as native Home Assistant event types ā rather than relying solely on MQTT, which would simplify automation logic.
- Integrate the Gateway as a native HA component ā with automatic detection of R5 devices and their events.
In terms of documentation:
- Provide sample blueprints and automations for R5 ā ready-to-use scenarios with clear descriptions and requirements.
- Include a diagram of the integration flow: R5 ā Gateway ā MQTT ā Home Assistant ā to illustrate data paths and configuration.
- Create a debugging guide ā explaining how to verify R5 functionality, which logs to check, and how to resolve common issues.
When comparing the data emitted by eWeLink Remote via DongleM with that from the add-on, the DongleM dataset is better structured and more useful, both for automation and integration with Home Assistant. It provides richer device metadata, aligns more closely with HAās interface, and makes scalable solutions easier to build.
If I had to choose a communication model for blueprints or integrations, the DongleM approach is clearly the stronger starting point. I suggest joining forces or exchanging insights with the Dongle team to develop a unified approach.
I trust these observations and suggestions will be helpful and not just a list of complaints. In any case, thank you for inviting me to test - itās a great reason to engage the brain on hot summer days, and itās been a bit of an adventure in itself.
Best regards,
jam3
Thank you so much for the thorough feedback and thoughtful suggestions ā itās incredibly valuable for us, especially at this stage of the project. Weāre really glad to hear that the setup has been stable for you and that the BLE proxy approach is proving to be effective in your environment.
Regarding your suggestions:
-
Documentation improvements (MQTT topic structure, debugging guide, etc.) ā totally agree. We plan to include those once the official version is released.
-
Configurable MQTT topic prefix ā thatās an interesting idea. Weāll evaluate it technically, and if feasible, weād love to include it in a future release.
-
Native HA integration ā as weāve mentioned earlier, our team doesnāt currently have deep experience with Python, so thatās something we likely wonāt be able to tackle in the short term. That said, as we continue working more closely with the HA ecosystem, this direction definitely makes sense.
-
Blueprints ā to be honest, I havenāt used this feature much myself
. Youāve brought it up a few times now, and Iāll definitely take some time to look into it more closely. If we can build something useful out of it, that could help a lot of users.
Thanks again for your insights and time testing this ā it means a lot to us.
Thanks for braving the epic saga of my ramblings. I know it was a lot, and I half expected you to fall into a boredom-induced coma. But hey, you replied, so I guess it wasnāt that bad after all!
Indeed, you did mention the limited capabilities. And of course, I forgot all about that, getting carried away with ideas. If youāre planning a new 64-bit iHost with HA installation support and donāt intend to abandon eWeLink Remote, such a solution will be necessary either way. Iād love to see that happen, but thatās a whole separate matter 
Using a blueprint as a template to handle R5 support seems like the most sensible approach. With 6 buttons and 3 actions each, building automations manually is a painfully tedious task. Since I can access R5 via MQTT, it makes sense to approach it the same way as when itās controlled through the Sonoff LAN add-on. That brings us to the documentation and MQTT topic structure. I spent several hours trying to figure it out through trial and error and by listening in. Attached is the result of those efforts - unfortunately, not what I had hoped for.
I couldnāt create a blueprint that dynamically lists available R5 devices. Thatās partly due to limitations in HAās blueprint handling, and partly due to the lack of documentation. My blueprint requires hardcoding the device ID, meaning you need one blueprint per R5 unit. Any attempt to implement a selector failed consistently. Eventually, I gave up. Maybe youāll be able to improve or build something better. Ideally, the eWeLink-Remote Gateway add-on would systematize and generate entities the way Sonoff LAN does.
I dearly hope that my ramblings are at least marginally useful and that I havenāt become yet another delightfully insufferable nuisance clogging up your digital existence
Best regards,
Marek
(attachments)
sonoff_r5_mqtt.7z (874 Bytes)