https://github.com/Andre0512/hon
https://github.com/Andre0512/pyhOn
Doing what you suggest would require them to respect software enough to bring it in as a discipline alongside mechanical and electrical engineering.
Except lots of people wouldn't buy your shit if not for the addon.
> Specifically, the plug-ins are using our services in an unauthorized manner, which is causing significant economic harm to our Company.
> We take the protection of our intellectual property very seriously and demand that you immediately cease and desist all illegal activities related to the development and distribution of these plug-ins.
They seem to be threatening legal action because he is violating their terms of service? This doesn't make much sense to me
Or... better yet, engage with these clearly VERY passionate customers. This is someone who not only bought your product but has donated hundreds or thousands of hours of their free time to making your product better. Better how? Because its works in a way your customers want that you don't otherwise offer. Instead of demanding take down, file a bug report with them to explain how the code is misbehaving. Bugs happen, maybe the developer didn't include an exponential fall off for outages. Whatever. Let them know and they'll probably fix it. Heck, you could use one of the in house developers to file a pull request to fix it yourself.
That's how you be the good guys. Instead of stomping on small projects of passionate customers, you engage with them. Make them even more a fan of your product, rather than a lifetime hater.
[1] https://www.home-assistant.io/blog/2023/11/06/removal-of-myq...
If you want smart functionality, it had better run entirely locally, or else you should not care about or depend on that functionality.
-edit- I also had to learn this lesson (somewhat) painfully. I chose the EVSE that I did for 2 reasons: it was on the list of devices my power company would help pay for and it had an HA integration. less than 6 months after I bought it, the company killed the API that the HA integration relied on.
Luckily for me, the HA integration wasn't that big of a deal, more of "nice to have", but I learned my lesson to never use non-local cloud functionality as a selling point.
They offered API that they don't want people to use. Maintaining APIs and uptime costs, but they only wanted their API to be used by their apps that collect data about you.
I also had to learn that lesson painfully when my network connected Brother printer got a (unasked for and unapproved) firmware update that disabled the 3rd party toner cartridge it was using. It's now blocked from the internet in my router, but it's unfortunately a case of shutting the barn door after the cows are gone.
>Haier is a multinational home appliances and consumer electronics corporation selling a wide range of products under the brands General Electric Appliances, Hotpoint, Hoover, Fisher & Paykel, and Candy.
The bridge already has some weird requirements like refusing to work unless you connect an ethernet cable. As far as I know the update is to force you to use an account with the app, but the devices should still be compliant with other controllers.
The solution is to allow local interfaces (matter, HTTP, etc) but most company cybersecurity teams just freak out at this.
Oh, and the reason we don't have a full time team managing HA is like I said.. addressable market versus FAANG/Samsung.
It takes a full time person (persons) to manage Alexa, Google, Samsung, etc.
Yeah, and we can see(in general) how good they are. is there any such shitty consumer thing that doesnt have atrocious security?
They do about $30 billion a year in revenue.
I've long advocated a local HTTP interface for our products, but usually a losing battle.
Thankfully we have a (fairly) accessible API to the cloud side.
TBD on what (if anything) matter will change.
I often forget to take clothes out of the dryer in the garage, so I'm working on an automation to flash the lights by my desk with increasing urgency the longer clothes are left in.
I'm very surprised how well Home Assistant works for its kind of hobby project, it's matured quite a bit from when I looked into it a few years back. It's not a huge win if all your devices are already HomeKit and programmable via Shortcuts, but it's that it can bridge my non-Homekit Nest, ECOVACS, and GE devices into HomeKit land, and offer unified WebSocket & REST APIs to program against.
I can see why companies would send the takedown notices if their API service implementation is low quality. The HomeAssistant user has to be a super-expert, the sort of person to set up a Google Cloud project to create OAuth credentials so you can connect your calendar. There can't be a lot of those people, and the integrations are probably quite spammy with API polling.
I'm not sure what you'd need to do to disconnect your fork, but clicking the "fork" button will often get your repo automatically taken down if the parent repository gets DMCA'd.
If the commit history is different (say, because you rebased the project onto a slightly different initial state), Github won't auto-detect the fork as easily, so the lawyers would need to find your project and include it in their takedown notice.
It could still be identified as the same codebase by eg. comparing commit hashes or content hashes, but that's harder. If you really want to be sure, clone the repository, make a few local edits to files (eg. adding a comment to each file), copy the full source repository to a new directory in the filesystem, git init that as a new repository, commit changes, and push. That blows away all the existing history of commits, and ensures that each file has a different hash. It's still technically possible to detect it as a dupe, but would require an extremely expensive shingling or filesystem diff on every repository in GitHub.
Furthermore: reject them not only when the regular use goes through a cloud, but also anything that needs a specific app download or cloud connection just to change settings. All functionality available on local network and with standard tools or nothing.
I saw that a lot with cameras. "It has ONVIF, you just have to download--," nope, that's it, next candidate.
If home-assistant receives a GPL source code request(for example due to many of the python libraries in the home-assistant docker images being GPL licensed) wouldn’t the source code to all library dependencies(including the source for historical dependencies like any plugin taken down after a release) need to be provided for 3 years(due to the combined home-assistant application effectively falling under GPL requirements) from the date of last distribution of the home-assistant docker image?
Instead, this seems like a completely bullshit copyright claim. That's what the ideal fix should be.
There's zero incentive to not do DMCA takedown notices, what are the consequences of getting it wrong? It's a great tool to intimidate anyone doing something you don't like. Haier has a legal team, this developer has nobody.
A lot of the worst IoT vulnerabilities in the past have been due to exactly that. 'Local' unfortunately isn't something decided at design time, it's decided when someone connects it to a network. Most people plugging these devices in don't have any clue how to simultaneously secure them and connect them to the internet, so they often end up directly on the internet with default credentials or with outdated vulnerable software and a port open. That's the biggest reason all of the major players now just close all inbound ports and reach outbound to a cloud service. It checks both boxes of usability and network security with even the most misguided user.
Yes, this arrangement sucks for people who know better. But we aren't the people in the user stories.
But, the alternative is we either accept this completely upside down API traffic ratio with locally focused integrations (bad, costs lots of money) or allow a local interface.
Another potential workaround I advocated for was a "cloud down" message that could enable the local interface for those that ONLY go looking for how to do it.
I wonder how this would play out if instead of serving responses for nonhuman consumption (i.e., an API), it was serving responses for human consumption (i.e, HTML documents). In that scenario, if a subset of requests were of a high-frequency nonhuman nature (i.e., polling and scraping), would a court find it equally abusive or materially different?
If you use HomeAssistant and have some Philips Hue equipment, you can pick up a $30 coordinator and you'll be in full control. It's a nice bonus that compatibility with other zigbee devices expands dramatically.
I got rid of my Hue Hub ages ago.
That is a very major claim to be making. If that's true (or even plausible) it's a very huge deal. Is there anywhere I could read about any of that?
-edit- also I'm either misunderstanding your comment or learning something very major about HA. I didn't realize it was a cohesive enough entity to have "staff" that could be moved around/laid off.
Making it so that only people who care and are more likely to use it in a responsible way have access is pretty reasonable! Not having the option isn't (in my opinion).
Plus finding I'm logged out and having to log back in when I just want to turn a light on/off in the middle of the night (because baby) is a PITA.
I have a Hubitat Elevation for Aqara temperature/humidity/pressure sensors mostly. They all run locally. I'd like to throw some smart LEDs in the mix for ambient lighting. What's a good, non enshittified vendor?
With my business hat on, I'm not so sure. "Why are we spending development resources on a feature that isn't valuable for our target users?"
I could definitely see doing this if it were a product with a prosumer-type angle to the value prop. But for the devices we see on the shelf at a big-box store, I don't think those companies' management considers that valuable.
When the Chamberlain story happened, I received questions from executives on why it was such a big story.
From a business perspective, it just isn't.
I agree with you.
Same reason we don't dedicate people to write HA integrations.
1. https://www.home-assistant.io/blog/2018/04/12/ubiquiti-and-h...
2. https://www.home-assistant.io/blog/2019/05/03/update-from-th...
I'm probably going to ditch Hue in favour of smart switches and dumb bulbs in my next house, so not too worried about it.
This appears to be the company contacting the developer directly to ask that they withdraw the code.
In the last half year Haier, Chamberlain, and Mazda have issued takedowns or actively blocked access to HA integrations.
Last year Ubiquiti Networks hired me, Paulus Schoutsen, the founder of Home
Assistant, to work full time on improving Home Assistant. This has really helped the
project make big leaps towards getting to 1.0. During this time, Home Assistant added
an authentication system, the concept of devices and areas, a UI for configuring
integrations, and the new Lovelace UI, just to name a few things.
We left on friendly terms and I want to thank Ubiquiti for this tremendous
opportunity, it has given the Home Assistant project a significant boost.
Personally, I'd call that a win. :)
It's obviously connected to the public internet when it talks to cloud servers, and that's somehow (claimed to be) secure.
Comparing a good cloud API with a poorly designed local API is a false dichotomy. Would you set up your cloud servers with default credentials of admin:admin?
Have a hidden physical switch that toggles local control, and require a physical button press to (re-)generate secure credentials. Have the user upload TLS certificates (non-optional), then hand over the credentials over a secure connection. There, the security of local API should now be up to par with the cloud connection.
I extensively use HA and buy (and build) various smart stuff so now I know I blacklist Haier. Good thing they released the request.
I will share this news with the HA networks I am active in.
Thank you Haier for being proactive and help me to (not) choose!
It is a fundamental digital right despite what nonsense-ese is present in any service's egregious terms and conditions.
There needs to be an anti-adversarial interop specific complaint department at the EFF.
Otherwise one day, one of these developers will take the lack of support at its face and choose to defend themselves in court without any (legal) resources.
When the precedents are set that billion dollar megacorps can ruin an interop developers life due to overreaching ToS or some bs about copyright then it'll be too late to cry about it.
Invidious (YouTube), beeper (iMessage), Meta Vs many OSS Devs, etc. etc. etc. largely show that tech's freedom loving stance is not much more than lip service.
Interop projects aren't sexy. The Devs behind them get a pittance if anything. It's not VC-able. Yet instead of praise for the dog work they do we have well-actually-niks berating then in situations like this.
We are now becoming digital beings. We should have digital human rights. Interop is a base level digital human right.
I want to thank you for your work Andre0512 and Long Live hon!
P.s if there any EU digital lawyers out here please reach out to Andre0512 and actually help him please!
What impressed me particularly is that the generation 3 smart heaters (which is my version) lets you specify to NOT connect to the cloud when it joins WiFi, and instead is accessible only locally—in my case via home assistant. (But I did have to create an account on the first-time setup to update the firmware) The fact their newest products offer this kind of functionality gives me some faith in the future.
I use HomeKit so this probably doesn’t directly affect me at all. But if I stop using HomeKit, I can and will do as I see fit to make the gear I already own work with whatever I’ve switched to. If adversarial companies want to stop people from doing that, then I’ll help them in that mission by not bringing their stuff into my house in the first place.
I was gifted this particular appliance, but the solution is really to just not give companies like this your money. Unfortunately it's easier said than done, but looking for things with a local API or based on an open and configurable standard are a good start.
I'll add Haier and related companies to my ever growing blacklist because fuck them for this.
I vehemently support people doing what they want with the things they own so long as it's not "interfacing" with other people or their stuff; don't connect to or "abuse" their cloud systems, they can rightfully be upset about that, but removing their crappy smarts (and data collection) and replacing it with local-only is your own business and companies like this can get lost.
See also previous discussion on >>39044932
upcoming legislation in Europe mandates secure-boot for any IoT device sold by 2025 in EU. this and the cybersec resilience act will ensure only firmware shipped and signed by the vendor are able to boot :) ... so your comment is spot-on.
However, the app to control them cannot work without a connection to the server. It has no local device functions at all. It won't even launch if their servers are offline.
That's just next-level stupid to me. Why build in a useless option? If Bluetooth won't work without a server connection anyway, what's the point?
* A declaration that no content copyrighted by the hardware vendor is in the codebase
* The code cannot be classified as a DMCA circumvention device as it does not provide
access to copyrighted works
* An assertion that the RE activities are protected under US fair use doctrine for the
purposes of hardware interoperability (even if not a US citizen)
* Any potential trade secrets were discovered independently through the RE process
The code in question scraped the API off of app/device traffic.
Also, Home Assistant is a locally focused platform, and when it uses cloud APIs it creates HUGE amounts of traffic for the amount of users that use it.
Source: I run a developer program for a different IoT company
For smaller non-appliance stuff there's CloudFree [1] which sells products from other vendors that can be reflashed with ESPHome (no affiliation, just a happy customer).
[0] https://www.silabs.com/wireless/z-wave/500-series-modules
They have no right to be upset about that. They sold you a requirement to connect to that cloud. If they don't want anyone connecting to their cloud, then don't sell cloud connected junk.
Emotionally, ethically, morally, sure. Legally? We'll see how this shakes out, I guess.
But yeah - this is one of the reasons why nothing in my home is smart. I fully can't bring myself to trust any company to not eventually fuck me, either intentionally, or by going out of business and bricking some C&C server, or by selling themselves to some assholes.
Or, crazy idea, just let users use their devices locally. You won't even have to get your shit together and fix your api then!
Now also just design an official home assistant module and you've turned this drama into community goodwill.
Wouldn't a GitHub search still find it pretty easily? As I understand it, they put significant effort into supporting search; but since that's being done anyway, it doesn't have a very high marginal cost.
Radio Equipment Directive which now has a huge cybersec impact. So if you want to sell hardware in EU it must be certified
here is a lot of what will be in there. https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02...
the final standard is not the above but based on the ideas in ETSI.
While the above applies mostly to the "thing" the cloud and edge that enable services for IoT will be covered by the hotly debated CRA:
Yeah right.
https://en.wikipedia.org/wiki/Sony_Corp._of_America_v._Unive....
I think this applies here as well. Curious how this will play out.
We actually have a public self-serve API. In some cases, if I've tried the diplomatic approach, I've had to actually shut off API access to get someone to even respond to me.
In this case, it appears they've taken the same access/creds as the mobile app maybe?
Another one of our platforms we cert-pinned the API to prevent this as well.
Yes there are ways, the other part we don't know is if they went straight to the legal route or not.
If 3k home assistant users take up as much traffic as say... 50% of my total population we're just supposed to accept that cost in perpetuity?
> Or, crazy idea, just let users use their devices locally. You won't even have to get your shit together and fix your api then
I advocate for local access internally (to be clear, I don't work for Haier). But I'm here to discuss things I have sphere of influence over as well.
> Now also just design an official home assistant module and you've turned this drama into community goodwill.
That, again, costs money/people/time that can be spent doing things that keep us all getting paid.
All this said, we have lots of API keys in our systems issued that are used in HA, and they DO take up lots of traffic. I sort of let it go because of exactly this (it creates a lot of noise to shut it off for little benefit).
Again, I also agree we should all offer local interfaces, but that's an uphill cybersecurity battle (lots of reasons, some of them not great)
https://chat.openai.com/share/6386ad1f-a44d-4cc1-a5d1-0e3c3c...
Sega Enterprises Ltd. v. Accolade, Inc.: In this 1992 case, the court held that Accolade's reverse engineering of Sega's game console for the purpose of developing compatible games without licensing was a fair use.
Sony Computer Entertainment, Inc. v. Connectix Corporation: In 2000, the court ruled that Connectix's reverse engineering of the Sony PlayStation to create a compatible emulator (Virtual Game Station) was fair use.
But yeah, things aren't like this all over the world.
Should Sony decide what you do with your TV? No.
Should Haier decide how you control your AC? NO.
Should Whatsapp decide how you interact with your own account. NO!
Interop devs are the Louis Rossman's/mom & pop repair shops of the software world.
They take whatever redundant software/service you have and enable you to use it as you see fit.
This is a good one:
https://www.reddit.com/r/homeassistant/comments/19a615l/haie...
It's an odd width because of a stupid home remodel by the previous owner that I can't really undo, and haier was the only vendor that didn't want to charge me "designer" prices because of that.
Hopefully it keeps going strong :/
Yes, they are your users. They are likely the people who will gush about your product to their friends and result in more sales. If the plugin could be behaved better: Make a PR and improve it. People will love you if you do it under your company name, but if you don't want the potential internal drama just do it anonymously. Wins all around.
> That, again, costs money/people/time that can be spent doing things that keep us all getting paid.
Power users are some of the best cheap marketing available to device manufacturers. They will post about your product online. They will tell their friends. They will make your product better for no charge to you.
> I also agree we should all offer local interfaces, but that's an uphill cybersecurity battle (lots of reasons, some of them not great)
I'd love to hear about how this could be considered a cybersecurity issue. It's typically far more secure than a cloud connected solution, but most companies don't like that line of reasoning because it doesn't allow them to track their users.
- they plan to trap customers in subscription scheme, that's one of the few logical reasons to oppose ADDING ways to use their devices;
- they surveil and profit from data gathered form their users, to be known if under the respect of GDPR and similar norms or not;
Those reasons suffice to AVOID any vendor who have such track record FOR LIFE, even if they change after a certain backlash. That's is, people simply must understand the concept of subscription trap and the concept of ownership, witch should be known but evidently it's not that understood for the sake of human civilization and evolution.
Haier US -> GE Appliances -> Haier Group
Haier Europe -> Candy Group -> Haier Group
Which is why to this point, I let it go and don't actually tell anyone how much traffic it takes up. It isn't worth fighting over. Haha.
> Power users are some of the best cheap marketing available to device manufacturers. They will post about your product online. They will tell their friends. They will make your product better for no charge to you.
If I had some way to quantify that, I'd accept it. But as it sits now the vast majority of our users don't interact with any integration models short of "share data with my installer". Alexa being the most popular aside from that.
> I'd love to hear about how this could be considered a cybersecurity issue. It's typically far more secure than a cloud connected solution, but most companies don't like that line of reasoning because it doesn't allow them to track their users.
Go look at major IoT "security problem" news. It is either "cloud leaked data" or "OEM didn't lock down local interface correctly". See the recent Bosch Thermostat story.
Or the "horror years" of Chinese ODM cameras showing up on shodan with live feed video access.
I don't mind a cloud option, but prefer self hosted first. I'm particular something that's already or otherwise ready to containerize.
I would suggest complying. Then, probably, a clone of the repo could maybe show up in some other git host, like Gitee, without authorship information that can reveal who to send further legal threats.
I would of course never do such thing. Just talking about an idea a friend had.
A Chinese appliance maker with a German sounding name already sounds a bit dodgy in my books. But...I don't think most of us are the target, they go purely at the value buyer market.
There are also carve outs for breaking DRM for compatibility.
At what point will the courts decide that post purchase contracts are unenforceable?
I believe EU has already done that. That'd be a hidden term, I believe.
https://europa.eu/youreurope/citizens/consumers/unfair-treat...
Asking why a Haier dishwasher doesn't have a local API is like asking why a Toyota Sienna doesn't have configurable launch control, power-take-off, or a fifth-wheel. The target market segment isn't looking for those features.
(from their wikipedia article)
For strips, if you're ok with wifi, HE supports local control of Kasa devices, which is made by TP-Link. Otherwise your best bet is something Zigbee-controlled but I don't have a particular recommendation.
Check the HE forums[1], too, they're very active and full of recommendations, driver links, and experience reports.
It doesn't have to cost the manufacturer one full-time employee to maintain a relation with the home assistant community. Just let the community do the work to develop integration for your products for free! Just look at how companies like Asus maintain a relationship with open source router firmware maintainers for example. Asus spent a minimal effort in that front, yet the community is very happy and keep recommending Asus routers to their friends and family. It's basically a win-win relationship.
All Haier need to do is sending an email to the maintainer of the open source integration asking them to not polling so heavily and they'll usually comply! It shouldn't take a dedicated employee 40 hours per week to send that email. Taking down an integration should be the last resort because it burns the goodwill of your community. The first step should be reaching out to the dev and work something out.
1. Making sure their app can control the smart devices even while the internet connection is out as long as the phone and the devices is connected to the same lan (local control). Local control adds resiliency to your product, which increase user satisfaction. Don't see it as spending an effort to support home assistant, but instead, see it as making your own product more resilient to unstable internet connection.
2. If your device don't support ZigBee (or other local protocol) and only supports wifi, have the local control api secured with a key. This key will be generated during initial setup and should be retrievable from your app.
That's it. If your devices are popular enough, someone will poke around, see the device has local control api secured with a key that can be retrieved from the official app, and publish an open source integration on HACS. You spent zero effort to directly support home assistant but your users now has an option to use their devices with home assistant and will likely to be a repeat customers.
Which is why they aren't.
I agree with you wholeheartedly that it should be fair game, but ultimately, if reverse engineered users are creating, say, 50% of traffic[0], because they're polling instead of using the proper push mechanism, these sorts of companies can and will get upset.
Frankly, as a backend software engineer myself, if any system I built with the purpose of being constantly accessed by a fleet of devices sold on the open market couldn't handle the relatively tiny numbers MyQ created a fuss[1] over, I'd be embarrassed.
[0] https://chamberlaingroup.com/press/a-message-about-our-decis... [1] https://www.home-assistant.io/blog/2023/11/06/removal-of-myq...
And I don't dispute that, this option should remain available. What I dispute is the idea that the lack of local control is somehow beneficial to the end user by "protecting" them from vulnerabilities.
The only thing such arrangement is protecting is the manufacturer's bottom line, by allowing them to 1. harvest and sell data, 2. take away features or start pushing upsells when they need to boost their quarterly profits.
> Asking why a Haier dishwasher doesn't have a local API is like asking why a Toyota Sienna doesn't have configurable launch control, power-take-off, or a fifth-wheel.
Well that's just ridiculous, all of those features have significant per-unit cost to implement. Exposing some form of local control would take, if we're being generous, a couple of person-weeks of effort and it would cover the entire product line with a marginal per-unit cost of a single switch.