It'd be possible for a knows-enough-to-be-dangerous customer to modify their system in such a way that they unwittingly allow unauthenticated local access. From my point of view, Chamberlain/MyQ should be totally indemnified in such scenarios but I'm not sure how murky the legalities would be in terms of getting judges/juries to accept "caveat emptor".
EDIT: Maybe there's a way to ensure customers have signed an indemnification agreement before unlocking local API access? I guess there'd also need to be a way to ensure/promote a factory reset if/when ownership/rentalship changes.
I'm sure this is a solvable and solved problem, but I do believe it is non-trivial, and potentially a major headache for a company to implement just to support a tiny niche of users. I'd be delighted to find out I'm wrong though!
And, unfortunately, the business case isn't there, since this weakens lock-in effects. I don't endorse this reason—that's why I run my own HA instance and don't buy or use any products that require the cloud or otherwise can't be operated entirely locally (including flashing Valetudo to my robot vacuum!).
It’s not a perfect solution since it costs money but it’s a nice alternative to exposing your HA instance or some other front end proxy to the internet.
If you served the entire US (130 million households) and had a 1 hour keepalive, that's only 36k packets per second, which is nothing.
You could also auto-train the idle timeout by using a pair of TCP connections. One uses a known good value while the other probes upwards until it finds its connections start getting closed (with some optional binary search fanciness), feeding new known good values back to the first.
(Obviously the no-cloud solution is better still)
https://support.nuki.io/hc/en-us/articles/12947926779409-MQT...
Either way, they'll almost certainly pull the plug on this service sometime before the end of the decade.
