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.
).
