Haier hits Home Assistant plugin dev with takedown notice | Hacker News Reader

Haier hits Home Assistant plugin dev with takedown notice

bleepingcomputer.com

175 pointslinker3000169 comments

I'm in the process of reverse engineering an appliance myself to allow it to be integrated with Home Assistant, one which requires an mobile app to operate remotely and is connected to the net all of the time, when it doesn't need to be.

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.

which appliance?

If some company sells stuff that requires a connection to their cloud then it is 100% fair game to reverse and utilize that cloud to get the product working the way you want.

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.

> They have no right to be upset about that.

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.

All my smarthome stuff is zigbee based, controlled by home assistant locally. It's nice. Agree on avoiding cloud garbage.

I think the issue, particularly in the case of some of the companies that have been hostile to Home Assistant integrations, is that, according to them, the small number of users with reverse engineered access to their cloud, tend to abuse the API by creating a significant percentage of the traffic, presumably by accessing it "incorrectly".

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

On a related note, we bought an LG wall oven, and, after the cabinets to fit it were built, inside the oven door, we found a “by using this oven you agree to binding arbitration and worse” sticker. Of course, it was too late to switch out the model, and the distributor wouldn’t have accepted the return if we’d tried.

At what point will the courts decide that post purchase contracts are unenforceable?

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

Per the one tweet in the article that says they only bought one of these appliances because of the HA plugin: the lesson is don't buy smart devices that have cloud control. Whether or not they have local automation plugins (like HA), or just that have apps/cloud services, expecting those capabilities to remain for the life of the device is a fool's errand. We have a host of examples of cloud services being killed and open integrations getting taken down, and none of the examples where this hasn't happened have existed long enough for us to say anything besides "so far".

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.

Philips Hue did run locally, and now they are rolling out updates where a cloud account is required.

Yeah the second rule is: for anything that runs locally and for which your use doesn't require an internet connection: put it on a separate network without WAN access.

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.

Hue bulbs and strips run fine on HA. For a couple of reasons, I have a completely offline system running in a Docker container with a ZigBee dongle (mainly I have no control over my LAN). I don't use the bridge any more. You don't get some of the scenes and other functionality that the bridge offers, but 90% of the functionality is there.

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.

That is only for the Hue app. You can still just put them in pairing mode and use any zigbee controller you like.

You can also still use the Hue hub. It accepts local http requests for all functionality.

Aren't they removing that?

So far mine keeps working with Home Assistant

I haven't heard anything about that - but, if you have disallowed it from accessing the internet, it can't update to remove any features.

No, they're just enforcing that everyone must have an account to use the Hue app. But big parts of the whole Hue ecosystem depend on local access, so it's out of the question that they'd remove it.

I’ve also been annoyed by this but thankfully the local hub still accepts HTTP requests just fine. The first party mobile app is all that’s affected.

Thankfully it's not much of a loss, and there's actually a lot to gain by not touching Philip's cloud.

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.

And I don't know if it's just me, but responsiveness seems worse in recent months (using iOS app, don't know if it's the app or the bulbs or the hub). And sometimes the app is out of sync with the actual light states. I haven't seen this in years of using Hue bulbs and app.

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 haven't had Hue login troubles, but the quality of the light control has gone down a bit. If I tell it to turn the lights to the fireplace mode, that gets turned into multiple instructions to the light bulbs, but sometimes it drops some of them for no reason. So I get half-brightness daylight-white instead.

Yeah that sounds about right, too. Sometimes I move the slider and it doesn't adjust. Sometimes the slider is in one place and jumps to another without me touching it. Not often, but I'm pretty sure it never used to happen.

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.

Totally correct.

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.

Scratches Haier off list of household vendors.

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.

