> 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 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?
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.
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.
It happens all the time, no tech required, any time someone is foreclosed on.
I agree it's wiser to avoid such situations but a lot of people end up delegating this kind of responsibility. If enough of them end up burning their own fingers, that could go badly for a provider. Even if frivolous lawsuits weren't a thing, a spate of ignorant but angry social media posts could be very damaging.
Again, I'm not saying I necessarily have a solution or that hardware owners should have hurdles placed in their way. I'm just pointing out that in some ways the provider may be damned in one way if they do and damned in another way if they don't.
I suppose the IoT sub-sector will end up in similar proportions to other, older tech: Some vendors, analogous to e.g., Red Hat or Linode, will specialize in catering to enthusiasts / power-users and have fairly noncommittal / at-your-own-risk / no-warranty license agreements. However, if the past is any indication, most people will end up doing a lot of business in walled-garden analogs of Apple or Facebook.
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.
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.
Unfortunately it's not actually that different in effect -- Nabu Casa proxy the encrypted TCP connection, rather than terminating TLS and proxying HTTP, which is great for privacy but not so much for providing an extra layer of security on top of HA itself.
It is also much easier for those without easy access to extra static IP addresses. Given the target audience I think it's probably the right approach.
I don't think it's entirely devoid of security improvements---you need to know the webhook address in order to get access to talk to a HA instance which would be a lot more difficult than just port scanning for an open (perhaps unpatched) HA instance on the open internet. I would still prefer it though if things would expose a local API or speak MQTT however.
Open a TCP connection from the instance to the cloud service. I don't know about all consumer routers, but I just checked mine and the default TCP established timeout is 7440 seconds. Idle timeouts are supposed to be at least 2 hours.
If you served the entire US (130 million households) and had a 1 hour keepalive, that's only 36k packets per second, which is nothing.
You could also auto-train the idle timeout by using a pair of TCP connections. One uses a known good value while the other probes upwards until it finds its connections start getting closed (with some optional binary search fanciness), feeding new known good values back to the first.
MQTT is the solution for this. Note that the garage door openers talk MQTT to the myq service (over TLS with preshared keys). It should be possible to subscribe to events from your garage door opener(s) and also to send commands to it.
but MQTT alone doesn't solve the challenge for some Internet server to push messages to a Home Assistance instance running inside a home network / behind a router / behind a firewall / NAT unless a port is opened on the router, or long-polling is used.
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.
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.
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.
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.
That’s definitely the high road solution. The low road solution would have been to start suing HA users under the CFAA. So I guess they took the middle road.
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.
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.
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.
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!
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".
* 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
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.
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.
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.
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.
If your mass-market commercial product needs this by design, you will fail. To successfully sell a product to the general public, it must work out of the box.
They exist, but they're expensive. And the products they sell are not really consumer devices, they are B2B products marketed at contractors.
They're really two different markets, the bulk of the home automation market doesn't want to spend $10K+ for a contractor to check the same feature boxes that something on the shelf at Home Depot can do for a 3-digit price tag. Labor is really expensive, so home automation contractors operate almost exclusively on the high-end of the market.
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
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.
> a consumer has to trust a third party who may have incentives that don't align with their own
That's true for literally anything, not just IoT security and privacy. I mean, even for highly technical users, one can't do everything from scratch, nor even check and control every single aspect: you gotta trust the the computer hardware or OS you're using isn't backdoored, you gotta trust the people that built the place you live in didn't put half the rebar actually needed or wired the whole thing backwards or with thinner-than-required wires, you gotta trust that the food you eat isn't going to make you sick...
Same for HASS, one could delegate trust to a specialist that would install a HA Green or Yellow box for them, just as they do for electrical wiring. HA is only "third party" because the IoT place lacks standards but is in essence no different than wiring stuff from different vendors, where "myriads of decentralised solutions" exist only because of standards, and for which decentralisation essentially means everyone is a third party to everyone else.
So I don't think dismissing HASS as third party is fair, and wiring IoT with virtual wires is no different than wiring a breaker box. If you don't know how to do it it can be dangerous, and so you delegate and trust someone to do their job properly.
> 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.
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
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.
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.
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.
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.
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.
> Why in the hell does a garage door opener need a server?
Because the user is almost certainly installing the device behind a NAT with a dynamically assigned public IP. These are mass-market garage door openers, not devices targeted to those familiar with advanced network configuration.
I also avoid cloud connected IoT stuff. I have the luxury of doing so because I have IT skills. For those who do not, accessible alternatives simply don't exist.
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.
> - 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?
> 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.
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".
Yeah -- it is certainly quicker to use the keypad that I have outside the garage door than try and use their app. In particular, it keeps asking me for a username and password (which I can't remember because who remembers 16 character strings??).
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.
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.
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..
any home IoT solution without a cloud inbetween and which shall also be able to communicate with you while on the go requires a lot of technical expertise (and perpetual maintenance...). It is therefore not viable for the mass market.
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.
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.
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.
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.
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.
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.
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?
> 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."