Great to see the detailed tutorial, which reminded me of this forum dedicated to Antenna R&D (mostly for TV and FM Radio but also other types) that has a wealth of info on DIY techniques, physical structures, fabrication, theory, testing, etc.
Great to hear! And if memory serves correct, long time no see (Belgium like 11 years ago? haha) :) the Greek Mozilla squad was tons of fun to hang out with, super interesting discussions that day- project I mentioned briefly back then got awarded by NASA one year later, wish what I did was half as impactful than what you guys got going on at Libre Space though! Hope all is well
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.
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.
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 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.
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.
> '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.
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.
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.
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.
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.
Even the event where they demonstrated the battery swap was so fake, I guess people weren't as aware of how brazen he was to not question it at the time. Couldn't set up a camera to show your own demo at a staged event? But it got them some taxpayer dollars so mission accomplished https://youtu.be/H5V0vL3nnHY
true, the way I see it, we need libre software, hardware, data but IMHO we also need lots of people from diverse backgrounds (professional, cultural, you name it) to share these ideas into the public sphere.
Vitalik is a businessmen, I do not see a hacker spirit inside him. I suppose this is some PR campaign promoting him as an intellectual, but usually this word means something more than running a successful business and writing a blog about technologies in cryptocurrencies.
The PR campaign is for crypto to have a public intellectual and thus appear more credible. He is currently their most suitable candidate, and he does make efforts to be seen as such, writing about broader topics than crypto currencies. However he is completely shallow and remains invisible outside the crypto bubble, showing no talent or strategy that would make things otherwise.
