[a254613e]

The main reason why HA accounted for so many requests is probably because it was a polling integration, requesting data every 30 seconds from the server, while the official app either had push events when something changes, or it updated state when the app gets opened.

[giancarlostoro]

Why not... just allow HA receive callback events at that point when things change? I feel like this has an easy resolve that doesn't piss off your power user customers, and makes them encourage others to invest in your products, IE power users, and they'll come back because despite being a little extra engineering effort, they were glad you thought of them.

[jacquesm]

Why not simply allow HA to integrate on site rather than to have to go through some crappy service that likely will not last the lifetime of the doors in the first place?

[giancarlostoro]

That's also a good question, one reason I'd be okay with having callbacks is if your software that handles what to do is on a server somewhere else entirely, maybe you own multiple homes and don't want to run several on-premise servers when one could do, I'm also thinking of more than just whatever HA is doing and whatever a power user might do.

[organsnyder]

I bought MyQ's Homekit bridge to allow local integration with Home Assistant. It was a bit of a pain to set up initially, and it's stupid that I have a separate device when the openers themselves support wifi natively, but it's been rock-solid.

[mikestew]

You know that "bit of a pain to set up initially" you mentioned? Yeah, I've had to do that repeatedly because its little pea-brain forgets every few months. It's been anything but rock-solid for me. I just gave up on it.

I initially bought the bridge because I thought a wireless relay spliced into the hardwired door switch would be too much trouble, so I'll spend a little and save some time. Boy, was I wrong.

[rootusrootus]

I had a version of your experience, but it resolved magically. No idea why. I originally set up the integration, and it worked. Then I completely rebuilt HA at one point and had to redo the bridge config, and it just refused. All sorts of errors, it just refused to even see the doors. Frustrated, I chucked the device in my closet and forgot about it for a while.

Then a few months later I decided to try again and be very careful and deliberate, and ... it worked. Just like it was supposed to. Sigh. No idea what incantation I did right, but now it has been working for several years without a hitch.

I did recently buy a ratgdo (well, ordered it at least, it hasn't arrived). That's my backup plan if the Home Bridge decides to go tits up.

[organsnyder]

I've been lucky, I guess. After I got it set up, it's just worked—even across various configuration changes I've made to Home Assistant and my network infrastructure.

[steamer25]

I'm not saying owners should be completely barred from modifying their systems but there are security implications to bypassing their centralized / cloud-based authentication.

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.

[jacquesm]

You've got that backwards. Giving a third party control over your garage door is the 'security implication' you want to avoid.

[steamer25]

It happens all the time, no tech required, any time someone is foreclosed on.

I agree it's wiser to avoid such situations but a lot of people end up delegating this kind of responsibility. If enough of them end up burning their own fingers, that could go badly for a provider. Even if frivolous lawsuits weren't a thing, a spate of ignorant but angry social media posts could be very damaging.

Again, I'm not saying I necessarily have a solution or that hardware owners should have hurdles placed in their way. I'm just pointing out that in some ways the provider may be damned in one way if they do and damned in another way if they don't.

I suppose the IoT sub-sector will end up in similar proportions to other, older tech: Some vendors, analogous to e.g., Red Hat or Linode, will specialize in catering to enthusiasts / power-users and have fairly noncommittal / at-your-own-risk / no-warranty license agreements. However, if the past is any indication, most people will end up doing a lot of business in walled-garden analogs of Apple or Facebook.

[hunter2_]

Deadbolt companies aren't liable for customers leaving their products unlocked, right? Is this so different?

[steamer25]

That makes sense to me but I'm not sure your average judge/juror would see it so simply--especially given that in most cases it'd be a lot easier to tell if/when a deadbolt has been modified.

[twicetwice]

Good suggestion, but where and how does HA receive callbacks? I would guess that almost all HA instances are behind residential LANs and most aren't accessible on the public internet. You could use dynamic DNS and forward ports, but that's flaky, you might run into CGNAT, etc. And anyway, it's best if your HA instance isn't publicly addressable; mine is only accessible over my personal WireGuard VPN and I intend to keep it that way.

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

[tuckerman]

If you pay for the home assistant cloud subscription (built into HA, ~5 USD/mo) they can provision custom callback URLs for you so you don’t have to expose your HA instance. I have this setup for certain integrations such as Samsung Smart Things.

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.

[andrewaylett]

Unfortunately it's not actually that different in effect -- Nabu Casa proxy the encrypted TCP connection, rather than terminating TLS and proxying HTTP, which is great for privacy but not so much for providing an extra layer of security on top of HA itself.

It is also much easier for those without easy access to extra static IP addresses. Given the target audience I think it's probably the right approach.

[tuckerman]

I don't think it's entirely devoid of security improvements---you need to know the webhook address in order to get access to talk to a HA instance which would be a lot more difficult than just port scanning for an open (perhaps unpatched) HA instance on the open internet. I would still prefer it though if things would expose a local API or speak MQTT however.

[ndriscoll]

Open a TCP connection from the instance to the cloud service. I don't know about all consumer routers, but I just checked mine and the default TCP established timeout is 7440 seconds. Idle timeouts are supposed to be at least 2 hours.

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)

