Home Assistant blocked from integrating with Garage Door opener API

From company statement:

Our customers rely on us to make access simple without sacrificing quality and reliability. Unauthorized app integrations, stemming from only 0.2% of myQ users, previously accounted for more than half of the traffic to and from the myQ system, and at times constituted a substantial DDOS event that consumed high quantities of resources.

Yeah, that sounds plausible, because:

- Home Assistant users are power users, thus more likely to actually use the devices in question;

- Official IoT software and integrations are uniformly shit, designed to discourage effective use (while maximizing data collection).

Thus, I read this statement as: "We're not happy that some of our customers decided to actually use the 'smart'/'connected' aspects of our product; our service-providing part was not ready to provide the service, and unlike the data collection part, it was never intended to."

The problem is that these require some kind of server. Get one that just talks to HA over your local network.

Why in the hell does a garage door opener need a server?

Oh, data collection. And subscriptions. Nothing for the user.

I avoid any home automation thing that has any cloud backing that's not strictly optional. It's a strong anti-feature. In home stuff cloud means it won't work when the Internet is down, it spies on you, and it can become a brick or start requiring a subscription at any time.

You can access the device when you're away from home if it's internet connected. Of course, the server doesn't need to be doing much besides proxying connections.

And of course, you can easily run a VPN/Tailscale/ZeroTier/whatever to achieve the same without the downsides.

I'm quite confident my parents and the many people like them in the world would not find running VPN/Tailscale/ZeroTier to be "easy." Nor would they have any idea how to troubleshoot when those services have issues. Nor would they want to play intermediary between Tailscale and myQ customer support to figure out which one is broken and fix it.

Having options like this is great for powerusers, but the vast majority of people are not that. They need something that just works. Of course that still doesn't mean they need their garage door collecting telemetry data, but they need something more than a LAN-connected smart device.

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 vendor to collect telemetry data about your usage of the products exists.

There is really no viable way for the typical consumer to be able to both have a good product experience for something like this, and to prevent a cloud vendor from having access to their data. Unless I'm missing something obvious.

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 custom built UI proxy servers. Our UI proxy servers operate at the TCP level and will forward all encrypted data to the local instance.

Routing is made possible by the Server Name Indication (SNI) extension on the TLS handshake. It contains the information for which hostname an incoming request is destined, and we forward this information to the matching local instance. To be able to route multiple simultaneous requests, all data will be routed via a TCP multiplexer. The local Home Assistant instance will receive the TCP packets, demultiplex them, decrypt them with the SSL certificate and forward them to the HTTP component.

The source code is available on GitHub:

SniTun - End-to-End encryption with SNI proxy on top of a TCP multiplexer

hass-nabucasa - Cloud integration in Home Assistant

https://www.nabucasa.com/config/remote/#how-it-works

https://www.nabucasa.com/config/remote/#security

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.

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.

The problem is that approximately NONE of the commercial vendors are in any way trustworthy. They're really pushing hard the degree of abuse they inflict on the customers, and social immunity takes long time to build.

The ultimate solution IMO is to have people trust in people they can actually trust - that is, make the third parties local. A partner, a kid, a neighbor, a small company servicing the local community and physically located in it. At this scale, trust can be managed through tried-and-true social techniques humans are innately good at, and have successfully used for many thousands of years. This is how you make most of the tech industry and adjacent problems go away.

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.

Sounds like there's a market for intermediary tech support

Perhaps in general, but if the problem here is "I don't want a corporation to have access to when my garage door is open or closed" I can't fathom how "Give another corporation access to my entire network to troubleshoot my VPN and LAN configuration of my devices" is the solution?

The solution is to "give my tech whiz kid/neighbor/friend, or a local IT shop two blocks over, the responsibility of managing my home network".

This is where ideas like non-shit IoT, Right to Repair, Free (Libre) Software, and even "how to not fuck up foreign aid 101", all converge. The point isn't to make everyone their tech support. The point is to allow local communities to be more self-sufficient, able to manage technology on their own - as opposed to outsourcing everything to some faceless companies that have no attachment to any given community.

Note that this doesn't preclude business - on the contrary, local businesses are the fundamental part of any community larger than couple dozen people; the ideas converge not on everyone doing stuff pro bono, but on small, local businesses* doing things for their communities, accumulating and retaining know-how.

