Smart Home 2023Q3 status: still for hackers only if you want more than a few lightswitches that you can just toggle from your phone, and even if you do want that, stick to one vendor + system only.

Highly recommended: Shelly gear, it is easy to configure and seems to be rock solid, I've got a bunch of their remote control radiator valves, several remote control relays and a tri-phase consumption/production meter. It all worked flawlessly since installation. And instead of a regular Pi I got one that was built into a keyboard. It was mostly because I couldn't get a bare one but in the end I think this was the better option.

I had something similar. Rock solid. Wired back haul. Nice manual. I knew it wouldn’t add $$$ to the house but I was a little surprised to find out it actually put a lot of people off. It had negative value as I had to rip it out and go analog.

Even nerds looking at the house wanted to do their own thing not maintain someone else's ideal and normies refused to spend ANY mental energy on understanding it.

Was eye opening!

But your point is well taken and I'll be sure to introduce the subject at the handover if it ever comes to that.

Energy efficiency was my main goal too but no one gives a fuck about that here either so it’s a different market.

What also helps is that the whole system runs without any user intervention. The manual is mostly aimed at people hired to add stuff at some point in the future, or in case something breaks.

Tapping that option should bring up a dialogue that lets you migrate to a different channel with a warning about how some devices may not automatically migrate and will need to be removed and re-added if so.

But congratulations on getting it to work.

I bought a SkyConnect adapter to support HAOS, but it's probably going to be unused for at least another year.

And yeah, it'll be another year or two before Matter/Threads really starts picking up steam. I'll just pick up a new dongle when there's 10 of 'em in that same timeframe.

(Disclaimer: my house is 800 sqft and I don't share any walls with neighbors. Zigbee is SUPPOSED to be mesh and Just Work assuming you have enough devices, but I can't speak from experience on that front.)

[1] https://news.ycombinator.com/item?id=37667266

I’ve never dealt with Matter, though.

Every plugin that is in that store must have a custom_components folder.

Drop that into the bind-mounted volume holding HA's configuration.yaml and restart. HA will pick it up automatically, and you'll be able to install it in Integrations and Devices.

Frankly, being anything other than super paranoid is almost a little reckless.

Also, shit-talking Home Assistant is a pretty weird take. I wouldn't write it in Python configured half in YAML and half in SQLite either, but ... not having to write it myself was the fun part.

Anyone who really complains about curl | sudo is just doing it for nerd points, because I guarantee you they happily install all sorts of other software without "vetting" it.

And if someone caught someone doing trickery it'd be big news.

If I don't trust the website to do curl | sudo bash then why do I trust the software that I would eventually install?

Even the old argument of "middleware devices modified the script en-route" is mostly removed by HTTPS everywhere.

And there are people like you who actually look at the script (and the compiled code, too!) to find things, because if they do find something in a script as big as HomeAssitant, they'll be famous.

And there’s nothing wrong with using port 80 security wise. Binding a port doesn’t mean you’re opening it on the firewall for the world to see. Plus if you’re opening some port on the firewall, what port you use doesn’t matter - it’ll be scanned by an automated scanner shortly regardless of port.

1. browsers don't even attempt encryption,

2. the port could be open to the world, and

3. lots of people are already running more meaningful shit on port 80.

Seriously, you want to sell me a lightbulb that needs root access and then opens an unencrypted port and then makes outbound calls...? Are you nuts? That's beyond lazy design. It's almost like an intentional insult.

[edit] If you set up a home service on your local network, surely you can also bookmark the obscure port number next to the 128/ address in front of it. The only purpose served by turning your light bulbs into a beacon from hell on port 80 would be letting strangers totally penetrate your house. What happens if you start up a webserver? Do the lights go off?

What kind of schmuck does this to his house??

2. If that's the case you have major issues going on which are irrelevant to the port chosen

3. On a single IP - so what? Every device can open it's own port 80 on your LAN without any conflict

> Seriously, you want to sell me a lightbulb that needs root access and then opens an unencrypted port and then makes outbound calls...? Are you nuts? That's beyond lazy design. It's almost like an intentional insult.

This doesn't make any sense. Are you talking about a single light bulb or actual orchestration software? Both need to communicate to actually do anything.

> edit] If you set up a home service on your local network, surely you can also bookmark the obscure port number next to the 128/ address in front of it. The only purpose served by turning your light bulbs into a beacon from hell on port 80 would be letting strangers totally penetrate your house.

This also doesn't make any sense. There is no reason a device on your local network listening on port 80 makes it a 'beacon from hell' - because again, listening on LAN & WAN are 2 very different things. And the port it's using has 0 bearing on security.

> What happens if you start up a webserver? Do the lights go off?

Absolutely nothing - because again there is no conflict with different devices on your LAN using the same ports to listen on.

You're mixing up a number of different things here & making issues where there aren't any. A device on your network opening port 80 doesn't magically make it accessible to the world for poking & prodding or result in any conflicts that cause things to stop working.

And when it comes to orchestrators like Home Assistant - you can choose any port you so desire. But changing the port doesn't make it any less or more secure.

"Oh, that path is actually not a temp directory and requires permissions different than the user account?" - sudo

