A major advancement would be finding a way for eWeLink Remote devices to communicate with Home Assistant via BLE, along with a corresponding integration. There is an ongoing discussion on the HA forum, and many users have expressed interest. So far, the integration has managed to unofficially support S-Mate, but the R5 remains an unresolved challenge due to its number of buttons and the configurability of each one. Currently, SonoffLAN integration only works via the cloud, which is far from ideal.
If eWeLink is truly committed to the HA project on iHost, solving this issue as soon as possible would be in everyoneâs best interest.
@MichaelLearnsToCode @KwayLi99 What do you think?
BTW: Are there any chances to enrich ZBBrige-U with eWeLink Remote hub so itâs possible to expose R5 or S-Mate it as a Matter device, no cloud involved?
Great idea! Thank you very much for the suggestion.
We do have received your feedback (and other usersâ ) on eWeLink Remote devices like S-Mate, S-Mate 2 and R5. We are developing an eWeLink Remote add-on which will import these devices into Home Assistant through MQTT, and of course, these devices can be bridged to Matter through Matter Bridge Add-on. The eWeLink Remote add-on is expected to be released next week.
Note 1: eWeLink Remote add-on can be used on all Home Assistant OS, not just HA over iHost.
Note 2: we are not developing integration simply because my team doesnât have Python developers right now. We do know integration is preferable in many cases. We will add Python developers if we succeed on HA over iHost project.
Regarding adding eWeLink Remote support on ZBBridge-U, I have just talked to our product manager who is in charge of ZBBridge-U, she is also excited about this idea. She will add this feature to ZBBridge-Uâs roadmap later.
Note 3: I am focusing on iHost Open Source Project, so I and my team will do our best to solve related issues.
May I ask one question: why do you use eWeLink Remote devices like S-Mate 2, R5, instead of SONOFFâs corresonding Zigbee devices, like ZBMINI-L2, ZBM5.
I like using the R5 because it is one of the few key controls that has a nice design, good response and works correctly. If Sonoff releases a Zigbee R5 it would be perfect.
I liked knowing that you can use the add-on even if you run HA through another means. Thatâs very interesting.
It would be nice if part of this project was to be able to add converters for ZigBee devices to cubeOS. I really like using CubeOS, one of the few complaints I have about it is that I canât create my own ZigBee converters like Z2M.
Hereâs an example of what Iâm talking about.
OMG! Itâs thrilling. Iâve been waiting for this since I bought my first S-Mate almost two years ago.
Itâs a shame. I hope itâs not that hard to find some skillful developers in CN unless itâs money related problem.
Give the lady my best regards 
Because I like the design, flexibility and idea that stands behind it. Especially R5 is sexy in this regard. The cell life is really long. I donât really know why because on one hand I love it and on the other I hate it
eWeLink CUBE OS is using zigbee-herdsman and zigbee-herdsman-converters under the hood, so ideally CUBE OS could have the same capabilities like Zigbee2MQTT. In reality, CUBE OS updates less frequently than Zigbee2MQTT, so its Zigbee function is slightly behind that of Zigbee2MQTT.
Today, my eagerly awaited ZBBridge-U is set to arrive. Time to put its capabilities to the test, given its hardware affinity with iHost, it seems to have some serious potential. My main interest? Bridging Zigbee devices to Home Assistant. Which brings me to a question (and a cheeky suggestion): could the ZBBridge-Uâs skills be expanded to support the eWeLink Remote hub? If iHost can pull it off, surely its tech-savvy relative can too.
Iâve also got a few more ideas and questions about the ZBBridge-U. If the product manager is interested, Iâd love to exchange some messages with her. Thereâs a chance that my overthinking will turn out to be useful.
The R5 device is a multi-key scene remote control that replaces several SNZB-01P devices.
It has a nice look.
Maybe someday we will see that Sonoff will build a new version of the R5 matter thrend.
I use ZBM5-3C-120, but it is a regular switch. ZBM5 does not support double press and long press. Therefore ZBM5 has limited capabilities as a scene remote.
And it must be connected to a 100-240V power supply
Good idea. Theoretically, eWeLink Remote devices can be converted to Thread since they operate via BLE, which is undoubtedly an advantage. Technically, it may be difficult because R5s do not support OTA. The only problem is local communication with the eWeLink Remote hub, as cloud mediation is required (e.g., in the NSPanel Pro or M5 â SonoffLAN â Home Assistant setup). In LAN-only mode, the M5 works, but the fun ends with the R5 connected to it 
I donât think thatâs an issue for most users. After all, itâs not about chasing the latest functionality. As long as it works reliably and efficiently, thatâs what matters. Newer doesnât necessarily mean better, donât you agree?
Iâve also got a few more ideas and questions about the ZBBridge-U. If the product manager is interested, Iâd love to exchange some messages with her. Thereâs a chance that my overthinking will turn out to be useful.
@momoko is our product manager in charge of ZBBridge-U, she would love to hear your ideas.
Thanks.
I would say that both are used frequently. Cubes comes out with an update almost every month. I would say that the difference is only in the question of options for more advanced users. As I said, if there was a place where the advanced user could put their converters, it would be super interesting. And I would say that it would be very well received.
Got it. I will inform our product manager who is in charge of eWeLink CUBE OS.
We have released eWeLink-Remote Gateway add-on v0.2.0. This time, eWeLink-Remote Gateway will not just working on HA over iHost, but also on other Home Assistant OS running on ARM64 and AMD64 devices.
Here is release note:
- Add-on adds support for x64 architecture
- Optimizes the default name display of the eWeLink-Remote sub-device entity
- After the eWeLink-Remote sub-device entity name is changed, the entity name associated in the automation will change accordingly (after the entity name is changed, the automation can run normally but the UI display will change to Unknown trigger. After re-saving, the UI display can return to normal)
Hello. Itâs good itâs a work in progress. Let me tell you about my experiences with it. With the add-on installed on Home Assistant running on a Raspberry Pi, only one of the R5 remotes, positioned about 1.5 meters from the Pi, worked reliably. The add-on performs well, but only when the R5 is close enough to maintain a strong signal. The remaining three remotes were consistently erratic, making them practically unusable. Eventually, I gave up trying.
After doing some research, it became clear that achieving stable performance on an RPI in this context is no small feat. The issue isnât unique to your add-on. There are numerous forum threads highlighting similar struggles. I decided to try using a BLE proxy instead.
The catch: the eWeLink-Remote add-on requires Bluetooth Passive Scanning to be enabled, which isnât an option when using a proxy. While the ESP32 board defaults to passive mode when set up as a Bluetooth proxy, the add-on doesnât recognize it. Therefore here is my plea: Iâd recommend considering a modification to the add-onâs code to accept the proxyâs default passive mode as valid. For what itâs worth, Iâve successfully connected other passive-scanning-dependent devices to Home Assistant via the proxy without any issues.
@MichaelLearnsToCode Any comments?
The catch: the eWeLink-Remote add-on requires Bluetooth Passive Scanning to be enabled, which isnât an option when using a proxy.
Oh, we never thought about the BLE proxy scenario.
Iâd recommend considering a modification to the add-onâs code to accept the proxyâs default passive mode as valid.
Great suggestion. We will work on it.