I wish more people from aforementioned movements realized their ultimate goal (at least in form that's possible in the real world) is the same, and joined forces.

My wife doesn't understand what I do on the computer all the time and she's pretty doubtful of my claim that server racks are normal household items. Nevertheless setting up the HA app on her phone with a Wireguard VPN was super simple and she's got a good handle on that.

That being said, setting up the HA and Wireguard server is definitely a more demanding experience. Although once setup it's pretty much a once and done sort of thing, and they're are integrated ready to go solutions available.

It would be nice to see something like "Geek Squad" offering that sort of service instead of just running AV software while trawling for nudes on customer laptops. No guesses on what's more profitable though.

she's pretty doubtful of my claim that server racks are normal household items.

Haha, she's got you there.

easily

Not for the average consumer.

I actually have gotten to know a lot of folks who are massive into home automation, who also know precisely fuck all about computers or whatnot.

I refuse to use cloud services, and I use tail scale, but telling the average consumer to do this instead of using whatever app came with the device is not going to work for most people

There are home assistant integrations for all of those. HA can also open a port via uPnP and use Letsencrypt.

You don’t need a cloud server to remotely access a device.

Most VPNs need significantly extra work to get notifications to pass through.

For example, Apple Home does not work by default over WireGuard.

Why would you need to access a garage door opener when away from home?

Putting aside the very legitimate use cases highlighted in other messages, a very simple one is: you're just arriving at home, but are still not (yet) connected to wifi.

These very practical daily occurrences can make devices incredibly annoying and frustrating for typical consumers who want it to just work.

That's why I have a radio remote in my car and in my living room and never bothered automating the garage door any further.

I find it handy for when I'm outside but not in my car—on my bike, working around the yard, etc.

For the "working around the yard" idea, I just got a keypad mounted near the garage door. It is wireless, it just acts like a remote which requires a pin before it sends the toggle command.

I forgot it open.

the real solution here is to make it auto close locally.

That's a nice to have feature. However there are cases when one wants to keep it open for hours or, as pointed by other replies, to open it to let somebody in. An edge case I just thought about: open it to let somebody delivery a package inside, possibly by looking at them with a camera, and then close it.

Give access to a friend or family member when you're out of town.

Allow package deliverers to put a package in your garage instead of on your step.

When I had MyQ, I used it almost exclusively when I was on my motorcycle. I had it configured so that I could tap a button on my phone that tracked my location and enabled a geofence around my house so it would ping the MyQ to open when I got about a quarter mile from home. I called this my "riding home" mode. This saved me the trouble of having to get my gloves off and open the door through the app when I got to my driveway, and I didn't have to leave a garage door opener on/with my bike.

To let in your cat sitter.

Check if you left it open? Let someone in remotely?

You can also just do both.

I'd rather that it use the LAN, if I'm there at the time.

Data collection and remote access can just be their own functionality.

Homekit provides this as well, and by default is local only. There really is no excuse for these devices not to support homekit out of the box other than a money grab.

Oh, data collection. And subscriptions.

This makes sense (and myQ’s privacy policy is a nightmare: https://www.myq.com/privacy-notice) but I’ve never understood how this particular bit of data is valuable to anyone. Any ideas?

I buy a garage door opener. That is the end of my transaction.

I buy a connected garage door opener. The provider knows my geolocation, my name, email address, socioeconomic status, even the phone I own. Inferences can be made on activity such as "they leave for work at 7am when garage door opens".

The collection of data doesn't need to be used specifically for reengaging me with Chamberlain. It is now an asset to the company that can be sold to others as outlined in their Information Sharing section. Which basically says "we share it with everyone".

Partners can be anyone from insurance companies to academic researchers. Remember that partners aren't limited to just one data set. They have the ability to ask multiple companies: "What data do you have for all occupants of houses in this geographic area?"

Remember that partners aren't limited to just one data set. They have the ability to ask multiple companies: "What data do you have for all occupants of houses in this geographic area?"

Yup. And to make the issue clear: there is no such thing as "anonymized data", there's only "anonymized until correlated with enough related data sets".

No direct experience, just my guesses

* someone who drives frequently may rank higher for automotive products and services

* use to independently rank other statistics, i.e. someone with kids probably comes and goes more than a single person or non-child-rearing couple. Take the dataset where you know they have kids (and myQ) and see if you can detect the ones with kids using only myQ data (plus other statistics). If it allows you to infer this property accurately enough, profit.

* Someone who comes and goes a lot is most likely not physically disabled, so exclude them from those specific marketing materials.

* someone who is home a lot (hardly ever opens their garage door) might like to spend money on useless gadgets, try selling them IoT toasters

Number of active car owners living in an area could be valuable for a few industries and governments

In the updated fairy tale, the 3rd little piggy actually perishes, because his house got bricked by the Big Bad Wolf IoT service.

It's a good thing the piggies invested in light infrastructure and good logs with their previous houses, the next version after brick will be even better!

I still prefer the version where the fourth pig built its home from wolf bones - while it wasn't the best building material, it made a point.

Nah, the wolf just pays a minimal fee to the IoT provider so it unlocks every door on the pig's house.

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.

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

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.

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.

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.

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.

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

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.

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.

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

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.

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, feeding new known good values back to the first.

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

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.

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.

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

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.

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.

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

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.

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.

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

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.

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

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

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.

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.

- Home Assistant users are power users, thus more likely to actually use the devices in question;

50% traffic from 0.2% of the users is far too big of a discrepancy to just explain it away with powerusers. Customers too have to follow a fair level of usage.

designed to discourage effective use (while maximizing data collection).

What valuable data can they collect, if nobody is using it?

This thing probably phones home every time you open or close your door, no matter if you do it via their smart portal or manually.

Yes, but according to their statement, the official client seems to behave better than the HA-implementation. Maybe HA is brute forcing something, like pulling state every 10 seconds or so. And this is a legit complaint from their side if this is the case.

If pulling the state goes through the cloud app it is their (self-inflicted) problem.

Sure, and because it was their problem, they made it the problem of those who gave them this problem, and pulled the plug.

But let's get real, 0.2 of customers are probably also matching around 0.2% of their income with those products. So it's probably not really a problem, short term.

Long term, they probably have damaged their brand hard, and missed out on some revenue from grassroot marketing. But that's a problem of future chamberlain. Today, the one responsible for this has solved their problems, calls it done and gets their paycheck.

And who knows, maybe next year they switch to Matter, get some good marketing from it, raise the sales and the victims from today are forgotten. That's business..

Probably because the official client only checks the state if you open the app, while HA probably does it every so often.

Legit solution would be for the company to allow local access to the garage door to check the state without needing to go through their servers.

As a former MyQ user, I can say definitively that this is accurate. There's a magnetic sensor that you put on the door for it to track the state of the door, so the app is always correct on whether it's open or closed.

I think they want you to install their app so that you have to open the app everytime you press the button. From there, you see ads to other products.

I use the myq app to open my garage door open regularly. The app is slow to open and generally annoying. For example, the whole interface is initially blocked, so you tap to open and it doesn't register the tap, still doesn't register the tap, then finally it does.

I was not aware of there being ads in it, but I just looked, and you are absolutely right, there is an ad at the top. It looks like its for their home security camera.

Based on my experience with the company, I would not purchase additional products from them. Not based on my desire to use home automation or homekit, just on the fact that the app is poor.

The garage door openers themselves, however, which have battery backup and which open quietly and with a gradual slowing near the finish, are pretty decent. Mainly I wish they had a better, faster app, as the garage door is the smart home thing I used most (followed by maybe Rachio).

I use the myq app to open my garage door open regularly.

It used to ask me to provide a rating every time I opened the app. I eventually added a negative rating because it kept asking even after I had answered "Do not ask me".

What valuable data can they collect, if nobody is using it?

What permissions does the app have? If it has location data so it can open/close the garage door based on proximity, it can probably collect your location whenever the phone is on and that can be sold to data brokers. That's just an example. There is potentially a trove of information the app could collect and sell and not just when the user has the app open.

Of course if the app is never installed it collects nothing. I wonder if the vendor requires the app to be installed for initial configuration.

And IAC, it would be preferable (to me) to have a device that works entirely locally.

What permissions does the app have?

"Location" (while using App) and "Notifications". So it can locate you when you trigger it, but it can't track you all the time.

They do not support opening your own garage door via IFTT, Alexa, or Google Assistant.

They do support allowing their paid partners (eg, Amazon) to open your garage door for deliveries. I think this last part is where they get "value".

Valuable data is in the eye of the beholder: such as burglars, home invaders, stalkers, panty-sniffers, voyeurs, blackmailers, robbers, kidnappers, spies, squatters, vagrants, wild teenagers and dumb adults that are scouting for their next juicy target.

“Valuable Data” doesn’t have to be valuable but can be valuable anyway if investors and other partners believe it is.

I have a MyQ door opener (and home assistant)

This is bullshit. Their app is bloatware that they use to try to push additional services like Amazon home delivery etc. I mean it’s just a button, that’s all it needs to do.

I’m going to replace it with one of the recommended devices. This is such an overt money grab.

I have the MyQ app (iOS).

I don't mind it at all. App works, fairly fast, the stupid extra stuff is just a chunk of the screen I can ignore / don't have to do / interact with.

I don't approve of the API situation but the app itself doesn't feel particularly bad.

The iOS app sounds like it's better than the Android one.

What is the Android app like?

Ah, ya that might be it. I use the iOS version and it works well.

I do agree that their app works perfectly fine. And it's as responsive as HomeKit, but I don't want to have to launch 20 apps for my various devices.

In fact, after my initial irritation, I thought "at the end of the day, if they made a couple shortcuts available then I could still say <Hey Siri> Open the Garage door" – It's not perfect like homekit but it'll go a long way to placating many of us who don't want to keep launching a separate app.

This. Chamberlain/homeassistant user here too.

In the past the app has gone the lengths of make us try to use their own assistant (!).

Why the fuck would I ever want to use a voice assistant from my garage door provider? Seems like a desperate attempt to enter a market that doesn't even make sense for them as they currently are.

Unofficial IoT software and integrations are not (much?) better. I wouldn't be at all surprised if this was partly due to a junk integration for this device cobbled together by an amateur and replicated by thousands more amateurs into their own ginormous pile of other junk YAMLs.

Why did that software work mostly fine most of the time since 2017? Even Chamberlain admits their blocking is deliberate. Even Chamberlain's external statements suggest this is part of their corporate strategy.

Why is Chamberlain's API so brittle it can't stand prodding from what they claim is a tiny fraction of users, even if those are misbehaving? Do you agree that comparing that to DDoS is ludicrous, and suggests either dishonesty or a fundamental misunderstanding of what "DDoS" means?

partly due to a junk integration for this device cobbled together by an amateur

Judge for yourself, here's the code:

https://github.com/home-assistant/core/tree/5523e9947d82ac14... (before it was removed)

https://github.com/arraylabs/pymyq/tree/master/pymyq

At the end of the day this is a very reasonable business decision - an incredibly obvious and easy one.

Chamberlain/myQ makes very low cost (likely loss-leader) mass manufactured devices. Like anything else if you can identify 0.2% of your users leading to 50% of an issue you're having the reasonable thing to do (from a business perspective) is to just cut them loose. If this CTO or anyone at Chamberlain were to try to champion support for HA users people with the numbers would look at them like they are crazy. For 0.2% of the user base it barely justifies anything more than a 10 minute conversation with a foregone decision.

I use and love Home Assistant. While it's a "big deal" to techies and power users like us the total installed base (as these numbers show) is infinitesimally small when you zoom out and look at the total "smart home" market. There are 275k active Home Assistant installations[0]. This number is already tiny compared to myQ sales. Then you can check the myQ integration and see that it's only used by 3% of HA installs[1]. Home Assistant is insignificant to Chamberlain and Chamberlain is insignificant to Home Assistant.

For a device that sells for $30 8,250 HA installs is $247,500 of total device lifetime revenue. Chamberlain has $820m of revenue per year. Even if every one of these installs bought four devices that's less than $1m. They. Do. Not. Care.

Again, I don't love this either. It's a jerk move but when viewed through the eyes of a cold and calculating business it makes perfect sense. Frankly I'm surprised this decision didn't come sooner. Especially when you consider all of these awful commercial devices really want you to install their app so they can push who-knows-what and upsell at every possible opportunity. That's an entire revenue stream they will never tap into with users utilizing the API and few businesses can resist gobs of money they see as ripe for the taking. Sad but true and standard for nearly any business. Even more so for a de-facto monopoly like Chamberlain.

HA users and people here are outraged, and that is completely fair but with these numbers Chamberlain isn't even going to remotely feel this.

At the end of the day HA is extremely powerful and the ecosystem and maker-ish community around it is incredibly robust. A device with a contact sensor on door close/open and relay (or something) to toggle the door is trivial. It's what I've been using since before MyQ or anything like it was even on the market.

Just avoid the commercial "IoT/smart home" junk whenever possible.

[0] - https://analytics.home-assistant.io/

[1] - https://www.home-assistant.io/integrations/myq/

Yeah, I always felt like the implementation wasn't that good. But, tbh, rate limiting them and saying "hey don't poll quite so much" would have been trivial compared to the approach they ultimately took.

And obviously people with HA will use it more than people that have to wait a ridiculous amount of time every time they open that stupid myq app. It was terrible.

One would think a reasonably decently written HTTP client with a server that responsibly responded with HTTP 429's when a client was polling too hard would be able to set a standard and enforce "good netizen" behavior.

If you buy a device that relies on a server connection for functioning, you might legally own it, but it essentially is 'on loan' by the company.

Well, you could always strip it for copper, I guess...

Devices that rely on cloud infrastructure should be required to carry an expiration date right on the box. "This item guaranteed to receive support until XX/XX/XX"

I prefer to have an e-waste law that says that if you stop maintaining the service, you have to open-source it :)

Unfortunately, this is just wishful thinking. Take an example where a company is going under. If such a law existed, it would be unenforceable as the company does not have the resources and know-how how to do such a thing. After they file for bankrupcy, there is no point in punishing them.

Software escrow processes could (partially) solve this, at an upfront cost for every company developing and selling such a device (meaning, at a price that will ultimately be paid by consumers).

Some government agency could be doing the escrow, at no charge to the company.

There is still a process cost to participate in any escrow process, both on an initial and on-going basis.

(That's before the blindingly obvious observation that even something provided by the government at no cost at point of use has a cost which is ultimately borne by the people.)

I don't disagree with either statement, but I think both of those are a price worth paying to avoid having hardware become e-waste because software support was stopped.

I agree with that conclusion.

I think we'd also need to figure out some durable and stable way to reach a conclusion on "when should the software be published out of escrow?" that handles a bunch of the various edge cases. "What happens to devices that are one-time programmable? What devices are in-scope/out-of-scope? Does this apply to radio firmware as well as general CPU firmware? Is the software license changed alongside the release of code from escrow? Are signing keys also released? Is code released from escrow just because some individual use case is no longer supported by the mainline firmware? [Is a disagreement with a product decision enough to release the old code?]"

I agree as well, though I don't think we need to figure out all edge cases before the legislation is viable. All we need to do is allow any person who purchased said software a private cause of action in which they can petition a court to release the code. Then a judge could decide based on the merits of the person's need whether the code should be released or not.

I think that situation exists now, which is the essential root of the problem.

It's too expensive and too unlikely to succeed, but I could sue Chamberlain now arguing that they have breached an implied contract and that the remedy I seek is for them to open-source their code.

I disagree; I believe any lawsuit brought against Chamberlain today would be dismissed for lack of standing. Further, even if it wasn't, I think you would have a very hard time convincing the court that open sourcing their code is a reasonable remedy.

Best case, I think you'd get your purchase price back. I'm not sure how you'd argue that remedy is insufficient, either - hence why my preference is to have the cause of action written into the law we're imagining here. It'd be even better if we can write in that the remedy for a degradation of the service is an open mechanism by which the user has sufficient level of control as to recreate their desired functionality.

All you need is an option you can set on a private repo in Github so that if you close your account or don't pay your fees for 3 months it automatically becomes public rather than gets deleted.

Yeah open sourcing code sounds nice but that's the pipe dream of the tech literate. A real workable solution would be regulation defining and banning ewaste creation and consumer protection from vendors rug pulling product support. Penalizing deviant practices and incentivizing open industry standards.

So they publish the crypto certificate that allows opening anybody's door?

If that exists, the company should be shut down for gross negligence, even before they go bankrupt.

Unless it's security by obscurity, releasing the source code of the entire infrastructure should never result in all systems becoming compromised. So, assuming the API is run over HTTPS with authentication tokens, Chamberlain wouldn't need to (and should under no circumstances) release its SSL certificates' private keys. Instead, the firmware and server infrastructure should be easily modified by the user to point to their own servers (or get rid of intermediate servers and directly be usable on the local network, which is the only good solution anyway).

That will only work for the code the company owns herself. But they can't open source code they licensed themselves, which means they can easily cheat the law by outsourcing their code.

Yes, but if there is a law like that there will be demand for open source components, like drivers, and if there is demand there will be offer.

Because that works so well with other laws...

once the company goes bankrupt there might be no one left to open source the leftovers if that's even legally possible due to NDAs, 3rd party licenses, etc.

Then it should be anticipated. Just like a company is required to pay employees what it owes them before it eventual shutdown, even in case of bankruptcy.

Also a very good option. Ideally it should trigger immediately once a regression happens and at least 12 months prior to service eol (give users time to migrate)

I'd prefer to have antitrust regulation that stops this bundling of software with hardware from day 1 - ideally applying to both app software, and the embedded software on the device itself. When a product is going end of life, it seems awkward to enforce a requirement on companies and difficult to get traction for a libre development community.

There are lots of devices these days that rely on cloud infrastructure, like Apple devices, Teslas. Its becoming more devices.

The same for software. Even Microsoft is going fully Cloud. Just had problems to activate my MS Office for Mac Business 2019, which I bought in physical. They now require on @outlook.com email address to be able to activate. Otherwise I can't use my "box" software.

They require Microsoft account, not an outlook.com address; though that address is an easy way to get the account. It is used for activation/license management, one nice feature is that you can yank a license on a dead device and use it with your new one.

Outside of activation, it is easy to use MS Office for Mac completely offline -- there's a checkbox for that in preferences. You will lose some marginal functionality, some of which I prefer to be disabled (like generating pdfs of your documents server-side instead of client-side).

Nope, a Microsoft account is not enough. It must be an @outlook.com address, or any registered company/school/university address.

It took me almost 3 days to find the problem. Microsoft changed that and between all "answers" there is only one single thread in the Microsoft forums that had the solution.

What does "any registered company/school/university address" mean?

Some years ago, I activated some Office licenses using my company email; we never did any hosting with O365 or whatever was it's predecessor, and at the time, everything went fine. All I had to do was to create live account using that email address.

The error message is along the lines: "You can't sign in here with a personal account. Use your work or school instead".

Which means, that you need to associate your existing account with an @outlook.com address. It seems, that Microsoft changed that requirement somewhere in 2020/2021.

Yes, previously Microsoft account with whatever email address was enough. But they changed that.

I stumbled upon that while upgrading to new hardware, which requires new activation of the Office products.

The same pirated copy of Office 2007 has been doing me fine for well over a decade at this point.

We are a small company. I don't use pirated software. I like on-premise software over cloud solutions. Adobe and Zoom ae the only cloud solutions we use. Zoom is obviously. But I look on how to get rid of Adobe, while Adobe Stock has no real competition as the bought Fotolia, which we used before.

Serious question: did you try pexels? for most of my stock photo needs they are okay (not great but okay), and all pictures are public domain and free of charge. They don't have stock video tho. :(

I updated it to version 2010. Much much better. Jack Sparrow ahead:)

Just do it. You won't regret it. I also bought office 2016 cheap at some point in time. That's even better. Faster, nicer UI.. just to give you feedback xD

The cloud is some one else’s computers and internet.

That internet connection for cloud services for smart gear always costs someone.

Smart home devices that can’t be locally hosted or easily made to be locally hosted should be avoided.

There’s no reason a light switch that normally works for 10-20 years will only work for 2-5 due to cloud connectivity.

Luckily for the time being a lot of the providers can be reflashed with Tuyo based firmwares.

Agree with you overall, while adding a note that light switches normally work for far, far longer than 20 years.

Extremely fair comment that light switches normally work far longer than 20 :)