Scratch off everything that requires internet access (in this case the Home Assistant integration talked to the vendor's API servers).

See also previous discussion on https://news.ycombinator.com/item?id=39044932

curious, is there a vendor that isn't "cloud-first" today? I've never seen an appliance that doesn't call home

The one that frustrates me the most is Home Depot's HubSpace. You do not have to link the devices to the router. They can be operated by Bluetooth.

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?

The "feature" is end user tracking and isn't for you, it's for the vendor. So if the servers are down they don't care about the rest of it.

At some point a team of developers fought for local control. They lost but it's too expensive to rip out again. So management chooses to sweep it under the rug and pretend it doesn't exist. Stalking your users is so much more profitable.

The trick is to get a ZigBee device instead of a WiFi one. It's an inherently local-only protocol and you can make your computer a Hub with a $30 stick.

ZWave is another option here too. I wouldn't recommend devices that don't have at least a "500 series"[0] chipset, but pretty much any device you'd buy today or moving forward will contain this or a newer chipset.

[0] https://www.silabs.com/wireless/z-wave/500-series-modules

Yes, ZWave is good too, though I haven't seen many devices in the wild myself - this might depend on your local market.

Z-Wave is also nice because it's in the 860/900 MHz band. Better propagation through walls and so much less contention than 2.4 GHz.

Shelly devices are great. They have a "cloud" that you can optionally use, but the settings (at least on the switchable plug and the in-wall energy-monitoring switches that I have) default to that cloud connectivity being OFF. They seem to be aligned with those of us who prefer local data, interoperability and despise vendor lock-in and surveillance capitalism.

Pretty much any vendor selling commercial appliances. SpeedQueen even gives you the choice of the old school mechanical controls. I don't know if they even have any smart consumer devices. They can be a bit more expensive but rarely break from household use.

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

[1] https://cloudfree.shop/

I've bought from cloud Free before, worked great.

Esphome supports several AC units using a simple dongle: https://static.xtremeownage.com/blog/2023/pioneer-mini-split...

My Venstar T7900 thermostat has a local HTTP API. It has some cloud stuff too, but I've never created an account or let it talk to the Internet.

> Scratches Haier off list of household vendors.

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.

Just like the recent case of Mazda sending a Cease and Desist to someone writing an integration:

https://news.ycombinator.com/item?id=37990990

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.

The two subject repos are:

  https://github.com/Andre0512/hon
  https://github.com/Andre0512/pyhOn

Make whatever use of that information you will before the takedown occurs.

If people fork the repo, would they also be sent a takedown?

If you fork it, do a proper git clone and git push. Github can and has DMCAed direct forks in the past.

At the risk of asking a dumb question, what does a git push do for you there? (Fully agree on the clone locally point.)

Not the GP but at that point it's available and more discoverable for at least a little while longer for others (and no guarantee you'd get hit with a takedown as well).

Thank you! I was considering a different/lesser form of "keep it privately available" (as I suspected that keeping it widely/anonymously publicly available was never going to work.)

Don't rely on GH alone. Save a local copy. Host it somewhere that isn't so centralized and discoverable. One upside of increasing centralization is that people who you don't want finding things are awful at finding said things that exist outside it.

If Github doesn't realise you forked the project, it doesn't appear in the list of forks, which a lot of companies use when sending an actual DMCA notice to Github.

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.

When I read ‘git clone’, I assumed “on the command line of a machine you control, run git clone” not “use GitHub’s repo fork web interface action”.

It's not marked as a fork in their systems. Instead, it's as if you'd written a bunch of code in a local repository and then pushed it to GitHub.

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.

Find the first commit and overwrite it :P

That could still be fairly easily detected by looking at the tree and blob ids.

I never use squash but couldn't you squash all the commits into a new one for a new history?

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

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.

This doesn't appear to be a DMCA takedown request, so I doubt Github would care.

This appears to be the company contacting the developer directly to ask that they withdraw the code.

because a company asking for a takedown would never file a takedown request afterwards?

In this case probably not. DMCA takedown requests are only for alleged copyright infringement. The allegation here is that the software is using an API on a company server in violation of the terms of use.

If people are forking it, it would probably be worth mirroring it to GitLab, Sourcehut, Codeberg, or some other place that isn't GitHub, since they could likely very easily remove all the forks at once if asked.

The takedown notice says that the "plug-ins are in violation of the terms of service". This is super odd. So what would happen if I never bought their product and hosted this repo - while not being a party to the terms of service?

Probably this: https://github.com/Andre0512/pyhOn/blob/main/pyhon/const.py

Sounds like the company could just invalidate that API key and break the integration themselves whenever they want.

Initially I had the same thought: I'm not using their services, how can I break TOS? But this explains it. If a device cannot be controlled locally and need their cloud connection to work, it's in a high risk of becoming e-waste at some point of time. That's why I would never pick such devices.

I wish there would be an appliance manufacturer that would actually hire developers to create and maintain Home Assistant.

Hardware companies don't understand how software works. To them, it's just something you pay a low-wage grunt to produce to an exacting specification written by an EE.

Doing what you suggest would require them to respect software enough to bring it in as a discipline alongside mechanical and electrical engineering.

Tuya started this trend in 2020, but it didn't last long. They developed lots of local-APIs, but quickly stopped contributing to GH repo.

