There is no fool proof solution to this. Except maybe make your own I guess. It’s a garage door opener. An esp32 controlling a relay wired to your existing garage door remote probably won’t look as nice but I bet it ends up being more secure
Can’t comment on quality, haven’t got around to installing yet
I have a lot of thoughts about this.
Supporting things like this is a mixed bag IMO.
This group (especially Home Assistant) are very technical, hands on, and engaged.
I'm a one man team (soon to be two). Between the "big guys" Alexa, Google, SmartThings, HomeKit, Paying Customers (RMR) it's hard to dedicate time to support what in my world are enthusiast projects outside of simply providing the API developer portal.
On the other side, it's really fun to work with these groups. I just usually run out of time.
The dark side of these integrations is they can be really badly implemented, and possibly misused. I've had to make pull requests to more than one "scraped" API integration because it was sending tons of bad traffic and/or creating unintended results for end-users.
It is mostly a manpower problem to police, and in extreme cases like a garage door being left open/not closing becomes a liability (no matter what your API agreement says).
That being said, our public API has been a net good. We've promoted some real quality partnerships off organic visitors to the website (or my linkedin).
But that isn't really their reason. They don't allow IFTT to open the door. Alexa and Google Assistant support is extremely limited.
They've focused on partnerships that directly produce revenue. It is purely a cash grab.
Why not allow people to securely talk to the IOT device right on the local network? I think that then really puts a bright line on where the liability lays.
40 bucks, HA, and about half an hour each (mostly fiddling with the ESP/shield pcb wiring inside the light cover of the opener from the awkward overhead-on-a-ladder position) for me to no-cloud smartify two chamberlain MyQ openers. Special sauce is that the device can MITM the "Security2.0+" signal and emulate the discrete functions of the wired wall remote, not just act as a dry contact relay on the motor.
Result is that separate entities are created not just for the door open(ing)-clos(ing) states, but also for the obstruction sensor and a separate switch to turn the opener's light on or off remotely, all exposed (as MQTT topics) in HA.
Sadly I need MyQ to integrate with my Model 3 though. So I'll probably keep it and get ratgdo too (or something similar since my openers are older than Security 2.0) simply so I can close the door if it's left open.
My very first experience with myQ was figuring out that their IP blocklist provider, brightcloud, blocks anything with the word "proxy" - including the default "it works" page for Nginx Proxy Manager [1]. And they have no way of overriding this to actually provide service if someone turns out to be a legitimate customer.
[1]: https://github.com/NginxProxyManager/nginx-proxy-manager/dis...