The date should at least match the expiration date of any root CA public certificates installed on the device.

Partially responsible for this. (Sold Lockitron to Chamberlain in 2017 which became the basis for Amazon Key integrations.)

Contrary to the popular sentiment in a lot of the comments here, there’s not much value in the analytics. As we all painfully found out in the 2010’s, there are only two viable recurring revenue streams in the IoT space - charging for video storage and charging for commercial access. Chamberlain does both with the MyQ cameras and with the garage access program to partners like Amazon and Walmart. Both retailers have a fraud problem (discussed here https://news.ycombinator.com/item?id=38176891). “In garage delivery” promises dropping delivery fraud to zero - ie users falsely claiming package theft. That solution is worth millions to retailers, naturally Chamberlain would like a cut but only if they can successfully defend that chokepoint.

For historical reasons having to do with the security of three or four generations of wireless protocols used in garage doors they can’t (and products like ratgdo and OpenSesame exploit this.) Other industries such as automotive have a more secure chain of control over their encryption keys so one has to (for instance) go to the dealer to buy a replacement key fob for your Tesla for $300 and not eBay for $5.

Given the turnover in leadership there I’m not surprised the new guy needs to put their hand on the plate to see it’s hot, but there’s a reason this wasn’t implemented before and it wasn’t because of lack of discussion. I can see the temptation in going for monetization given their market share but I think this approach was ill conceived rather than fix foundational issues which would allow home users to integrate with 3rd party services and still charge industry partners for reducing incidences of fraud.

A stressed out underpaid and overworked delivery driver is the last person I want in my garage. Verified deliveries are left at the wrong house, or the driver simply takes it with them after posting the porch picture. And I've seen boxes arrive that were forced open and the contents pulled out. But sure, it's the customers who are untrustworthy not the delivery people.

True. Delivery drivers consistently deliver to my neighbor instead of myself. The last three digits of our addresses are 885 and 855, and they consistently confuse the two. They’re tired, overworked, underpaid, and I honestly don’t blame them. But I wouldn’t trust anyone in my garage/home when I’m not home. Not sure why these companies think that will actually work.

In US homes the garage is often a way to access the house with minimal security between the two.

That’s not true, the garage typically has a full outdoor door with standard security (dead bolts, wired into the security system) the same as any other door as the interface door between the garage and the house. This is a code thing for a variety of reasons but primarily because the outdoor door is weatherized and provides a barrier against CO, but also for the precise reason that the garage door is not considered secure. The protocols for opening the door wirelessly are known insecure and municipalities have required outdoor doors at the interface due to the number of home invasions and burglaries through the garage.

At least in my experience people are a lot more likely to leave the garage door unlocked than the front door, either intentionally or unintentionally.

Agreed. Our garages have always had three entries: one from the house, one via garage door, and a side door. Side door was always locked, garage door always closed (never locked though), and the door between house and garage not only almost never locked, but often flat out open because that's where we put the litter box.

haha, our litter box is there as well. vinyl floors in mudroom are easiest to clean.

i also keep expensive things in the garage: onewheel, a couple good bikes, a lot of nice tools. i assume this is true for quite a few homeowners.

I've got an 80% hit rate at best across all carriers (in the US). I'm constantly trading mail with my neighbors due to mis-deliveries. It's a good thing we now have the option to go mostly paperless for important documents at least..

Heck, I get food misdelivered to me at times! I might as well be a last mile delivery service

They think it will work because if you refuse to do it they won't refund your stolen package unless you file a police report, and convenience with huge downsides wins with consumers 99% of the time over effort with no downsides.

This is just conjecture, btw, I have no authoritative knowledge of their plans to do anything.

Missing packages are not really a police matter for the recipient. Recipients don't actually know that a package was stolen, since it never made it into their possession. Amazon could certainly file police reports, but that requires a higher bar of evidence than throw-and-go delivery service provides, and either way it Doesn't Scale (TM).

I'd guess it's more likely the opposite dynamic, where they'll get a bunch of early adopter types to sign up without thinking through the ramifications. And then after the honeymoon period, Amazon will start demanding those users file police reports for missing packages since from their system it now looks much more airtight that the package must have been stolen from the buyer.

I use it for expensive items. My garage door opener has an integrated security camera.

A stressed out underpaid and overworked delivery driver is the last person I want in my garage. Verified deliveries are left at the wrong house

It doesn't work like this. Delivery workers use an app that opens the door, so if they are at a wrong location, it will be immediately apparent.

Subject to location service accuracy, which as we know, is ±1m... in movies, ±10m in reality... except more often it's ±50m or worse, because who knows why.

Not at all. Since the app is linked to a system that opens your specific garage door, it will be obvious because they push the button and the door in front of them does not open.

This can happen. A delivery person comes to a door, presses the button in their app, and nothing happens. So it's immediately obvious that they are at a wrong location.

And they know that they can't just leave the package there, they have to find the correct door. And there's a flow in the Amazon delivery app to mark an incorrect geolocation, so they won't be penalized for taking longer time.

The app also has pictures of the location in question, to minimize the confusion.

From the homeowner's side, the garage door will be open for half a minute or so with nobody nearby. It's possible for a burglar to use this time to quickly run inside. But the probability of that is pretty low, and there'll be a camera recording of that.

A stressed out underpaid and overworked delivery driver is the last person I want in my garage.

Same, but this is irrelevant to the point GP was making. Some minority of people do want Amazon Key (and similar services), and those people are now unable to claim their package wasn't delivered once they sign up for the service.

Add those people up and you have something worth millions, even if there aren't many of them.

I live in a townhouse and I _love_ the Key deliveries into my garage. I've been using it since it was a closed beta, and I haven't had a problem with it.

It provides a convenient service for both parties.

I fully suspect though that the people who do want Amazon Key and the people who are happily defrauding Amazon are not one and the same.

I realise that there are the porch pirates who are another issue entirely!

Have you seen Walmart advertising delivery to your refrigerator? Absolute insanity.

Actually, this would be cool for say a fridge in a mudroom...

So you're saying that retailers will pay Chamberlain to act as more or less a clearinghouse for package deliveries in my garage, and that in order to successfully operate this model Chamberlain needs to funnel all users through their proprietary channels in order to fully vet the delivery transaction? Or at least to prevent HA users from nibbling at Chamberlain's lunch with DIY equivalents? Do you think that they will pull back from this move given the pushback?

For retailers I want someone to verify that they are legitimate. I don't want random people in my garage. If someone enters my garage when I'm not home they better really be agents for WalMart/Amazon/target/UPS (as opposed to WolMort/Amozan/targit/USP...) , and whatever company does that does background checks on drivers. Probably they also need to have other cameras in their vehicles so that drivers trying to steal whatever valuables I have are not stolen. (as already pointed out, most people have an unlocked door from the garage to the house)

as already pointed out, most people have an unlocked door from the garage to the house

Not sure where you live, but every house I've lived in (USA, a few different states) during my entire life has had an exterior-quality door with exterior-quality lock, including deadbolt, between the house and garage.

In the one house I lived in that had a security system, that garage-to-interior door was also wired into the system and arming it would treat it like an exterior door.

Having said that, I still wouldn't want random delivery people entering my garage without my knowledge.

I think parent comment was saying the door exists, but many people leave it unlocked. I grew up leaving that garage-interior door open because that's where we put the litter box, at several different houses.

I know it's a distraction and orthogonal to your point, but your statement of a "key fob for your Tesla for $300" is fallacious and incorrect. Tesla uses Phone Key with with the Tesla app as your primary method of unlocking the car, with a $20 NFC card as fallback, and the limit of paired phones is above any practical real-world use. If you want a keyfob as a status symbol, it's $175. (Mine is a desk ornament, it doesn't get used.)

Swap in a more traditional automaker, and your point remains correct.

Yes, I mean surely Chamberlain could maintain a correct and official API endpoint for HomeAssistant users for the kopecks it would cost. It’s all a big money grab.

I was burned by this change. I don’t know if anyone at Chamberlain is reading this, but you guys have neighbors, users just wanna keep their home safe. You’re one TikTok away from a crisis when you do stuff that is anti-consumer.

If you want a keyfob as a status symbol, it's $175. (Mine is a desk ornament, it doesn't get used.)

The keyfob is super-useful. It fits perfectly into that small jeans pocket (that was originally meant for watches), so you can trigger the trunk/frunk opening without taking the fob (or phone) out.

Why would any of those monetization strategies require fucking over your customers like this? How are they incompatible?

Who here claimed it was, they literally said it was “ill conceived”

They are afraid a potential partner will use the automation meant for customers.

This is just more enshittification in order to exploit revenue channels other than direct sales.

Lockitron! I remember chatting with your engineer about the WiFi radio we used in Twine. Good insight.

Ah, chokepoint capitalism. The problem with every company becoming a tech company is that they all expect unsustainable tech company growth. The strip mining of customers is also scaling up, so efficient that industries will destroy themselves. Can't wait until private equity owns the radios in my home, and controls not just the output but inputs.

This is what I love hacker news, a comment from an actual subject matter expert.

Based on my local big box store and garage installer availability, Chamberlain has a de facto monopoly. They also pulled the rug out from under customers: that behavior had been in Home Assistant since 2017, and it's their own recent changes that caused the alleged "DDoS". They say it's to promote official products, but the company previously had a local hub that didn't require their cloud service and discontinued it.

The API breakage coincides pretty well with their brand new CTO, whose objective is apparently "transformation to a smart access software company".

It's unclear if the CTO just doesn't understand that "DDoS" generally implies malice, or if they're intentionally using that language to blame users for using their product.

Good news: ratgdo, an ESP-based local solution works great. I hope the author is making a decent profit on the kits.

It's unclear if the CTO just doesn't understand that "DDoS" generally implies malice, or if they're intentionally using that language to blame users for using their product.

I've definitely seen "DDoS" used when there was no malice, such as when a developer accidentally releases a client that generates way more traffic than it was supposed to. Probably because we don't seem to have a good term for "event that at the server looks exactly like a malicious DDoS attack but was actually due to a mistake or to the server becoming unexpectedly popular" :-).

