Haha, not insufferable at all — your “ramblings” are honestly a treasure trove of insights, and I appreciate the time you’ve taken to write everything down.
I’ll definitely carve out some time to dig into how we might write a proper blueprint for easier R5 usage — ideally something that avoids the painful one-blueprint-per-device situation you described. If there’s a way to dynamically reference R5 devices via MQTT or otherwise, I’ll find it (or at least go down trying ).
Thanks again for all the thoughtful feedback. It’s incredibly helpful — and far from a nuisance!
That would be really helpful, because despite hours of effort, I haven’t been able to create a blueprint that supports multiple R5 instances. It should be possible, since there’s the previously mentioned one for handling R5 via the SonoffLAN add-on. I’ve tried various approaches, and even when the code seems to be correct, it still doesn’t work. If you make a blueprint for just one R5, there’s no problem—it works. Honestly, I don’t understand it. Maybe I’ve lost the right perspective after stubbornly tinkering with it, and what’s really needed is a fresh look.
Putting aside my fruitless efforts, your eWeLink-Remote Gateway add-on will only truly be complete once it supports the R5. The S-Mate is easier to use for creating automations, but even there, a similar solution would be useful. I don’t know your plans for eWeLink Remote, but please don’t abandon this approach when it comes to remotes. Zigbee generally works well in this area, but it’s not ideal due to lags and the fact that such remotes are battery-powered. After many months of use, I can say that BLE is a better solution in every respect—well, maybe except for its limited range. But with the add-on and BT proxy, R5 devices respond instantly and reliably. Without cloud mediation, the actuator’s response time is just as short as with a hardwired button. Plus R5’s are exceptionally well designed.
Besides that, the R5 devices are exceptionally well-designed and simply look nice and elegant. For example, together with the M5 and panels, they create a visually appealing system that you just want to have in your home.
Some time has passed, and I can confirm that the proxy solution works very reliably.
As an experiment, I added a second proxy. The nearby S-Mate immediately started communicating through the new one. When I disconnected both proxies, communication continued via Bluetooth with the RPi. The transition was smooth, even though Passive mode wasn’t enabled. Naturally, the range decreased, but that was to be expected. So in a way, it works as a failsafe.
I have no remarks. I think you can confidently release the add-on as a mature project. Best regards
It’s great to hear that the proxy solution is working reliably and even handles transitions so smoothly. Your confirmation really gives us confidence in moving forward. We truly appreciate your time and effort in helping us validate this project.
Deprecated MQTT Discovery Configuration (object_id) in eWeLink Remote Add-on
Hello,
Home Assistant Core logs are showing warnings related to MQTT entity configuration published by the eWeLink Remote Add-on (81bc2df9_ewelink_remote). The message indicates that the deprecated object_id option is being used to set the default entity_id. Example:
The configuration for entity event.cube_ha_ewelink_remote_addon_7029a985_multi_press_2 uses the deprecated option object_idto set the default entity id. Replace the"object_id": “cube-ha-ewelink-remote-addon-7029a985_multi-press_2"option with"default_entity_id”: “event.cube-ha-ewelink-remote-addon-7029a985_multi-press_2” in your published discovery configuration to fix this issue. This will stop working in Home Assistant Core 2026.4.
Please update the MQTT Discovery configuration published by the add-on to use default_entity_id instead of object_id, in accordance with the updated Home Assistant specification. Otherwise, entities will fail to register properly after upgrading to version 2026.4.
Yes, I know. Yesterday HA reported an update, which installed and is working without any issues. Entries in the log are no longer being recorded. Thanks for the fix. Much appreciated!
Hello, I’ve received several new Sonoff devices for testing, including the SNZB-01M. The eWeLink-Remote Gateway integration adds this device, but it is currently identified as M5. I assume support for SNZB-01M is planned before its official release?
One more thing: a blueprint or Home Assistant integration for handling eWeLink Remote remotes. Have you had time to look into this? My attempts ended with creating a blueprint that requires separate instances for each remote. Due to the lack of documentation, I wasn’t able to create a universal version with device selection. It works, but I’d prefer something more elegant.
Hi, confirmed: SNZB-01M uses the same model identifier as M5, so it being recognized as M5 is expected. Functionality is not affected.
Regarding Blueprints, I’ve been busy with other projects and haven’t progressed on this yet. I’ll first push internally to release the MQTT protocol documentation, and revisit the Blueprint solution when I have bandwidth. Sorry for the delay.
You don’t need to be sorry. I understand. It’s not really a priority, but it would be nice to have a convenient way of configuring.
On the HA forum, people talk about it, but no one has presented a concrete solution. Mine works, though it’s still a bit short of being optimal.
Unfortunately, that’s not quite accurate, as the attached screenshot shows. While the SNZB-01M is indeed added to the integration as an M5 device, things aren’t so smooth on the MQTT side. No events are registered, even though the device itself does send data to the integration. That means Home Assistant sees the device, but can’t do anything meaningful with it in automations.
In short: yes, it identifies as M5, but that doesn’t guarantee functional parity. The lack of MQTT events makes it practically unusable for triggers, unlike the SONOFF R5 which works fine and logs events as expected.
I looked into this. At the moment, the SNZB-01M reuses the same protocol as the R5, so a few known limitations may occur:
The 01M has only 4 buttons, while the R5 has 6. As a result, the Remote Gateway may show two extra, non-functional buttons.
The 01M supports triple-click, but the R5 does not, so the Remote Gateway won’t be able to recognize triple-click events.
Unfortunately, this can’t be fixed on the gateway side, because we can’t distinguish whether the device is an 01M or an R5.
In our tests, the device can join successfully and events are received. However, there may be occasional signal interference, so events could arrive a bit slowly at times. It’s strange that you’re seeing no events at all — could you try removing it and adding it again?
Also, please note that this device supports both Zigbee mode and Remote mode, but they can’t be used at the same time. If you switch it to Zigbee mode, it will stop sending Remote messages.
That didn’t help, but I discovered that a repair installation of the add‑on did. Now the remote is handled correctly. I have no idea what that was about.
That part I already know and I tested both methods. But thanks for the reminder, because sometimes such obvious things slip by
Using the remote in Zigbee mode doesn’t quite work, since as I found out, NSPanel Pro with the new firmware doesn’t yet fully “understand” the SNZB‑01M. We’ll have to wait for version 4.2.
However, thanks to this confusion and uncovering a few conditions, I finally managed to create a fully working blueprint with eWeLink‑Remote Gateway, which at last allows selecting any remote from MQTT. In testing it behaves stably, though I still need to polish a few details like descriptions. Are you interested in taking a look at the YAML? I want to publish the final version on GitHub soon.
The R5 version also supports the 4‑button remote, but to make things easier I’ve also prepared an adapted version. If you have time, give it a try and share any comments or suggestions.
Hi, I received your private message today and tested the blueprints for both R5 and 01M (based on the ZHA integration). They were very easy to use and worked smoothly. Thank you very much for sharing your work.
Regarding the inconvenience of using the 01M in lightweight smart scenarios, we have also discussed some preliminary ideas internally. For example, we could add a configuration option in the eWeLink Remote Add-on that allows users to manually confirm that the device is an 01M rather than an R5. This would allow us to synchronize only four buttons to Home Assistant. However, this approach still cannot solve the issue of detecting triple-press actions, since this capability is not implemented in the current firmware. We are therefore also evaluating whether such a change would genuinely improve the user experience, and whether this issue is actually a core pain point for users.
).