"Oh your firewall blocks my outgoing telemetry data?" - sudo

"Oh your firewall blocks my localhost request but I don't actually realize that's what happens but when I try it with sudo it just works everywhere?" - sudo

There are myriad reasons apps want root access, and almost none of them are good reasons, but that doesn't mean it's not simpler for them to get sudo from a user than it is to get dev eyes addressing (let alone understanding) the nuance.

I'm not sure why I'm getting downvotes here... is there some cult of people who love installing apps with root privileges?

Or maybe the downvotes are because everything I was saying was conjecture / hypothetical anyway, and you're now asking a more specific question to the general question being answered.

I thought the question was "why do apps that don't need sudo request sudo?" And my answer was "perhaps because it's easier to fix permissions problems by getting permission for everything than it is to get them by understanding why your app is getting blocked by them in the first place." Whether it's inbound or outbound or taking video surreptitiously doesn't really answer the question of "why, if the app doesn't actually need it?"

At any rate, I don't actually know why because I don't ask for permissions that I don't need. I also don't know why you're getting downvotes as I didn't downvote you: this answer, like my previous one, is speculative, as is somewhat inevitable when trying to answer "why" questions that relate to the motivations of others.

Maybe more interestingly: I do think that the motivations of others are totally calculable. Society is an autocomplete. One big honkin LLM replete with all the hallucinations. Pretending to be a member of this society is to pretend that I wish to better understand why I'd be downvoted for a thought - to pretend that it's just me, a neuron, looking for back propagation. Yay for the neuron.

Nevermind, it's not important anyway. (Life).

"Running a software installer" in general seems just as insecure as "sudo | curl" whatever.

It’s good practice to check anything that you’ll pipe to `sudo`, but this article’s level of paranoia is kind of self-defeating, no?

At some point, we all trust the things we run on our machines. We rely on communities — and our participation in them — to vet installations.

There is no perfect solution. Someone will always be misled.

I periodically get told that a published browser userscript of mine is malicious or suspicious in emails simply because of the cautions and wording around the userscript installers themselves (it's just a css tweak, a theme), meanwhile the executables I have in the wild have generated zero similar feedback.

my theory is that since the script is more easily read that it attracts people to read it without any theory or knowledge of what they're even looking at .

Where something that can be verified gets more scrutiny than something that can’t.

Maybe someone else knows.

  $ curl https://whatever/foo.sh > foo.sh
  $ sh foo.sh

After

  $ curl https://whatever/foo.sh | sh

  $ curl https://whatever/foo.sh > foo.sh

Since it takes an insignificant amount of effort to defend against this why not get in the habit of doing it?

[1] https://news.ycombinator.com/item?id=17636032

I'll take a properly curated package in flatpak Fedora repos over a random script downloaded and piped into a root shell any day

Her. Rachel is a woman. Pretty knowledgeable and experienced, too, so I would at least consider what she's saying.

  tiny_installer.sh

  #! /bin/bash
  curl www.url-you-didnt-check.dev/the-real-installer.sh | sudo bash -

Even Microsoft has this published for the dotnet install tool:

  curl -sSL https://dot.net/v1/dotnet-install.sh | bash /dev/stdin <additional install-script args>

If the answer to cloud enshittification is “I know! I’ll use a different company’s solution instead of this open source project because I want to make an outdated stand against curl|bash” then I think the thought process is misguided.

Last I checked, the bare metal pip3 method was "always" going to be supported. So the "Just use Docker" comments ignore this.

The author complains about a lack of product leadership at Phillips, but HA has always been renown for ignoring their users.

All that being said, I find it a little odd that this article is somehow decrying HAOS as a worse alternative to a proprietary, anti-user black box developed by companies trying to squeeze more profit, just because they played fast-and-loose with some shell scripts at some point. (Aside: I just installed Homebrew on a new Mac today, and it's still just a curl | sh)

Most of the major consumer IoT vendors have had major security incidents (Wyze, Hue, Nest, Arlo, many others), and if nothing else, my little HAOS Rpi gets a little obscurity compared to the big names getting hit by script kiddies. Not to mention it's easy for me to keep it local-only and just join it to my Tailscale network.

But given all the allusions to HomeKit, I suspect the author has total faith in Apple to do it right (not a wholly misplaced assumption) and wants everything to just talk HomeKit.

Which we might actually get (in practice) as Matter makes inroads! Hell, I'd love for everything to talk HomeKit because HA can emulate a HomeKit Controller, and that means less cloud APIs. Win for everyone!

I'm running the docker container (since I already had a home server running docker containers), but a NUC with HAOS for my folks has been working great.

HA is one guy's pet project to goof around with the latest and greatest technologies.

Sure, don't do that as is - But it's not hard to just curl the script, read it to confirm it looks okay, then run it.

But every single other reply seems to be either “well yeah obviously read the script first” or “how dumb, just use docker,” so like I said, maybe I’m the dumb one.

I love Home Assistant, but I regularly find myself opening the Hue and Lutron apps anyway. And I’m someone who runs a NUC. I don’t mind administration, but I don’t want to HAVE to do that when I’ve already paid for a thing that supposedly does most of that.