My favorite example of whatever we are supposed to call this was John Carmack in 1997. From his 1997-12-09 .plan:

Cyrix has a new processor that is significantly faster at single precision floating point calculations if you don't do any double precision calculations anywhere.

Quake had always kept its timebase as a double precision seconds value, but I agreed to change it over to an integer millisecond timer to allow the global setting of single precision mode.

We went through and changed all the uses of it that we found, but the routine that sends heartbeats to the master servers was missed.

So, instead of sending a packet every 300 seconds, it is sending one every 300 MILLISECONDS.

Oops.

To a server, it won't really make a difference. A tiny extra packet three times a second is a fraction of the bandwidth of a player.

However, if there are thousands of network games in progress, that is a LOT of packets flooding idsoftware.com.

So, please download the new executable if you are going to run any servers (even servers started through the menus).

A term I hear a lot for non-malicious or non-intentional DDOS is the Hug of death.

That's fair. Maybe my security background is shining through here. I guess we used to have "slashdotting" but that doesn't generalize well :)

I did do some napkin math to quantify how much that bad traffic may have been: HA estimates between 6857-25576 intallations of the MyQ integration. Let's say 16k clients. HA makes it really easy to detect and "add" the integration (which counts as an installation even if it's not configured), so, that's definitely not all clients hitting the API. Let's say it's 50%, so 8k actually using it. Most users just notice myQ is broken. Let's say some fraction retry, which would look the same as an extra user from a volume perspective. Call it an even 10k users (including repeat users).

The most recent change is after they broke everything past the OAuth dance. Let's say the OAuth request is 1kB. The retry code retries up to 5 times with exponential backoff. Let's say 5 requests over 10 min.

(5 requests / 10 minutes) * 1 request/user * 10k users = 5k requests/minute, or 83 per second, amounting to 83kB/s inbound.

There's no reason to assume those requests would synchronize, but I'm sure there's something (let's say every single myQ user updated at the same time).

If what they're saying is true, sounds like actually malicious botnet wielders can ransom the living daylights out of them. Given 1Tbs DDoS attacks they'd only need a tiny fraction of the full bore ion cannon! ;-)

[1]: https://github.com/arraylabs/pymyq/blob/master/pymyq/request...

Huh, nice. I went with a dry contact kit from Athom but status feedback is tempting (mine just uses a reed switch to detect state):

https://www.athom.tech/blank-1/garage-door-opener-for-esphom...

Getting status information from the door is the entire value prop from something like the ratgdo. It's the only reason I ordered one. Otherwise, momentary switches with HA integration are readily and cheaply available.

I use the Athom one also, and putting a reed switch in the fully closed state, as well as in the fully open state allows me to reasonably determine where the door is. Might not be enough for your case, but for me it was enough to know that the door is “kinda open”, or “fully open”, or closed.

Can someone post the endpoint it is trying to reach for “research” purposes?

Tsk tsk.

That project looks great! Now the issue is finding a Chamberlain or Liftmaster opener without myQ built-in. Or maybe I just don’t have to activate it.

Odds are that whatever nice Chamberlain opener you want will have myQ built in because that's their business strategy. You can try getting a different brand if you're voting with your wallet -- but if all you care about is security: the Cloud connectivity is optional and you can just not connect it to WiFi.

The ratgdo is more trustworthy, and it just connects (really easily, too, especially with the new v2.5 board) to the opener via the same contacts that the dry contact button does.