Ah hell naw. Walled garden much? If anyone dumps significant enough money into the project they're going to expect "a return".

Home Assistant users are small minority of many of these companies user bases (including ours), and these integrations being locally focused often poll HEAVILY causing an upside down ratio in API traffic compared to all other users.

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.

> but most company cybersecurity teams just freak out at this.

Yeah, and we can see(in general) how good they are. is there any such shitty consumer thing that doesnt have atrocious security?

Security via obscurity and "closed loop" tends to be the answer, plus whatever doesn't show up on a scan tool.

Thankfully we have a (fairly) accessible API to the cloud side.

TBD on what (if anything) matter will change.

Why would the cybersecurity freak out at that, that seems opposite. The company owning the data (and controls!) is much more of a risk.

Don't ask me to explain the mindset of your average "tool runner" cybersecurity person.

I've long advocated a local HTTP interface for our products, but usually a losing battle.

>local HTTP interface

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.

Even though I advocate for a local interface, I also completely agree with your statement.

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'd be 100% on board with local control being a minor PITA to enable, as long as it's allowed and supported. I'd even be ok all the way up to needing to reflash the board to allow it.

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

With my developer hat on, I agree.

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.

At this point? I'd push harder to avoid all this negative press that is pervasive in IoT journo when it REALLY impacts a percent of a percent.

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.

All companies need to do to support home assistant in this front is:

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.

And all they need to do to be commercially successfully in the consumer market is: none of that.

Which is why they aren't.

> 'Local' unfortunately isn't something decided at design time, it's decided when someone connects it to a network.

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.

There's a at least a dozen ways for set up a secure local API. Whether it is possible was never the question. The question is whether Joe Blow can pick one up off the shelf at Best Buy and successfully implement it. The answer to that question is no. Joe Blow wants to download the app, click the button, and make it work. This is 99.999% of the users that buy something off the shelf at the big box store.

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.

> Joe Blow wants to download the app, click the button, and make it work. This is 99.999% of the users that buy something off the shelf at the big box store.

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.

Hah, the staff on Assistant working on home integrations measured in the hundreds (I used to work adjacent to those teams). Of course most of them were either laid off or reassigned to other projects, so it's pretty likely that Assistant will stop working soon, if it hasn't already.

It takes a lot more to deal with/manage these integrations than some on HN ever realize, especially when these stories come up.

Hold up....Home Assistant staff has been recently cut in a way that you think the entire thing is likely to stop working in the near future?

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.

I'm guessing when they're saying "Assistant" they're talking about Google. Not HA.

That makes more sense, you're right.

They must be talking about teams at Amazon, Google, or Samsung. HomeAssistant doesn't have hundreds of staff to begin with.

Yet most 3rd party home assistant integrations are maintained by a single person in their free time. The devs targeted by Haier even maintains TWO integrations in his own free time.

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.

Ubiquiti did that[1], didn't work out so well[2].

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

According to your [2], it did work out well though?

An employment ended by the employer in less than a year because the employer "changed their plan" (according to the former employee) doesn't look like a success to me.

The article literally says:

    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.

... along with:

    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.

Sounds like it moved the project forward in good ways that wouldn't have happened otherwise.

Personally, I'd call that a win. :)

Is anyone maintaining and publishing a list of these consumer-hostile companies to avoid?

In the last half year Haier, Chamberlain, and Mazda have issued takedowns or actively blocked access to HA integrations.

Just go to the bottom of the integration listing on Home Assistant's website and skip anything with a category that involves cloud. When companies are providing things for free that has an ongoing cost, something is going to break eventually.

> We are writing to inform you that we have discovered two Home Assistant integration plug-ins developed by you [...] that are in violation of our terms of service

> 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

IANAL, but this sounds like bullshit intended at scaring people into compliance. An individual cannot afford legal fees against a corporation no matter what. The usual.

It looks like it is using a service running on Haier's servers, which is probably what brings terms of service into this.

The tech community as a whole is dropping the ball by not advocating loudly and openly for adversarial interoperability.

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!

It could be a part of the push for right to repair. Farmers have pushed similar interface needs for maintaining advanced farming equipment. This seems very similar.

Interoperability IS right-to-repair for software.

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.

One of my thoughts is you can have the FTC and IRS issue rules about what qualifies as first sale and doesn't. Anything that fails the company has to count as inventory with a 20 year depreciation schedule. And they're required to pay for disposal.

I am very ignorant about this topic. Can you please explain what "adversarial interoperability" means? The term sounds very intriguing.

