Looks like the MyQ triggering device uses MQTT-Secure to do push-notifications and checks. Pretty standard stuff. It’s basically an TLS-encrypted micro sized data packet on a long running connection (which is odd that’s not what their app is using too). The actual up/down status seems to be a state stored on the device itself, and it does a push notification to check its state for reporting.
So in theory, if 3,000 of us are hammering them at around 200 bytes round trip for an open/close call (largest of their request/response sizes) all at the exact same moment, we could maybe cause them to consume ~585 KB of bandwidth. That doesn’t count the REST call up front, but yeah…let’s just say they should have no qualms with what we’re doing from an engineering aspect. This is really just legal junk.
In general there are a few approaches to hacking it to run locally, but it involves more time consumption than I’m willing to put in. It’s much easier to just create a basic REST app out on a virtual server, and have it relay REST calls out to MyQ’s REST services via some quickly spun up TOR proxies. It could also handle exponential backoff if it starts getting overwhelmed with requests from a rogue smartapp gone crazy. A REST service like that should only take a day to code up.
So if it does stop working, I’m pretty confident I’ll be doing something they won’t like and share it with you all.