The API breakage coincides pretty well with their brand new CTO

You can go and engage him directly on the topic, maybe he'll present a perspective we haven't seen, or maybe he'll listen to your arguments and reconsider:

https://www.linkedin.com/in/dan-phillips-9a33831/

(and no, this is not doxing: his profile is public).

Came here to plug ratgdo as well - mine is supposed to arrive today! And he should definitely charge more.

I'm happy to not have one of their devices but if they did this after I had installed it based on the fact that it works with HA then I'd definitely sue them for breach of contract or whatever else I can think of or to get a full refund.

What a shit move to pull on your existing customers.

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.

That helps, but a remote integration doesn't _have_ to be hostile. I get that it's different from IoT, and most of my stuff is local Zigbee after learning the hard way, but my Home Assistant also talks to the Norwegian meteorological institute and Tailscale :)

One reason this is tricky to do is because up until let's say the last 6 months or so, myQ _wasn't_ hostile, even if it was Cloud-based. (I get that that aligns with your point! I'm not arguing with you there.)

All remote are more potentially hostile than any local will ever be.

Yes, but some can't be local. For instance an integration that scrapes news from a website.

Sure it can be local - in the sense that all control and scrapping lives on your machine.

But in general, OK - some things are better done via an on-line service. But it's the minority of cases - almost none of IoT devices have a legitimate reason to route control and diagnostics through the cloud.

And a local integration can be hostile if it's not publicly documented and they can update it / make it go away with an over the air update.

What matters is that they provide proper documentation for their APIs, encourage devs to use them, and don't have a history of breaking old clients with new firmware updates (without very good security reasons).

And the company doesn't even have to be actively hostile for remote to be risky.

The company could go out of business and shut down their servers. Or shut down the servers because they're no longer selling the product.

Sometimes incompetence is as bad or worse than malice. The company could break an API accidentally. Or the API only works intermittently. Or they could add poorly-implemented rate limiting that unintentionally affects multiple users when they share an IP via NAT.

Yes, but you have to open each integration page manually, you can't filter by this.

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?

And put it high and proud on the site!

I use Home Assistant and have this openner. My installer recommeneded it because he’s had happy customers like me who use home automation. I can tell you that I a) will never recommend or buy the brand again, and b) have already complained to my installer about his recommendation of this line (and he is moving to another brand).

I wish ratgdo a ton of success and have several on order.

On top of the lack of integration support, the MyQ app used to open garage doors is full of advertisements. It's ridiculous. I regret buying their products.

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

Actually, some other commentator statet, that when he's about to open/close his garage door, he opens the official app and where there's been a "open/close" button is now a video ad and to reach the button, you have to scroll the screen until you reach it.

I would try to sue that manufacturer. I hope it we'll be pulled to a court.

And there you have it folks. That's the number one reason why they are forcing you to use their app.

have already complained to my installer about his recommendation of this line (and he is moving to another brand).

What brand is he moving to? Does it work with Home Assistant?

I can't recall the last time I saw a garage door that wasn't Chamberlain or one of the brands they own. At least in my area they seem to have a near-monopoly.

Hopefully it has a native HomeKit integration.

I don't blame your installer for recommending it. I've had a myQ opener since 2015 and it's been rock solid... it has been the most reliable home automation product I have ever owned, until now.

Why does a garage door need an API?

Two reasons:

1. My wife can check that we didn't forget to close it instead of driving 20 minutes back home to quell her nerves.

2. We can let a friend or neighbor into the garage (or into the house if we use the smart lock on the door inside the garage) when we're not home. Without giving permanent access to a key or PIN code.

1. My wife can check that we didn't forget to close it instead of driving 20 minutes back home to quell her nerves.

Seems like a bit of an ill-adaptation. I used to want a smart door lock for exactly this reason, but instead I learned to be mindful when I close my dumb door...

You can teach yourself to be mindful, how about the other people in the house? Or will you personally check it every time the house is empty?

Let me know how you feel after you're married.

My garage was broken into. The open door warning is how I found out.

My chamberlain remote pad opener from like 2012 has “burner” codes that operate a certain number of times, down to a single use. I have one programmed if I need to let someone in.

To allow remote control. Of course this is silly and the real answer is to make you dependent on their app which shows you ads.

Also many smaller smart home device manufacturers with an app seem to be heading in the direction of wanting to expand into other smart home devices and lock you into their proprietary ecosystem, while the rest of the industry simultaneously seems to move towards more interoperability via things like the Matter protocol, presumably to make it easier to interact with various voice assistants without requiring an individual gateway for each one.

This is just another reason to distrust any smart home device that doesn't support ZigBee, Matter, or a similar purpose-built local protocol.

Maybe so people will get alarmed when the garage opens, while they are not at home? Or for them to open the garage remotely for deliveries, workers or visitors. Does this system support this?

Is this "myQ ecosystem" the only way to interact with these garage doors? i.e. is there no way to communicate with them without involving the manufacturer's server?

You can buy little ESPHome devices that will speak it’s local serial protocol and control it. (And then link to them how you want)

It’s incredibly annoying and dumb and I now have to get some. grumble

You can just use a relay to open and close the door if that’s all you want.

Edit: no you can't, if it's the fancy one. You gotta hack a switch like this: LiftMaster 883LM Security+ 2.0 MyQ Door Control Push Button

Sort-of: the newer ones require the physical button to speak the same rolling code protocol the remotes do. So, yes: but you have to modify a real door opener. ratgdo has the advantage that it pretends to be said door opener.

There's often a pair of pins on the internal board that you can attach a relay to. Shorting the pins causes the door to close.

That sounds even dicier than modifying the wall switch, but sure :)

There is a part of me that wants to break the damn thing open to hunt for a 3.3V line so I can power the ratgdo without a USB PSU...

bummer! i had no idea it wasn't just a dumb switch! also super cool that they reverse engineered it. :)

My garage doors (purchased within the last year) have "regular" buttons / car remotes to open them, myQ was 100% optional. I basically use it as a way to alert me when the garage door opens (someone just came home, amazon is doing that semi-weird in-garage delivery thing, etc)

Here's the company's statement, which they've updated to accuse HA of, basically, DDOS: https://chamberlaingroup.com/press/a-message-about-our-decis...

Even if we assume that's true (I very much have my doubts), this is a totally self-inflicted problem as a result of bad design: there's no reason a garage door opener should rely on a remote server instead of local communication.

You don't even have to go so far as saying they should change the embedded software. Here is the problem:

The MyQ integration was introduced in Home Assistant 0.39, and it's used by 3.1% of the active installations. Its IoT class is Cloud Polling.

"Cloud Polling", meaning they don't have a way for an API client to register for state change callbacks. I'm sure this is why there is so much traffic - if Home Assistant wants to support triggers based on state changes (eg door opening, turn on home lights), then it needs to repeatedly check the status so that it becomes aware of the change in a timely manner.

(Personally I only buy/use devices with local control, and generally cut them off from Internet access. Just saying though)

If it's not on a remote server, then how would you know when people leave/arrive at their homes? You'd miss out on so much sweet, monetizable personal information. Won't anyone think of corporate profits???

Perhaps they updated the statement since then, but they're not accusing them of "basically" DDOS: they literally say DDOS now. Which of course prompts the question: is the problem that the CTO doesn't understand what DDOS is, or are they intentionally painting HA as malicious somehow?

TBH, that's better, as that is a problem that could be fixed. Even if we had to switch to a tilt sensor and just retain control, that'd be much better than their approach.

IOW, this real reason is better than their dumb comment about "unauthorized use".

As they themselves admit in that statement: There used to be an official way to integrate locally, but they discontinued it (myQ Home Bridge) and they're hard to find today (inc. huge markups when available).

can we just make non-sens like that illegal

no one has time for it

you bought the device you should own it

it's not even anything fancy where you could argue that continuous software updated need to be done or similar

also pass a law that all smart home devices had to go through a hub, no direct internet connection allowed, uh put it under "reducing DDOS potential due to long term issues with internet connected smart home device security"

all smart home devices had to go through a hub

I fully agree, this is the reason I mostly buy Zigbee devices for my smart home. The problem with this rule is that there is already a device on the market that complies with it on paper, but not how you intended: Amazon Echo devices act as Zigbee gateways. While I never tried it, I bet it will not turn on your lights without calling the mothership.

If this rule were to become reality, vendors would just sell your their "mandatory" hubs that handle the calling home part. Smaller vendors would no longer be able to offer their ESP based devices, even though I can easily decloud them via ESPHome etc, if even necessary.

From a purely idealistic PoV, I guess the only way we achieve ownership as you described is if we require by law, with proper enforcement, that reasonable technical people are able to connect to the device on a local interface. But this has so many weasel words already, it would be ineffective and/or lead to regulatory capture ("implement this 600 page, 200$ ISO standard based on XML, don't mind the proprietary extensions ensuring no interop!").

For me, the way to have some degree of ownership of my smart home is doing research before buying to ensure the device either runs on Zigbee, has a local network interface and does not rely on the cloud even for initial configuration or can be flashed with Tasmota or ESPHome with minimal fuzz. I don't see this changing any time soon. It is sad that you need to have the knowledge and time to be able to "own" your smart home, but I at least can help my "tech support circle" where possible to make informed decisions.

If this rule were to become reality, vendors would just sell your their "mandatory" hubs that handle the calling home part. Smaller vendors would no longer be able to offer their ESP based devices, even though I can easily decloud them via ESPHome etc, if even necessary.