[pjsg]

MQTT is the solution for this. Note that the garage door openers talk MQTT to the myq service (over TLS with preshared keys). It should be possible to subscribe to events from your garage door opener(s) and also to send commands to it.

[Eduard]

but MQTT alone doesn't solve the challenge for some Internet server to push messages to a Home Assistance instance running inside a home network / behind a router / behind a firewall / NAT unless a port is opened on the router, or long-polling is used.

[moritonal]

I recently bought a Nuki smart-lock, purely because it offered MQTT support with auto home-assistant discovery. Vote with your wallets and we can have nice things.

https://support.nuki.io/hc/en-us/articles/12947926779409-MQT...

[bluGill]

Because that would require them to build a callback system for the 0.2%. I don't have this, but I'm guessing the app only checks if your garage is open when you open the app. That is if you don't have the app open and someone opens the door you don't get a notification.

[ryukoposting]

Isn't the high road solution here to open your API to enable users to make a less shitty HA integration?

Either way, they'll almost certainly pull the plug on this service sometime before the end of the decade.

[lhamil64]

Or open up a local API so Home Assistant users don't even need to hit their servers in the first place, which is preferable anyway...

[thecapybara]

If I recall correctly, Chamberlin had an optional accessory that added HomeKit support to garage door openers, and that was discontinued last year. Home Assistant is capable of acting as a HomeKit hub, allowing it to control HomeKit compatible devices locally that otherwise would've required a cloud connection.

[ziml77]

I'm so glad HomeKit exists because without it I'm positive the vast majority of "smart" home devices wouldn't support any kind of local connectivity.

[kortilla]

It sucks how many iot devices skip home kit integration for this very reason. :(

[epiecs]

I was just going to comment this. The device is network connected anyhow. So just open up the local api.

[cameldrv]

Haha this is the company that has an undocumented encrypted wire protocol between the wired button and the opener so you have to use their button instead of a normal doorbell switch.

[giancarlostoro]

I would argue that letting HA define a callback URL or some way to receive those events instead of relying on polling would do it. But also, are they caching the responses? I have a weird feeling that the vendor is not caching enough, especially for data that changes insanely infrequently.

[criddell]

That’s definitely the high road solution. The low road solution would have been to start suing HA users under the CFAA. So I guess they took the middle road.

[Angostura]

Possible answers would be for the company to create an official integration, using a change state trigger rather than a polling trigger - or possibly to throttle requests from a particular IP to a certain number per day to incentivise parsimonious usage

[xur17]

Absolutely. It would also be possible for them to create a local API that home assistant can call over the local network. The real problem is that the company just doesn't care.

[greggsy]

HA even claim that it’s used as a test bed for many iot products, so it can often have integrations before any other platform. Kind of makes sense, give many cross platform integrations there are in it.

[lvh]

A third-party hub would have a similar problem, though, right?

[mikeryan]

MyQ has built in integrations for Apple Smart Home and Alexa. I’m assuming in those situations the MyQ app passes state to those services so they don’t have to poll.

[achandlerwhite]

Not for HoneKit unfortunately. They did sell a separate -$100 box that would bridge it officially but have discontinued it.