I intuited the phrase in context to roughly mean that APIs are fair game for respectful contact by everyone including competitors. It wouldn't mean they need to provide a open api spec or make it easy, but it couldn't be a ToS violation or something forbidden to access.

You can see "Adversarial Interoperability" on Youtube to see talks on this.

This is a good one:

https://www.youtube.com/watch?v=rimtaSgGz_4

Isn't it more than settled down on the US? The "tech community", whoever you think has any power there, isn't doing anything because the lawyers already overpowered everybody and mounted some unbeatable defenses.

But yeah, things aren't like this all over the world.

My advice would be never to purchase anything from Haier, IoT or not. We had a washer drier that had to be repaired three times because of an enormous design flaw causing it to overheat to a dangerous extent. I did eventually somehow manage to persuade them to collect it, after more than a year of back and forth with their nice, hardworking and entirely powerless customer service team. After the device was collected it then took more than six months for me to get my money back. Never again.

This is too bad. I've got a (dumb) Haier refrigerator that works perfectly well, going on 5 or 6 years now.

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 :/

>"Specifically, the plug-ins are using our services in an unauthorized manner, which is causing significant economic harm to our Company."

Except lots of people wouldn't buy your shit if not for the addon.

It should be a requirement that companies include a good-faith estimate of actual economic damages in a DMCA, or an excellent reason why they cannot come up with such an estimate, and if there is a lawsuit stemming from this later be on the hook for those estimates actually being in good faith and not just "let's assume everyone in the country would have bought our dehumidifer if not for this GitHub repo existing ..."

I don't think anyone should have to estimate damages for DMCA. Damages are not an issue, it's still your copyright.

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.

Unfortunate. I'm not directly affected by this takedown, but I just started using Home Assistant with my GE (owned by Haier) washer and dryer via this repo: https://github.com/simbaja/ha_gehome

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.

It's annoying how, in the world where a few boys could code Second Reality in 1993 in barely a megabyte or two, on computers that were a tiny fraction of what we're using today, we (collectively) have somehow obfuscated the matter of simple remote sensing and switching across a network into this ongoing kerfuffle of competing interests and complex, shaky solutions.

This is stupid and just like Chamberlain with their MyQ snafu [1]. Assuming the developer did not steal the code, then this sort of work should be protected. If you have a public API, people should be legally allowed to use it and work against it. If you as a company don't like that, then make it harder for 3rd parties. If the open source code is abusive, then use a freaking WAF to protect yourself. But unless they are hacking yours system, stealing code, or being intentionally abusive there should be no legal recourse here.

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

[dupe]

Discussion: https://news.ycombinator.com/item?id=39044932

I was researching whether there's legal precedent making such uses legal, and ChatGPT pointed out that "Sony Corporation of America v. Universal City Studios, Inc.," where it was decided that developing a VCR where users can record Universal's content is legal.

https://en.wikipedia.org/wiki/Sony_Corp._of_America_v._Unive....

I think this applies here as well. Curious how this will play out.

Here's the chat log if you're curious:

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.

Have you verified the court cases? ChatGPT answers are usually garbage when it comes to facts.

Yes

The only Haier products I've ever owned were "dumb" TVs that I received several years ago when buying some furniture. For that reason, I categorized them as very low-end in my mind.

Another brand to add to the shit list

It's been there for a long time. The quality of their products is awful.

I've once read an article in Harvard Business Review about how this company works, it's also awful. It's like they are all "self employed" and can associate with other employees to form a mini company inside Haier. They are all competing against each other, the fluctuation between the teams is very high and of course if their mini companie is successful, the company takes the profits and credits for it, if you don't make your money worth you get canned quite quickly

FWIW This is Haier Europe, Haier US supports Home Automation and DIY IOT:

https://www.reddit.com/r/homeassistant/comments/19a615l/haie...

Haier Group owns them both so to me it doesn't matter which "region" it is, Haier Europe is still Haier, Haier US is still Haier

Haier US -> GE Appliances -> Haier Group

Haier Europe -> Candy Group -> Haier Group

How is this different to Google copying Oracle's Java API? Is it because it's hardware?

The devices talk to Haier's servers, which Home Assistant (or rather a third-party integration) then talks to. It's dumb that it's required, but at least Haier's servers are involved.

Oracle vs Google is a fully resolved case that cost those companies millions of dollars to litigate. This is a shakedown letter which uses those kinds of large legal damages as a threat to force a developer to stop doing something that a company does not like.

I was wondering if the precedent set by the Oracle vs Google case applied here as the user is re-implementing an API, but considering the fact that the user still has to go talk to Haeir servers, it's a different story.