No, what should become the reality is that only HARDWARE vendors that make a living off the hardware and some corollary service will have the incentives to be on the market, instead of the behemoths like Amazon or Google that just want to harvest your data with mostly loss leader products.

Yeah, I agree that this is what SHOULD happen. But I am far too cynical at this point to believe it WILL happen.

In our current system I see two ways to try to make this reality: 1) economic factors and 2) regulation. 1) will not happen, because the data is worth enough to big players that a small competitor can not compete on the hardware/software/service margins alone. You need to become as big and integrated as the current players to be able to offer similar features and prices. Sure, it is more choice, but the option is just as bad.

2) will not happen due to regulatory capture problems as I already stated. A big player can shoulder the burden of compliance easier than a small shop. Maybe, just maybe, there is hope if anti-trust actions split up the existing big players, but I am not holding my breath.

The third way, one small group of indomitable Gauls^Wnerds still holds out against the invaders, is what we currently have and what offers a little bit of hope to me. But I fear this will never become the norm.

I use (or used, I mostly have Lightwave switches instead of zigbee bulbs now) one of my Echo devices as a gateway, and sure it will call the mothership, but I really don't care about that as long as the switches and other devices themselves still works if/when I decide to tear out the Echos. To me they're not a problem, as long as they speak open protocols.

I think that part is more important than demanding a hub. Demanding that the device can connect to a local hub (where "can" means "can easily be reconfigured without going through the original manufacturer or requiring expensive tools"...) speaking open protocols (and specify clearly what "open protocol" means, to avoid your 600 page, 200$ ISO standard) is more important than requiring that they must connect to a local hub. Also necessary to specify that you can carry out all the functions of the device via open protocols, or you'll get bullshit where essentials get locked away.

Personally, I don't care if I have proprietary smart home devices. I do care that the maximum cost and hassle if a manufacturer goes "rogue" like in this linked article remains low. So each proprietary device in current use reduces my willingness to get another one. Currently, all of my devices can be controlled via open source, and though some of them (some cheap Govee led strips) do call home, there are open source to talk to them, and worst case I can literally cut them off with a pair of scissors and replace the controllers for a pittance if they ever become a nuisance, and that makes them an acceptable choice (though whenever there are multiple options I will look for the more open one).

also pass a law that all smart home devices had to go through a hub, no direct internet connection allowed, uh put it under "reducing DDOS potential due to long term issues with internet connected smart home device security"

Assuming no authentication/encryption/intentional obfuscation shenanigans (which would need to be covered), I don't really care if it is forced to go through a local hub if only they were required to provide an easy mechanism for pointing the device at a local network endpoint.

The problem is it's routed through a central server.

all smart home devices had to go through a hub

I think ultimately this is the only way to get it to even work properly, let alone last long enough that the next purchaser of a smart home can use it reliably. But it will also slow innovation and Big Tech will hate it.

Any IOT device that requires the cloud for functionality is a trap.

I bought a Miku baby monitor specifically because of the 2 devices that offered a feature I wanted, Miku had no subscription fees. And they advertised that they never would. It cost $400.

Then they went bankrupt and during bankruptcy they sent out a proposal to start charging for previously free features. Then they retracted that proposal. Not sure if the judge shut that down, or what happened. But then they sold to a company conveniently created the day of the sale.

Within a month the new company forced out an over the air update that disabled most functionality until you pay them $10 a month (they went bankrupt in the first place because they did a normal over the air firmware update that bricked every single unit and had to replace them all).

Last time I checked they were still being advertised on Amazon as being subscription free.

Honestly I think we need regulation to force companies to purchase a bond to provide basic security and support for any IOT devices they sell for some number of years from the purchase date. I don’t see any sign of the market solving this anytime soon.

I had an internet connected baby monitor. In the end we decided to just get a local RF one and it is a far better experience. Pair it once, and it just works. Lower power. Very reliable. Coverage throughout the house without issue. No apps to crash in the background. No dropped streams. No needing to log in to the app. No worries about features getting taken away. No subscriptions. No having to send data out to the cloud just to pull it back down. Lower latency. Far easier to just hand the display unit to the baby sitter instead of trying to talk them into installing an app and sharing a login.

These days the local RF ones are very solid. Modern DECT-based systems use encryption and frequency hopping so once paired you're not realistically going to get someone listening in.

The only benefit I see for these cloud connected cameras is if you're out of the house and are going to check in on the baby sitter, but in the end I'm not even a big fan of that feature. There's tons of pros for the local RF ones and few negatives, and mostly a bunch of unknowns and concerns with the cloud ones.

My wife works nights and she likes to be able to check in occasionally. It’s also got a millimeter wave radar that shows a breathing graph.

My wife is a pediatric ER doctor and she thinks the breath tracking radar is stupid, but I like to be able to look over and see the graph because I’m a crazy person and otherwise I’d zoom in on the camera and stare at it until I see movement.

I recently bought a baby monitor - or more specifically, spent a couple hundred € on Ubiquity hardware - two cameras, NVR/host, and a PoE switch - and made one myself, because that's the only way I know of (after serious research and asking on HN) one can buy a wifi-enabled baby cam in Europe, that doesn't route video through some sketchy cloud. Baby cam vendors, fuck you all very much.

Sounds like bait and switch to me, which is illegal.

You can report this action to the ftc https://reportfraud.ftc.gov/#/

Especially that it was a new company deliberately disabling the devices, it sounds like a straightforward criminal CFAA violation. Of course, such laws are really only for persecuting little guys doing uppity things like trying to make scientific knowledge available to the public. Even if you could convince any six-degrees-of-golf-buddies prosecutor to take the case, I'm sure the malicious crackers have some fake contract to hide behind that claims a transferable right to remotely destroy your property.

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 that phones home by default, but can be converted to local only, dumb mode that works fine with Home Assistant [1] with a tiny bit of soldering. I use these exclusively without problems, even the one I rooted for my parents works without any maintenance.

[1] https://paulbanks.org/projects/lidl-zigbee/#overview

Zigbee in general is great. If you want the more expensive stuff, Philips is the leader in that.

And now that Matter support is slowly trickling in, they should all be fully interoperable. Currently it's touch and go if a Ikea bulb works well with the Hue hub for example.

It’s not the same as MyQ here, but Philips (specifically Hue) recently pulled a similar move around requiring accounts. Thankfully it’s not as big of a deal for the HA crowd because the lights can be controlled directly via zigbee, but it certainly caused a kerfuffle in their ecosystem.

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.

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.

You don't have a choice...all of the major garage doors are supplied by one company (Chamberlin Group)

We understand that this impacts a small percentage of users, ...

Wow, what a contemptuous statement.

I have news for you, Chamberlain Group. You are not only alienating, being hostile and losing a "Small percentage of users" (most companies would prefer to call them "valued customers", but I get it). You are causing an enormous permanent damage to your own brand.

As much as I want this to be true I kinda doubt it. People who install and configure home assistant are far and away niche users. Almost everyone with one of their products will just use a physical clicker or pair it with their car directly.

These specific niche users are the geeks that all relatives and friends ask what to get.

This is the own goal that Intel did with their Pentium FDIV bug. They were absolutely correct that it only impacted a small percentage of users. They still ended up losing their shirts over the problem.

One extra step I’ve learned to follow is to verify if needed, could the hardware be permanently redirected to a local server, and worst case reflagged with a different firmware or it can be redirected to remain local. The latter is sometimes easier if it’s a Tuya based device, which a lot of these unknown devices are.

https://github.com/make-all/tuya-local

One of the main things these “smart” devices do is use your internet connection. It’s wise to create a dedicated _IoT suffixed wifi which can’t access your network or devices, but at the same time your other devices can ping them.

How?

This is a pretty solid guide of a home network setup here. It can be running a $50 EdgeRouter X or translated to other devices.

https://github.com/mjp66/Ubiquiti/blob/master/Ubiquiti%20Hom...

Edit: comments below have additional info on Tasmota and ESPHome

https://github.com/make-all/tuya-local

Just a small warning: make sure to check whether your device needs to be added to the Tuya cloud to get a local API key. I was only able to get "my" lamp working locally after registering it via the app and creating a developer account.

Another option can be flashing it with Tasmota: https://tasmota.github.io/docs/Tuya-Convert/

Thanks for that clarification, I also couldn’t remember the name of Tasmota.

Another option can be flashing it with Tasmota

ESPHome is also a good option and makes Home Assistant integration easier.

Something that I don’t see people talking about here is that MyQ is the core/required integration component for Amazon Key in-garage delivery, a service used by millions of people to have their packages delivered to their garages instead of having them stolen off their porch. That’s why it needs Internet access. All the talk about how Chamberlain will go bankrupt because a comparatively small number of tech people stop using the product is fluff. I ran into the MyQ API problem with Homebridge a couple weeks ago, and I bought a unit from Meross that integrates directly with Apple HomeKit. I still have the MyQ installed because I _need_ it for Amazon deliveries. Yes, all the fury about ads and user hostility and probable polling requiring extra resources with no recompense is correct and justified. But at the end of the day, Chamberlain doesn’t care if they piss us off. They get all their money from the same people who think their phone screen is _supposed_ to be covered in ads on every page they visit, and they likely get TONS of money from Amazon.

Something that I don’t see people talking about here is that MyQ is the core/required integration component for Amazon Key in-garage delivery, a service used by millions of people to have their packages delivered to their garages instead of having them stolen off their porch.

Would be nice if this functionality could work with arbitrary openers via webhooks. You could even have a fancy auth flow that you trigger from your smart home dashboard so users don't have to know or care how it's implemented under the hood.

