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.
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???
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)
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).
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".
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"
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.
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.
> 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.
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.
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.
> 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.
> 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.
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.
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.
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
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.
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.
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.
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
> 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.
> - 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?
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.
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??).
> 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.
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.
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.
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.
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 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.
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.
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.
Why not simply allow HA to integrate on site rather than to have to go through some crappy service that likely will not last the lifetime of the doors in the first place?
I'm not saying owners should be completely barred from modifying their systems but there are security implications to bypassing their centralized / cloud-based authentication.
It'd be possible for a knows-enough-to-be-dangerous customer to modify their system in such a way that they unwittingly allow unauthenticated local access. From my point of view, Chamberlain/MyQ should be totally indemnified in such scenarios but I'm not sure how murky the legalities would be in terms of getting judges/juries to accept "caveat emptor".
EDIT: Maybe there's a way to ensure customers have signed an indemnification agreement before unlocking local API access? I guess there'd also need to be a way to ensure/promote a factory reset if/when ownership/rentalship changes.
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.
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.
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'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 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.
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 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.
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?
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.
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 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.
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.
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.
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.
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"
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)
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).
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 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.
Professional escrow is not cheap. The first year, when you have to demonstrate a complete build and 'bring up' process with them the price seems pretty good as it's a lot of work. Funnily they don't seem to offer a multi year deal.
The second year there is much less work but they double the cost. You go along with that as it takes a lot of work on your part to engage a new escrow firm from scratch.
The next year they double it again. It's still demanded by your large corporate customers and you try to pass on the costs but they don't want to pay it.
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.
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.
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.
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.
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).
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.
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
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. :(
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.
I remember reading about someone who could not brew coffee anymore because the cert on their "smart coffee maker" had expired and the business had gone under.. they discovered that by attempting to use wireshark, of all things, to take a peek. I thought "this moment right here is where people will catch up to it, no way we can go even further".
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
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.
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:
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.
I did the same with a MHCOZY Zigbee dry contact relay and two Aqara door/window sensors. I use the dry contact relay for two doors, and have two more channels to use for other stuff if I need to.
Additionally, I tried using an Aqara vibration/tilt sensor for more accurate "partially open" status reporting but it was a) not sensitive enough b) too unreliable c) too slow to update. I guess it's more meant for detecting impacts or falls.
I've also toyed with the idea to mount an ultrasonic distance sensor at the top of the (rolling) door, which could measure how far from the ceiling/far wall the top of the door is, but it'd be pretty bulky and problematic to power mounted on a moving part like a door.
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.
> 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).
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! ;-)
83 rps would be a challenge when hitting a Java EE app written to make use of tutorial-level ORM code without any caching or optimizations. An app where a request takes 300ms to resolve (pulling numbers out of hat for an average poorly written Java EE app; ignorantly assuming 300 ms are spent with 100% CPU utilization of a single core), would require a 24-core machine to keep up with 83 rps. Accounting for some peaks in usage (how about 5x around 7-8am?), 400 rps could make almost every morning an "all hands on deck" event for the ops?
> I've definitely seen "DDoS" used when there was no malice,
Absolutely. Used to work on the Identity team somewhere. Dev accidentally removed code that was supposed to cache a token on a very chatty service. Brought auth to its knees and called it DDoS.
> 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" :-).
This is a problem with the service, not with the developer.
If the service (doesn't want) / (can't handle) something, then it should rate limit it's response.
If the service can't handle "0.2%" of it's clients making a 'not unreasonable' amount of requests, how will the service hold up against a hostile actor who aims to DDOS their service.
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.
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?
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.
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)
Home Assistant should really maintain a list of actively hostile (and actively cooperative) manufacturers to make it easier to decide what to purchase.
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.)
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.
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").
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.
To some extent, serving ads is like owning a money printer. I can't really get upset that everyone wants to own a money printer. I just hope that there is a backlash against ads someday, where they start having a negative effect. "Oh, Toyota is constantly advertising in my garage door app? I'm going to buy a Ford instead." People say that the US government defaulting on its debt would be the end of the world, but the real end of the world is one where advertisements stop working!
As discussed elsewhere in the thread, it seems that this would be the number two reason, the number one being trying to be the only service that can profit from in-garage deliveries.
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.
> 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.
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.
I don’t, and would happily use that installer again. =) But unless you give feedback on how the choices are working out how can you expect them to know and have a better choice next time? (Genie, is what I heard for the future… I’ll have to check further when/if it becomes relevant)
I also just left my installer a voicemail explaining that they are going out of their way to break compatibility with the software I use, and I recommend that they look for another brand, at least for folks who are interested in wifi connectivity.
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.
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.
> 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...
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?
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.
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.
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.
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.
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.
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 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.
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.
> 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.
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.
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.
That doesn't need to happen for the Charlatan Group to struggle. Most current hardware companies are dependent on the customer to renew their hardware every 5 years.
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]
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.
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.
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.
I wonder if you could take them to small claims court. That's a potentially useful remedy, although pretty much everywhere, if they lose in small claims they can appeal it to regular civil court and make it prohibitively expensive to fight them.
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.
We went with an Owlet sock that we got pre-nerfing from the FDA to track breathing/O2. The internet connected monitor was actually the Owlet cam. It worked decently enough, but just headaches from it being a cloud connected camera pushed us to get an RF-based system when we wanted a second camera.
If it works for you, that's great. I'm not trying to yuck your yum, just sharing my own personal experiences.
It used to lol! But it’ll be a cold day in hell before I pay to use the thing I already bought.
We’re about to have our next baby and I have no idea what solution we’ll end up with. I might end up trying to hack the Miku. I used to be an embedded software guy long ago.
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.
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'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
654 comments
[ 2.9 ms ] story [ 550 ms ] thread> 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)
IOW, this real reason is better than their dumb comment about "unauthorized use".
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 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.
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.
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.
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 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).
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.
> 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."
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 don’t need a cloud server to remotely access a device.
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.
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.
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.
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.
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
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 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.
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.
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.
Haha, she's got you there.
I guess you started using Home Assistance recently / shortly... and/or you use only a few HA integrations.
Otherwise, you would have already run into enough troubles with updates.
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.
For example, Apple Home does not work by default over WireGuard.
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.
These very practical daily occurrences can make devices incredibly annoying and frustrating for typical consumers who want it to just work.
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.
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 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?"
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
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.
>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?
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..
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.
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).
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".
I just want to get local access to my openers.
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.
"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 support allowing their paid partners (eg, Amazon) to open your garage door for deliveries. I think this last part is where they get "value".
Either way, they'll almost certainly pull the plug on this service sometime before the end of the decade.
I'm sure this is a solvable and solved problem, but I do believe it is non-trivial, and potentially a major headache for a company to implement just to support a tiny niche of users. I'd be delighted to find out I'm wrong though!
And, unfortunately, the business case isn't there, since this weakens lock-in effects. I don't endorse this reason—that's why I run my own HA instance and don't buy or use any products that require the cloud or otherwise can't be operated entirely locally (including flashing Valetudo to my robot vacuum!).
It’s not a perfect solution since it costs money but it’s a nice alternative to exposing your HA instance or some other front end proxy to the internet.
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.
If you served the entire US (130 million households) and had a 1 hour keepalive, that's only 36k packets per second, which is nothing.
You could also auto-train the idle timeout by using a pair of TCP connections. One uses a known good value while the other probes upwards until it finds its connections start getting closed (with some optional binary search fanciness), feeding new known good values back to the first.
(Obviously the no-cloud solution is better still)
It'd be possible for a knows-enough-to-be-dangerous customer to modify their system in such a way that they unwittingly allow unauthenticated local access. From my point of view, Chamberlain/MyQ should be totally indemnified in such scenarios but I'm not sure how murky the legalities would be in terms of getting judges/juries to accept "caveat emptor".
EDIT: Maybe there's a way to ensure customers have signed an indemnification agreement before unlocking local API access? I guess there'd also need to be a way to ensure/promote a factory reset if/when ownership/rentalship changes.
I 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.
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.
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.
https://support.nuki.io/hc/en-us/articles/12947926779409-MQT...
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?
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
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.
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 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.
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.
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.
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/
Nit: That they know of. As you say it's a techy product and I would assume that techy types are the exact kind of people to turn off analytics.
Order of magnitude higher, same point, same result.
Well, you could always strip it for copper, I guess...
(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 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?]"
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.
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.
The second year there is much less work but they double the cost. You go along with that as it takes a lot of work on your part to engage a new escrow firm from scratch.
The next year they double it again. It's still demanded by your large corporate customers and you try to pass on the costs but they don't want to pay it.
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.
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.
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 Gaben has spoke: "piracy is more about convenience than price"
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).
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.
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.
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.
This was like 7+ years ago.
https://twitter.com/internetofshit
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.
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.
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).
https://www.athom.tech/blank-1/garage-door-opener-for-esphom...
Additionally, I tried using an Aqara vibration/tilt sensor for more accurate "partially open" status reporting but it was a) not sensitive enough b) too unreliable c) too slow to update. I guess it's more meant for detecting impacts or falls.
I've also toyed with the idea to mount an ultrasonic distance sensor at the top of the (rolling) door, which could measure how far from the ceiling/far wall the top of the door is, but it'd be pretty bulky and problematic to power mounted on a moving part like a door.
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).
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...
Absolutely. Used to work on the Identity team somewhere. Dev accidentally removed code that was supposed to cache a token on a very chatty service. Brought auth to its knees and called it DDoS.
This is a problem with the service, not with the developer.
If the service (doesn't want) / (can't handle) something, then it should rate limit it's response.
If the service can't handle "0.2%" of it's clients making a 'not unreasonable' amount of requests, how will the service hold up against a hostile actor who aims to DDOS their service.
What a shit move to pull on your existing customers.
I used a local Meross install on my old garage doors, time to break them out, but ugh...
It’s incredibly annoying and dumb and I now have to get some. grumble
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
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...
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.)
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.
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).
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.
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?
It's an open source project. Stuff generally gets worked on by people who care about features. You seem to care about this. https://github.com/home-assistant/home-assistant.io
any takers?
I wish ratgdo a ton of success and have several on order.
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.
I would try to sue that manufacturer. I hope it we'll be pulled to a court.
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.
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.
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...
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.
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
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/
ESPHome is also a good option and makes Home Assistant integration easier.
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
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.
Related thread: https://news.ycombinator.com/item?id=37594377
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.
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.
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.
I am in the market for a new opener.. I just need the physical clicker.
I will not be buying one from this brand, as even if I do not need the HA functionality I no longer trust them as a company.
That doesn't need to happen for the Charlatan Group to struggle. Most current hardware companies are dependent on the customer to renew their hardware every 5 years.
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]
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.
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.
You can report this action to the ftc https://reportfraud.ftc.gov/#/
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 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.
If it works for you, that's great. I'm not trying to yuck your yum, just sharing my own personal experiences.
It used to lol! But it’ll be a cold day in hell before I pay to use the thing I already bought.
We’re about to have our next baby and I have no idea what solution we’ll end up with. I might end up trying to hack the Miku. I used to be an embedded software guy long ago.
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.
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