Asking a similar vein, really sick of all the cloud first networking great. Like Access Points especially.

I don't mind a cloud option, but prefer self hosted first. I'm particular something that's already or otherwise ready to containerize.

Just bought a convection heater today. I was willing to spend more for a “smart” one, but on the one condition that I was confident it would work with Home Assistant. Certainly not opening my wallet for the likes of Haier until they change their tune.

Would you be willing to share the one you ended up getting?

Yes! I was a bit cagey because I hadn’t tested it so didn’t know if it worked. It’s a Mill smart convection heater. Their smart stuff works both with their app and with a Home Assistant integration (and via HASS with HomeKit as well). Really neat to use when it’s all set up.

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 noticed a potential licensing issue Home Assistant may have when it comes to relying only on an external package source host like pypi and complying with a plugin takedown request.

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?

No, why do you think that? Have you actually read the GPL?

Never heard of them. May the Streisanding commence.

You may not have heard of Haier but I'm pretty sure you've heard of GE Appliance and Hoover.

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

One of the largest consumer appliance companies in the world... the own GE Appliances, for instance.

They do about $30 billion a year in revenue.

"According to data released by Euromonitor, Haier was the number one brand globally in major appliances for 10 consecutive years from 2009 to 2018."

(from their wikipedia article)

Yes, but I suppose the name is rather unknown in Germany. I only know some brands enumerated in other comments (Hoover etc.) from American TV series.

I guess I'm not buying that GE washer/dryer combo now...

I was never impressed by Haier's quality to begin with. I for one wouldn't have bought their junk anyway. You're not missing anything. Take a hard pass and buy something that lasts? Have a Haier already? Sell it and buy something with a chance of longevity. BTW, the US/EU distinction on IoT is interesting, but in the end it's all Haier China. So you know what to expect.

If you are going to break DRM know that the DMCA makes it copyright infringement regardless of how easy it is. If you create software that does this do not use your real identity and ensure any IP used is not your own. Leave them nowhere to send "legal action" to. Only those that play by the rules are affected by those rules.

> If you are going to break DRM know that the DMCA makes it copyright infringement regardless of how easy it is.

There are also carve outs for breaking DRM for compatibility.

This is like suing somebody for using chopsticks to eat a meal you sold them. Where is the financial damage? Do they sell their own automation products? Even if that's the case, and they're fork-sellers on the side in my analogy, there's absolutely no good to come from suppressing these plugins.

>Where is the financial damage?

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.

> They offered API that they don't want people to use.

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?

HTLM documents evolve much more frequently and there were dozens of HA addons that simply gave up updating their regexes extracting certain information from HTML and emails.

Ah, but now we have LLMs that can understand human interfaces without manual tweaking!

This is very good news.

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!

So, and assuming it is true, we now know which company not to buy appliances from.

For me is a call for boycott on one side, a call for class action in EU because such demand means:

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

I hate home automation! I hate home automation!

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?

Not sure if you mean bulbs or strips. For bulbs, most of IKEA's smart home stuff is Zigbee, supported by HE community drivers, and is priced well.

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.

[1] https://community.hubitat.com/

I’m really worried this will become common practice. We MUST fight against this otherwise they will take away open source from us. Making an integration to work with devices you own is NOT ILLEGAL. I’m happy to contribute to a qualified and trustworthy gofundme to protect devs. I myself have a few integrations I made and would refuse to take them down. Granted, I intentionally don’t use any “cloud” api garbage.

not only will it be common practice but likely also the law.

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.

What legalization is that? That's atrocious and only serves to fuck the end user.

legislation?

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:

https://news.ycombinator.com/item?id=38818734

https://news.ycombinator.com/item?id=38787005

Everyone working this space should include the following in their headers:

  * 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

This will deflate their legal team's attempts to exploit common ignorance when the code is admitted as evidence.

Haier (at least this product in the EU) doesn't have a published/public API.

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

So? If you don’t want people using your APIs there are ways to block them. If it’s public, don’t complain.

That's exactly what Haier is doing, just via legal means than technical ones.

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.

Haier is abusing the threat of legal action that’s not the same thing

Design a better api, bud. If you can't deal with all of your users using the product you sold them, the product you made is trash and your users deserve a refund.

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.

> Design a better api, bud. If you can't deal with all of your users using the product you sold them, the product you made is trash and your users deserve a refund.

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)

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

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.

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

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.

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

Yeah right.

I have data to back this up (at least for our products), do you?

Reply on news.ycombinator.com