Somewhat off topic but it is quite stunning to me that American carriers just leave the package at the door. I lived in different European countries and in all of them the expectation is that the mailman (official mail, or any of the services like dhl, ups, etc) will ring the bell. If you don't answer they will ring the neighbour and then take it back and either try again another day or you can go to a pickup point. Instead the U.S. has an entire category of devices to avoid package theft when the solution lies in holding carriers to account. I don't want to open the garage for Amazon or Bol or any other delivery company...

Aren’t garage door button just simple momentary switches? So use an aftermarket “smart” remote or button?

Not with newer openers - they speak a serial protocol to the opener.

Oh wow, what a pain in the butt.

Chamberlain sound like dicks but to be fair, when we're talking about remotely opening doors that give access to people's houses, it seems fair enough IN PRINCIPLE for them to restrict access to the API to 'partners' and for them to have some sort of payment and maybe even approval process around who becomes a 'partner'. Obviously that sucks for open-source projects that can't afford to pay up. But it seems fair enough to put some payments or approval processes in the way here.

And why does it seem fair enough? The garage door is mine, not Chamberlain's (although that starts to be more and more debatable the farther into enshittification we go).

I built my own HA integration with a tilt sensor and a relay to trigger the button. I have a camera on the door, I wonder if I can use that to validate the switch.

I normally leave it disconnected from the switch because I don’t need to open the door remotely and I am afraid that some exploit will have a Russian 13 year old opening and closing my door at 4am.

I have my Home Assistant completely local, if I need to access it from outside, I open Wireguard VPN to my local network and do my business in Hassio locally.

I felt silly at first complaining to my wife I couldn’t get myQ working again, thinking I did something wrong after adding an automation. We tried to open the door (remote via hass) for my son when he got home but it didn’t work. Obviously it was something I did?(nope)

Then I watched the discussion on discord and realized I’m not alone albeit still a small percentage.

Then I see this as top post on hn.

It’s frustrating to have a company do this. I don’t agree with their choice. Plus forcing you to see ads whenever you open or close the door is Orwellian.

Now I need to somehow sell this device on eBay with hopes a large percentage still wants it.

It does suck, but can you still use it remotely via the myQ app?

They can lock you out of the API, but they can't stop you from installing hardwired devices that simulate a press of the open/close button.

I just chucked my MyQ device and replaced it with a Meross MSG100HK--it works perfectly and natively with HomeKit--no cloud service required. Incidentally, the latency is much lower too.

The device is basically a wifi-enabled, USB powered "dry contact" switch. You connect the pigtail in parallel with your existing wired open/close button. There's also a magnetic sensor (similar to what old door alarms used) that goes near the door to verify it has closed.

That Meross opener is rock solid. I've had one for almost two years now controlling two doors. Even with a marginal wifi signal it always just works.

Homebridge + HomeKit is also an excellent middle ground between Home Assistant and HomeKit alone w/o having to go with some cloud-based solution.

For example, I wanted my garage door to automatically open and close as I leave and arrive in my car. Here's how I did that.

I have a pair of dummy switches in Homebridge. One of those tracks the state of whether my phone is in CarPlay mode or not. I do this with a Siri Shortcut on my phone that toggles the "CarPlay status" dummy switch when my phone enters/exits CarPlay mode. The second dummy switch triggers my garage door to open/close whenever the dummy switch turns on/off. This is a work-around for the opener itself being a secure accessory which HomeKit won't operate w/o the phone being unlocked. The last piece of the puzzle is a HomeKit location-based automation: if my phone leaves my home location and the "CarPlay status" dummy switch is on, then set the garage door dummy switch to off; if my phone enters my home location and the "CarPlay status" dummy switch is on, then set the garage door dummy switch to on.

I drew the home location as tight as possible around my home. The door opens just as I'm pulling up to my home and I see it close just as I'm leaving.

As to why I don't just use the CarPlay garage door button: I mean, why automate anything? Also, if you have multiple garage doors, there seems to be no rhyme or reason to which door CarPlay gives you the button for.

As to why I don't just use the button on my rear view mirror: Again, why automate anything? My mirror also has 3 buttons and it's easy to accidentally press the wrong one.

The reason they caused that much traffic is because Home-Assistant has no other way of finding out the status.

If only there was a LOCAL way. But I can't poll the device locally. I can't send it commands.

Good news: you can now, I just installed it and it was easy and fun. https://github.com/PaulWieland/ratgdo

But it is external to the device, you're right :) And for some crazy reason this guy is getting a lot of orders recently ;)

Chamberlain Group products now officially on my blacklist. They join the ranks of Rivian, Tesla, any QVC marketed product, and social media (IG, FB, TT, …) marketed junk.

I had a Z-Wave garage door opener which was wired to my old garage door opener's button switch port. The old unit's logic board started having issues, so I went ahead and replaced it with a cheap Chamberlain. I got the most basic unit thinking the one-button opener would be a basic switch style like old, but alas it is still some kind of serial connection. The Z-Wave controller can't effectively signal to it, but since it has a basic tilt sensor it can at least open the door state.

I'm thinking I'll just get a cheap garage door opener remote, solder the trigger pin to the button on the remote, and tape that to the ceiling next to the z-wave controller. Janky, but at least I'll be able to get it functional again to send the command.

Great to know which vendor I will NOT be buying from.

A gentle reminder that the Security+ and Security+ 2.0 RF protocols have been reverse engineered (https://github.com/argilo/secplus). While they are not the most secure thing in the world, you can build a custom RF transmitter (remote) that is network connected.

Having done some research into Chamberlain's products, I don't recommend anyone to use them if they have the choice.

Could there be a suit against them over this? I bought one explicitly for home automation, and it seems them disabling it turns that into some sort of false advertising

I had this vision long ago with household appliances (from different vendors) waging war in our homes. Looks like we've finally made it there.

The solution seems pretty clear - buy a 3rd party opener OR use a different vendor that does play nice.

I have a meross garage door opener that uses homelink (a standard that virtually ever garage door opener supports) to open/close the garage door with a sensor on the top of the door to detect when it's open and closed. It was $49. That's cheaper than myQ addons for chamberlain. It works with google home, ifttt and home assistant. (I have reminders set if the door is open for more than X minutes and if it is still open after a certain time of day).

Having to have "yet another app" (myQ) installed just to use a garage door is pretty ridiculous - if you're a power user you should understand the folly of using unofficial integrations and as an unofficial integration provider you should know you're walking on ice.

There's a key point on the data-mining-cloud-only route Chamberlain is taking: they were acquired by Blackstone a couple years ago [1], so not "family owned" anymore [2].

No doubt they want to exploit that data and begin integration with all their shady Real State business [3].

Their new CTO/Executive VP says in one of their PR news: "With Blackstone’s partnership, we will capitalize on new market opportunities". And a Senior Management Director says "...unique opportunity to build on its leadership position at the center of housing and e-commerce megatrends (...) expansion into connected homes, businesses and communities" [4].

Very alarming in times that big owners are trying also to force biometric data collection in their buildings (see Atlantic Plaza Towers) or are blindly giving information to agencies (see Amazon Ring cameras and the likes).

Now, the rant:

Of course, with one hand the CEO is donating to buy his name in institutions: "There is a Stephen Schwarzman building at the New York Public Library, a Schwarzman centre at Yale University and the Schwarzman College of Computing in Massachusetts. Soon, the University of Oxford will open the Schwarzman Centre for the Humanities, funded by the largest single donation it has ever received." [5] and the other is receiving billions from universities like UC to speculate in real state [6].

One would say it's curious how Schwarzman creates a huge publicity stunt with "biggest single donation 'since the Renaissance'" (£150m) [7], but why would be important to donate to Oxford, when they have almost £8b in endowments... [8]

  1: https://www.blackstone.com/news/press/the-duchossois-group-completes-saleof-chamberlain-group-to-blackstone/
  2: https://www.wsj.com/articles/blackstone-to-buy-chamberlain-group-11631019601
  3: https://www.theguardian.com/us-news/2019/mar/26/blackstone-group-accused-global-housing-crisis-un
  4: https://www.prnewswire.com/news-releases/chamberlain-group-adds-top-tech-leader-dan-phillips-as-cto-to-accelerate-companys-technology-transformation-301744538.html
  5: https://www.theguardian.com/business/2022/sep/29/blackstone-rebellion-how-one-country-worlds-biggest-commercial-landlord-denmark
  6: https://www.latimes.com/business/story/2023-01-20/university-california-blackstone-real-estate-fund-housing-prices
  7: https://www.theguardian.com/education/2019/jun/19/oxford-receive-biggest-single-donation-stephen-schwarzman
  8: https://en.wikipedia.org/wiki/List_of_universities_in_the_United_Kingdom_by_endowment#Endowments_over_%C2%A31_billion

+1 home assistant -1 Chamberlain

You would think a company would like to negotiate and be seen by a community as a positive company. I would not buy a product from them on principal after their statement. myQ could have engaged the home assistant maintainer and worked out, less API calls or something.

On a side note, i do love my home assistant, but ANYTHING that has to do with entry into my house is not and will not be automated, garage doors, door locks, etc. However that is my personal paranoia talking.

I'm in the market for a garage door opener, incidentally. This narrows down my options, so glad I hadn't bought one yet - there's a chance I might have ended up with a Chamberlain if I had. Out of the question now!

Sigh. I'm otherwise perfectly happy with my Liftmaster openers. As long as HomeKit continues to work (and it should; I don't allow the bridge access to the Internet), I'm still happy. I did buy a ratgdo device as a backup, however. And when I buy new openers at some point off in the future, Chamberlain is off the list.

