I wish there would be an appliance manufacturer that would actually hire developers to create and maintain Home Assistant.
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?
Thankfully we have a (fairly) accessible API to the cloud side.
TBD on what (if anything) matter will change.
I've long advocated a local HTTP interface for our products, but usually a losing battle.
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.
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 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. 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.
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.
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.
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.
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.
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.
Doing what you suggest would require them to respect software enough to bring it in as a discipline alongside mechanical and electrical engineering.
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...
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. :)