Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Home Assistant blocked from integrating with Garage Door opener API

home-assistant.io

Post reply on HN
Print view View original

221–230 of 655 posts

Re: Home Assistant blocked from integrating with Garage Door opener API

#221

Post by erinnh »

rft wrote: post #77
Moldoteck wrote: post #39

FYI if you want smart things that are not yet limited by this bs decisions, afaik IKEA products are pretty neat

Yepp, I have some IKEA buttons and they are just Zigbee devices. They also sell lamps etc., mostly Zigbee based from what I remember. For the Germans (maybe other countries as well): The Lidl smart home things are nearly all Zigbee based. So far no problems with them and they are, IMO, reasonably priced. I somehow trust Lidl more to not burn my house down than random Amazon sellers. They also sell a Zigbee gateway th…

I moved away from the Lidl Zigbee stuff.

It was just too low quality. Motion sensors would activate later and/or less than other vendors etc. Stuff like that.

Ikea is great, Aqara and Sonoff works well as well. They arent much more expensive (if at all) than the Lidl stuff either.

Re: Home Assistant blocked from integrating with Garage Door opener API

#223

Post by throwanem »

achandlerwhite wrote: post #187
throwanem wrote: post #173

Wait. People bought and installed garage doors that need to talk to the Internet to work? People on here did this?

They can still work the old fashioned way. But not the fancy stuff.

But they're just actuated by radio signaling with some standard protocols, right? I mean, I don't have a garage and in this city probably never will, but my car still came from the factory garage-door controls built into the rear-view mirror. I assume it would take a bit of configuration to work with any given receiver, but I also infer it would work with most, otherwise they wouldn't have built it that way.

Is it hard to find an "IR blaster" equivalent for this kind of signaling? I'm just bewildered to understand why someone with the focus on self-hosted infrastructure that Home Assistant implies can still end up in a position where a third-party API restriction can pose a problem in controlling a locally installed device.

Re: Home Assistant blocked from integrating with Garage Door opener API

#224

Post by dthul »

colinmorelli wrote: post #168
epiecs wrote: post #158

Earlier quoted context omitted.

They can just pay for home assistant cloud?

1) Home Assistant is not an officially sanctioned option by the devices and will run into technical issues regardless whether it's cloud hosted or not (as seen by the very post we're all commenting on). 2) Even if the above were not true, at that point you're back to an internet enabled smart home device system, and now we're simply picking which vendor to trust over the other. But in both cases, the option for the v…

I suppose the vendor could sell a home server device, which runs some kind of Tailscale-like technology to make it available from the internet, and the app talks to that locally hosted server.

Re: Home Assistant blocked from integrating with Garage Door opener API

#225

Post by steamer25 »

jacquesm wrote: post #206
giancarlostoro wrote: post #182

Earlier quoted context omitted.

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.

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?

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.

Re: Home Assistant blocked from integrating with Garage Door opener API

#226

Post by TeMPOraL »

toyg wrote: post #74
dspillett wrote: post #65

Earlier quoted context omitted.

> the MyQ app used to open garage doors is full of advertisements. This will most likely be a significant factor in though, though good luck getting them to admit it. HA users will mostly be bypassing the app and therefore not providing revenue via ad impressions.

The fact that a garage door accessory company relies on showing ads is a triumph for MBAs programs and a tragedy for the human race.

The stuff I learn in this thread is so unbelievable that I don't even know what to say anymore. This feels like pulled straight from Idiocracy.

Re: Home Assistant blocked from integrating with Garage Door opener API

#227

Post by ChainOfFools »

I highly recommend anyone having problems with this consider trying this free as in speech (and as in beer if you've got solderimg skills and an ESP laying around) solution: RatGDO [0]

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.

[0] https://github.com/PaulWieland/ratgdo

Re: Home Assistant blocked from integrating with Garage Door opener API

#228

Post by colinmorelli »

lloeki wrote: post #220
colinmorelli wrote: post #168

Earlier quoted context omitted.

1) Home Assistant is not an officially sanctioned option by the devices and will run into technical issues regardless whether it's cloud hosted or not (as seen by the very post we're all commenting on). 2) Even if the above were not true, at that point you're back to an internet enabled smart home device system, and now we're simply picking which vendor to trust over the other. But in both cases, the option for the v…

> Even if the above were not true, at that point you're back to an internet enabled smart home device system Home Assistant Cloud is essentially a TCP-level proxy (IOW Nabu Casa sees jack squat): > The remote UI encrypts all communication between your browser and your local instance. Encryption is provided by a Let’s Encrypt certificate. Under the hood, your local Home Assistant instance is connected to one of our cu…

Yeah so this is why I said "no way for the typical consumer to have a product experience like this" because what you're saying is true, but not something an individual can rely on.

Typical consumers have no way of ensuring their UI is, in fact, encrypting the data and not farming it out. They cannot verify the source code themselves, because they don't have the technical skill set they'd need to do so (nor, frankly, the time). They're reliant on the goodwill of whoever packaged and installed the offering for them not doing anything to that offering.

Technical power users can circumvent this because they can build/install from source, verify keychains, read the source, etc. Non-technical users can't do this, and need someone to help them. That someone will most likely be in the form of a third party organization that does this in exchange for money. They're placing their trust in that third party.

The point I'm getting at is that, eventually, a consumer has to trust a third party who may have incentives that don't align with their own. They're just playing a game of which vendor to place that trust in. This is why centralization is still the predominant architecture choice for the overwhelming majority of products, even in a world where myriad decentralized solutions exist for almost everything. It turns out that having bespoke third parties run decentralized solutions for customers is often not a better product experience, and still has the same root problem even if it manifests in different ways.

Re: Home Assistant blocked from integrating with Garage Door opener API

#229

Post by TeMPOraL »

gog wrote: post #84
zamalek wrote: post #21

Home Assistant should really maintain a list of actively hostile (and actively cooperative) manufacturers to make it easier to decide what to purchase.

On each integration page there is a button that states if the integration is local or remote.

Oh, that. I'm actually wondering if they are making this hard on purpose.

The obvious way to implement this would be to have a front-and-center filter for cloud/local, so that one could use it to check which brands to consider before buying new connected hardware. It's a use case people have been asking for years. It's the only reason one would want to access a searchable list through their own page (as opposed to googling "${brand name} home assistant").

What's the blocker here?

Post reply on HN