Parallel discussion: https://news.ycombinator.com/item?id=38188614

I wrote the below in another post on this topic:

They never technically allowed it in the first place.

Homebridge and Home Assistant used a popular Python library that reverse-engineered the MyQ API from the Android app. Many companies couldn't care less until abuse ramps up, but given that Chamberlain (Blackstone-owned) has gone into rent-seeking mode all of a sudden (or an incident happened that they won't disclose but prompted them to take a hard look at this), they decided to turn the Cloudflare Super Bot Fight stuff way the hell up on their OIDC token exchange endpoint (you can still request auth codes).

I decided to abandon trying to get MyQ to work with Home Assistant (it would have required hours of trying to figure out what combination of headers would have passed the CF checkpoint) and ended up getting a Meross Smart Opener. It was shockingly easy to install (plug the relay device into the same pinouts that your wall door opener uses) and works even better than MyQ (in that you won't get a weird "close error" that prevents you from operating your door that not even MyQ customer service will clear)

---

I still use and recommend MyQ, however. The Amazon Key and Tesla integrations work great. If they had previously allowed API access but then rescinded it in favor of "providing a better experience" like Reddit is doing, then I'd feel differently. In this case, however, it feels like we took advantage of a backdoor for a long time and the club decided to finally put a lock on it. Shitty, but reasonable.

The next big one to watch out for is Ring.

Ring does not (will not?) support HomeKit. Lots of folks (myself included) have resorted to using Homebridge or Home Assistant as an alternative.

Both are using a library that reverse-engineered Ring's API (though Ring engineers supposedly contributed to it).

While the Homebridge plugin simply exposes device statuses and metrics and RTSP feeds for the cameras, Koush's scrypted NVR platform enables HomeKit Secure Recording for the cameras, which allows more adventurous users to skip paying for Ring Protect ($10/mo)

While I get a lot of value from Ring Protect and will continue to pay it, I really hope Ring doesn't decide to "improve the user experience" for us like Chamberlain did. I'd be really sad if that happens, since HomeKit is amazing and is much better than having a million apps on my phone that don't talk to each other.

I have one of these garage door openers, and their MyQ software is absolute garbage. I set up Home Assistant specifically to avoid it and now they've gone out of their way to break that.

I' absolutely pissed - I just called the folks who installed my garage door and explained the situation to them, and recommended that they look for a different brand for anyone that wants wi-fi access in the future.

It's hard to emphasize how different the mindset of the late 2000s Internet is to nowadays.

APIs were more readily available and open. Mashups were usually encouraged, so long as you didn't generate undue stress.

Nowadays its a million tiny business silos hoarding tediously-obscure-but-still-sometimes-useful data. And you have to prove that what you want to do with the API doesn't infringe on their ability to capitalize on it better.

The irony is that all the data is way more easily accessible from a technical POV now due to the prevalence of SPAs and REST, but the legal environment is significantly more dangerous.

Honestly smart features in large/permanent appliances is something I explicitly avoid these days. The majority of smart home products I’ve bought over the last ten years have been somewhat disappointing if not outright rage inducing. I don’t want that in something that is difficult or expensive to replace.

I sort of have to assume in the case of large appliances that the manufacturer will drop support for it well before I want to replace it, and that if there is any sort of functionality fully gated behind an app, that it will become unusable to me at some point when I reset my phone and discover they’ve unpublished the app from the store.

I’d much rather buy a dumb garage door opener and bolt on that ratgd device mentioned in this post, than be beholden to the manufacturer’s whims and invariably godawful garbage horrible no-good app.

Not sure if related or not but I literally just an email informing me that Hive will remove their IFTT integration next month…

I've had nothing but bad experiences with Chamberlain in IoT integration discussions. I have since replaced all garage door openers I own with Genie/OHD.

The gnashing of teeth here reads like software people trying to solve a simple hardware problem.

You don't need anyone's permission or API to control any garage door opener --- smart or dumb. The suggested "ratgo" device is one option but looks kinda overpriced to me.

Every garage door opener has 2 sets of dry contacts. One set controls the open/close function and normally connects to a physical button on the inside wall. This is easily shared with any other device. The other set is a limit switch that tells the motor to stop once the door is open. This too can be easily shared and read.

All that is required for full control is a wifi device with 1 output and 1 input that speaks Home Assistant. Sonoff or some other manufacturer must have an affordable one. If not, maybe I'll make one. It's not that hard with readily available hardware.

The Homebridge integration is also, obviously, broken.

I'm not clear if people are really replacing a physical something here, but if you have an old smart home device which sucks, be sure to put it up on online marketplaces.

List it cheep along with a warts and all discussion of it's problems. Means less waste as there's always someone who'll want it, people who are looking for the product hear about the limits upfront, and the company actually gets a real loss from you leaving (assuming it sells to someone who might have bought a new one).

Plus it's fun to try to convince enquirers why they shouldn't buy your item

Having been impacted by something similar (company changing their cloud and breaking my HA integration), I think that when companies do this, the least they could do is offer refunds/buy-back to impacted customers.

In my case, I bought a slightly-inferior product specifically for its HA integration; now that it's broken it's just an inferior product...

That's why all of my installed IoT devices are either custom-firmwared or can be as well as configured to be not "dialing home" to some nosey data collection and aggregation center.

I wish I had known about ratgdo a few months ago. I spent a month trying to get a Meross smart garage door opener add on to work with the chamberlain that was already in my home, only to realize that the button was using some kind of obfuscated signaling, not just connecting the circuit. I ended up soldering a pair of wires to the button on the board in the button unit, and then connected my smart home stuff to those wires; worked like a champ. F** you Chamberlain; try blocking that.

I never bothered with the myQ bit and instead sacrificed one of the garage door opener remotes by wiring the button up to a relay (z-wave by Zooz) that I zip tied to the scaffold. It's worked great for the past 4 years in Home Assistant.

Another one on the shame list. You can use the public api, but only if you send your local data through our dogshit online channels, so we can sell it later

https://paulwieland.github.io/ratgdo/ is a home assistant compatible board that emulates a garage door opener. It adds local control and is easy to setup.

Received my ratgdo yesterday and uninstalled the myq app. They won’t be getting any more traffic from me

I’m recently in the market for a garage door opener I can automate (specifically close automatically after X time open) - does anyone have recommendations or is ratgdo the way to go?

Also I understand one of the reasons this isn’t a standard offering is because garage openers have a hard time not crushing things? Kind of surprised me.

The ratgdo says it work with “dry contact”… what does that mean?

I use HomeBridge but have also been noticing connectivity issues recently. Just ordered two of those Ratgdo devices, thanks. Sounds like a better solution anyway.

Not at all surprising to me. Recently I got 3 new LiftMaster garage door openers with the built in cameras. Over the course of a few months the HomeLink connection to the box supplied remotes stopped working, never worked syncing to (multiple) HomeLink transmitters in vehicles, and the installer cited "supply chain issues" when I wanted a replacement. The only thing that worked was the MyQ app which was less good than just pushing the button. And of course the video for the cameras only worked with a damn SUBSCRIPTION after 30 days with no way to integrate them with a networked DVR system.

Just one of the most awful customer hostile products I've ever wasted money on.

I surmise part of the reason they did this is to protect revenue from "authorized" partners. I'm sure these partners are not happy paying money to Chamberlain so their customers have access to myQ while other unauthorized partners get free access.

Burglar App:- Drive up, open door, drive in, close door, load up, open door, drive out, close door = clean getaway. Advertise to burglars at top of screen....

I wonder if there is a device that just taps into the open/close wires, with a sensor that will optically detect the distance along the track of the highest roller of the door, and attaches magnetically to the track. This solution would have first-class home assistant support and work across all door openers.

ratgdo[1] is close.

[1]: https://paulwieland.github.io/ratgdo/

We have nutriscore labels, excessive sugar labels, "smoking kills" labels...

Why not "This device does not support local cloudless control" and "This device does not allow 3rd party software access" labels too

Garage opener is a 10+ year device, expecting the company/cloud service to survive for that long and still be supported is too optimistic, but local control will still be usable, even if some 'adjustments' are needed.

I own a MyQ garage door opener and this is infuriating. We would be so much further along in home automation if companies were mandated to produce interoperable devices. Every appliance should expose its controls, events, and state in a standardized manner.

I don't know what such a mandate would look like. I just know that we're at least a decade behind where we should be because the market isn't getting it done.

Once they broke Google Assistant integration, I decided to replace them and never use any of their products again. I use a lot of connected devices and this is the only company that has gone backwards in terms of interop over time.

I usually check up compatibility with Home Assistant and if the service is cloud or if it can work locally. If both check, they have a new customer, otherwise, there are plenty of brands and products out there.

Protest with your money, buy from others, the sooner the hardware companies realize this is a stupid move (locking down), the sooner we'll have better integrations.

LOL. I have Chamberlain garage doors, and paid $30 for an Athom ESPhome preflash kit that includes a box, power supply and reed switches. Works great.

If there's one thing I'm dedicated to now, it's that all of these custom cloud IoT things are transient user hostile junk. If it's not open source and in my control, then it's not mine.

[dupe]

More discussion over here: https://news.ycombinator.com/item?id=38186303

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

I don’t understand how the MyQ app has such a high rating in the App Store. 4.8, 1.5M reviews. It’s so bare bones, no shortcut support, (obviously) no HomeKit, no widget, literally nothing to make the use easier or more convenient.

To make things even worse, first position above you devices is an ad (for their other devices) and it periodically suggests that I connect it to Amazon so some random people delivering packages have the power to enter my home.

Genuine question, how?????