A kernel developer plays with Home Assistant | Hacker News Reader

A kernel developer plays with Home Assistant

lwn.net

195 pointspabs3214 comments

Please note this is a two-part series. The second part can be read here:

https://lwn.net/SubscriberLink/1017945/93d12d28178b372e/

Someone posted that URL as a separate submission shortly after this was submitted, but rather than splitting the discussion, we've merged the comments here so it can all be discussed as one topic.

Founder Home Assistant here. Want to chime in that I always love to see write ups like these to see the great things what people achieve with Home Assistant.

Not everyone might know, but last year we started the Open Home Foundation as a non-profit in Switzerland and I donated Home Assistant to it[1]. It's fully funded by users. There are no investors involved.

We are fully committed to building out a smart home that focuses on local control and privacy. Yes there are rough edges, but we're actively working on it in the open, with progress being released every month.

~Paulus, Founder Home Assistant & President Open Home Foundation https://github.com/balloob

[1]: https://www.openhomefoundation.org/blog/announcing-the-open-...

Is it possible to donate to your foundation via some kind of a subscription?

I have a Nabu Casa subscription, but I don't really need it.

> I have a Nabu Casa subscription, but I don't really need it.

Shame there’s no way to donate it.

I mean, if you're paying for the subscription but never use it that's effectively a donation, right?

OP explains their motivation for not accepting small donations in another comment:

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

I think baby_souffle might have meant a way to donate the subscription to someone else.

Ah, that makes sense. My brain inserted a "to" before "it".

> I donated Home Assistant to it[1]. It's fully funded by users. There are no investors involved.

I cannot thank you enough for this. It was a bit risky adopting Home Assistant for everything ~two years ago, but that you guys did this move really makes me feel less scared about eventually having to replace it with something else.

I'm subscribed to Home Assistant Cloud (via Nabu Casa) even though I don't use it just because it seems to be one of the few ways to financially support you, is there any way of doing one time donations to the foundation itself?

It seems that's the only way according to their "support us" page.

https://www.openhomefoundation.org/organization/#support-our...

We don't want to come to rely on donations and have to show Wikipedia-style beg banners in our app (I would personally hate to see that myself).

So with the limited resources that we have, we currently only consider bigger donations valued $10k or more. We've had monetary donations from DuckDuckGo and Espressif so far.

I didn't get the begging feeling from using Blender, though it has been some years ago. IIRC they focused on donations for specific features and showpieces like their movies.

As a very happy Home Assistant user, hopefully you can manage something similar so you have enough money to stay afloat and keep up the good work.

Maybe you could allow people to pay more for Nabu Casa?

beg banners or awareness campaign.

I never had issues with that.

smart homes dont work because wifi doesnt work. almost every user is running low quality hardware or does not deploy a meshing AP to reach the devices. the devices are not resilient to lost packets and high latency

just change a wifi ssid with smart devices in a home and watch it all crumble. users want nothing more than to get rid of “smart” once they realize its not smart enough to figure out how to change wifi networks.

endless “updates”, rent seeking, breaking changes, account setup - its not worth it.

when you last complained about Torvalds rent seeking lol.

There are WiFi alternatives.

You don't have to use WiFi, this whole argument is just invalid. Use Zigbee instead.

You should check out Home Assistant and the vast range of ecosystems it integrates with! There a dazzling range of radio standards and manufacturers that have considered the problems you’re describing.

You could (and I understand many people do) run an entire smart home without any WiFi at all, if you’d like.

Home Assistant is free and open-source, and I understand from his comment above that their founder generously donated the project to a non-profit foundation to sustain it that way for the future.

Which is awfully reassuring with respect to the rent-seeking incentives you’re worried about.

Only my "smart" water heater communicates over wifi. The rest use Z-wave or Zigbee. I know at least Z-wave has from the start had the ability for devices to be programmed to operate without the controller.

So if the controller falls out or you don't have one you can still have your buttons toggle lights etc. Controller or no controller, in either case it works just fine without wifi.

Who is "just" changing their Wifi SSIDs?

Like my parents wifi SSID was set when I was in high school and 20 years later it's the same.

But if it did change, all the devices just setup a temporary AP and wait to be told the new one and the password (the temporary AP is also password protected).

Do you plan to fix https://github.com/home-assistant/frontend/issues/18549?

The real magic is in my opinion in ESPHome. The fact that you can amateur solder some aliexpress $2 sensors together and have that actually work in HA with no coding except some yaml that you found on the internet is wild.

>It would be interesting to see what would happen to a pull request adding support for, say, OpenThings Cloud as an alternative. The fate of that request would say a lot about how open the project really is.

I kinda hope nobody tries. Their attempts at monetization have been pretty friendly and tame thus far & if something spooks them that could change.

> I kinda hope nobody tries. Their attempts at monetization have been pretty friendly and tame thus far & if something spooks them that could change.

To be fair to them they've been making a big push on adding backup support recently. Their Nabu Casa subscription has built in support for this and was a major selling point for me getting the subscription (I have Wireguard for remote access already).

At the same time they implemented first class support for their own subscription, they added the hooks for other integrations to provide the same level of backup support. Now you can easily choose to use Google Drive, S3, BackBlaze and others just as easily as Nabu Casa. In some ways it's "better" as Nabu Casa only supports a single latest backup.

From this they seem pretty friendly and not too interested in lock-in.

Unfortunately their new backup support forces encryption; that makes sense for cloud-based backups but not for local (NAS etc.) ones. Requests for that just get replies to do it with manual backups the old way.

Why is that unfortunate? Encrypting backups is just a good best practice in general.

Because that means I need to manage the encryption key (which is a file, not a password). It makes it harder to do restores because I need to dig out the key.

I don't have anything I care about in the Home Assistant install to need encryption; if you have access to that you are already in the network, same as the actual running device.

It is unfortunate if you want to deduplicate and encrypt in the target backup.

Unencrypted backups is an option.

Yeah ESPHome is magic. I set up a full home humidity monitoring setup for the cost of a soldering setup + approximately $0 on components. No subscription bullshit, no proprietary interface bullshit, just exactly the setup I want and it was fun and easy to build!

Same. I had a couple extra ESP boards from an order where I only needed one, an extra breadboard and humidity/temp sensor and decided to finally measure the temp out in the greenhouse. It's amazing to have all that in a grafana dash running on a r pi.

Do you (or anyone!) know a good tutorial / series / blog how to get started with home automation?

I'd say install home assistant, and get a device that runs ESPhome, so you can tweak it. Unfortunately I don't really have anything more specific than that, but I agree that ESPhome is great. You solder some stuff, define the pins in the config, and everything works.

ESPHome is really cool, but it's still missing power management last I checked, which is the main reason I don't use it these days.

I'm not sure why enabling automatic light sleep isn't like, priority #1 for Arduino, but I guess there's some subtle issues where it might break certain sketches or something.

Because realistically none of the hardware used even supports deep sleep correctly and will drain the battery using their high quiescent current LDO regs, pull-ups, LEDs and vBat dividers. Also latency and energy cost of getting back on the network, waiting for hass server to connect (in esphome protocol devices are servers, not clients) and going back to sleep is only going to work for some weird edge scenarios where you don't care about latency or polling rate.

Automatic light sleep maintains a WiFi connection with only 1 or 2 milliamps, I'm using the exact same ESP as server model but with Websockets, and it all just works.

There's even some PRs for automatic light sleep I think in ESPHome, but they're not merged yet.

Bit of a late reply but check out sensor HLK-LD2402 if you haven't.

Think presence detection except the range actually works. Reliable and fast between 30cm and couple meters

The ESPHome Bluetooth Proxy is amazing - no faffing with Bluetooth on Linux (which remains a shambles) needed!

Even though ESPHome has warnings about using WiFi and Bluetooth proxy together being unstable, I've found it to be much better in terms of stability and performance than the Intel Bluetooth adapter connected to my Home Assistant system. BlueZ is probably more complex and less mature.

ESPhome runs my whole house now basically.

It's the HA system I've always wanted and the only way I would ever do it: everything just speaks regular IP, has a web interface, and lives on an isolated Wi-Fi network.

Well clearly he did not look under the hood ... I did. A few technical decisions are ... questionable. But it's prohibited to ask why in the forum. HA could do well in cleaning up its community that can be particularly toxic, especially toward advanced user and start accepting critics. The hostility one face when they don't want to follow the "dumb down version, do as we say" installation process is really off-putting.

Its not prohibited here. What technical decisions are questionable?

Yes it's prohibited I posted a few corrections (one positive , one negative) to his technical review, and it got downvoted, as will this probably....

I wouldn't consider downvotes to mean something is prohibited. I did in the past because that's what I limited myself to downvoting, but people just downvote what they don't like for whatever reason. All you can do is to not let it get to you.

"prohihited" implies an official rule enforced by the community organizers. Downvotes are an expression of opinion by community members.

Home assistant supervisor is not very friendly. It's designed so that it must be kept up to date, and handles it's own auto-update features. It also won't run nicely in a docker container with some significant hacks. This means that the only deployment option if you want a complete home assistant install is to use their "Home Assistant OS" or specific debian versions.

Generally it feels like they're making deploying it as hard as possible, doing stuff like checking if supervisor is running in a docker container and just not working if it is.

This is presumably born out of frustrations with users deploying it incorrectly, but there really is no reason a supervisor based HA install can't run in a docker container. I've got a some private hacks doing just that, that I'm hesitant to post publicly in case they find some way to break it.

No idea what the obsession is with keeping a full home assistant install from running in a container, but it's very strange. Trying to add more friction so they can sell more of their dedicated hardware? Their hardware is nice and stands on it's own, the only reason I don't use it is because I want to run on an old touch screen chromebook for very low power usage.

I've been running home assistant in docker for years. Just the `homeassistant/home-assistant` image. Don't need anything more. Best I can tell is that the supervisor is for people who just wanted a managed home assistant in a box setup at which point it's fair for the software to take over the system.

Supervisor is more or less required for some pretty critical add-ons.

Such as? Only one that comes to mind is ESPHome, and I run that separately just fine.

NodeRED is a complete PITA to set up outside of supervisor. It requires extensions on both ends, and it passes the auth in a weird way.

I'm running NodeRED and ESPHome in their own docker containers, integrated with home assistant, just fine. Never used supervisor. It's been a few years since I set them up so I don't remember the details but that also means it wasn't anything notable. They've been stable since.

Do you have it embedded in the Home Assistant UI, and using HA user credentials?

I have HA install in container for a few years - not sure what's "critical addon". Some are helpful, but they're easy to run independently.

I wanted to hate this aspect of it, but since I like Debian and and use it as my daily driver on a lot of systems anyway, I just couldn't work up enough ire to complain.

Debian are working on packaging HA stuff btw:

https://wiki.debian.org/Python/HomeAssistant https://wiki.debian.org/HomeAssistant

> Debian are working on packaging HA stuff

Which is part and parcel of distro-maintainer duties - someone has to deal with the complexity, between the upstream project, linux distro or the end user.

Complaining that the upstream project won't support specific configurations or installations reads as incredibly entitled to me, especially for projects like HA or Pihole that aim to be useful to folk who may not know how to fix package dependency issues, fix a broken install, or many other such foot-guns. This would be a magnet for unpaid support.

If one is knowledgeable enough to complain about installing onto an existing install, then one is likely skilled enough to know how to side-load the app and debug and resulting challenges. It's worth noting the upstream provides the installation artifacts!

As one example, they (core contributors and founder) were, and still are, very heavy-handed regarding how you are allowed to install their software: https://news.ycombinator.com/item?id=27505277

Wow, how pathetically obnoxious.

I was going to purchase a Home Assistant Yellow for my homelab, glad to know I need to minimize my interaction with the project before I pulled the trigger.

Will be sure to inform others using the project about this too, they deserve to know its a risk to rely on a project with such hostile core contributors.

Truly "Open Source" in name only (OSINO?)

I have HA running for years (in Docker) and it’s very reliable.

It has integrations with allmost all devices or apps I use and the support for DSMR (Smart Electrical Meters) is first class

I plugged a cable into my meter, the usb end into the server and it just works.

It does have a steep learning curve, though. It really seems “by IT people for IT people”

I have it in docker a d use supervised mode (which seems discouraged, but I want my machine for other uses also). The one thing I struggle with is updating, I'm concerned if I update it'll break. Is there a way to fully snapshot a container state and it's disk state, so I can 100% restore to it if something goes wrong ? I'm still running HA from 2020 because of this.

The other think I'm not a huge fan of is it's template language, it's clunky to say the least, but overall it's a great amd flexible system

I just backup the folder (volume) and that’s it.

If I should ever need to rollback I can change the Docker image tag from ‘latest’ to a specific one I guess.

I’ve never had to do it but I do know people sometimes complain about updates breaking things.

I’m running it with docker compose for the same reason and it never failed an update, but there was an occasional config tweak required. For the most part it’s compose pull, compose up, check back in a couple weeks for the point release.

Updating from that far is probably risky but you don’t need to backup everything, just the config directory. Automated backups to Google drive are worth the upgrade alone.

In the last few releases they've polished the built in backup and restore features, which are available in the setting menu now.

https://www.home-assistant.io/integrations/backup/

> Is there a way to fully snapshot a container state and it's disk state

`docker commit` should help you there, in making a copy of the container

All the persistent storage is in the host directory path you map into the container. Just backup the directory you're mapping into the container. Don't try to save the container state.

some filesystems support snapshots for directories. your software does not have to have "compatibility" for it, it just works.

with BTRFS you can even mount/work with multiple snapshots of same directory at once. it is great for debugging.

deduplication will save you space.

Could run it in a VM instead.

It used to have a steep learning curve, I’d say. Once I’ve had a long complicated manually written configuration of all my devices, integrations, automations etc, which gradually got replaced by simple clicking in the gui. On the other hand, this also meant a lot of breaking changes over the years, when I had to re-configure my staff the new way

Something that annoys me a lot with recent versions of HA is that it does not play well anymore with yaml file configs. Your are mostly forced to configure things through the interface, that is ok but might be annoying and painful to do when you have a few devices with a little bit more complicated setup.

For example, I wanted to replace a light bulb by another one that has a different Mac address to replace another one exactly. Before it was as simple as changing the Mac in the config file. No it is more complicated.

Also it was very easy to review and backup the config files. Now it is less obvious.

My friend uses self-hosted open-source software to monitor all his home IoT devices[1] and copies important information to the cloud. I'm using StarFive VisionFive 2 to host my database for monitoring, but also have a copy of the data of a chip hetzner arm vps, as well as hosting backups on the two different clouds. I know users who are running[2] for years to monitor Solar panels, lawn watering and vegetable garden watering.

My question is: is it really convenient to use only SaaS now if there is always the possibility of losing your data? I am referring to the case described in the article.

[1]: https://vrutkovs.eu/posts/home-infra/ [2]: https://github.com/VictoriaMetrics-Community/homeassistant-a...

PS: I'm working at VictoriaMetrics company

in recent podcast episode with the found of your company ( https://www.youtube.com/watch?v=8xkCykuJwKs , От стартапа до международного бизнеса: история VictoriaMetrics и её уроки | Александр Валялкин | #36) he explicitly described the path VictoriaMetrics has come and one of the early steps was trying to sell SaaS, while quite a lot of users/customers want to have on premise/own setup for such tooling.

So, answering your question: > My question is: is it really convenient to use only SaaS now

no, it's not

At some point a company is going to start making hackable, local connection devices (cloud optional) with published APIs and sell them at a higher price tag, and they’re going to be fabulously wealthy, commanding higher margins than the others.

At least, that’s what I like to tell myself.

There is Zigbee, Z-Wave and Matter. These are all smart home standards that are fully local and devices will be able to be set up and used even when the company goes out of business. You are however limited to the things that are standardized.

If you want to go a step further, look for devices made for ESPHome or devices made by Shelly. Both have local APIs and are very hackable.

(disclosure: I am the president of the Open Home Foundation and ESPHome is one of our projects and I am also a board member of the Z-Wave alliance)

> There is Zigbee, Z-Wave and Matter.

I am not a practitioner, but instead someone that looks at the ecosystem from time to time and has been waiting for a while, because I dont see the stack + DX/UX that I want yet.

Zigbee never reached critical mass and requires a hub. Z-wave seems to be the same. Thread over wifi (IIRC different protocols/transports are just fine) is what I think will be the future.

IMO Thread wins out, support gets put into routers, and I can just have a thread enabled router which MAY have other

I don’t want to buy an IoT hub. Many IoT devices I want to control are powerful enough to run Wifi, and I want to control them with a standard networking stack with high adoption and familiar tooling. Thread seems to fit this use case the best.

Please feel free to rip apart the above opinions, they’re loosely held. I’d love to learn how wrong I am today!

> If you want to go a step further, look for devices made for ESPHome or devices made by Shelly. Both have local APIs and are very hackable.

Thanks for the recommendation! Appreciate the disclosure and apologize for the blast of relatively uninformed opinions.

One more side question — why is it so hard to get a simple IoT button that runs local Wifi (really hoping for no base station) only and is battery chargable?

Buildable with an ESP32 clearly but I just want to buy this.

Maybe not exactly what you are looking for, but check out the Shelly BLU Button1. It's a BLE button with a long battery life.

It sends out BLE packets when pressed, which can be picked up by Home Assistant via a Bluetooth adapter or using a Bluetooth Proxy. You can make the latter with any ESP32 and https://esphome.io/projects/?type=bluetooth

Thanks for the recommendation! This definitely makes it easier. IIRC BLE power mode + wake on BLE + wifi would probably work for easy use!

Sounds like a far off weekend project

BTW, just bought a bunch of Shelly stuff. Looks like that project might happen sooner than I thought! The Shelly 1 also looked like a good option :)

Thanks again for the rec.

With Thread+WiFi, can devices talk to the internet? Because denying them that ability is a lot of why I like Zigbee/Z-Wave.

Wifi yes. Thread depends on the settings on the Thread Border Router. Ours defaults to no internet access.

I’m sure I’m speaking to the choir here but access to Wifi != access to the internet!

Why I’m excited about thread over wifi is that I don’t need any extra specialized gear and possibility one device could run by itself

While true, it's really hard to shop for devices that have access to WiFi without internet. It's too easy for the manufacturer to slip in the internet requirement and not put it on the box. Using other protocols makes the expectation disappear.

This is a good point I haven't considered until now. Inability for the ad-supported model to ever sneak in.

Now I'm really wondering why over wifi didn't take off.

ZWave is the most stable radio-based standard right now. It's not great, and it's not very extensible, but it's OK-ish. There's one hackable device: https://z-uno.z-wave.me/technical/ but its SDK is not that great.

Pure ZigBee is... spotty because there are no certification requirements. Matter is stuck in development hell, but is slowly getting better.

And the problem with WiFi is energy efficiency (or a lack thereof) compared to ZWave/ZigBee/Thread.

So far, I've tried probably most of the home radio standards. Lutron was the most reliable, but it's also super-proprietary. My next house will just have conduits with low-voltage cables running to all the light switches, so I can use something like KNX instead of the radio-based stuff.

> And the problem with WiFi is energy efficiency (or a lack thereof) compared to ZWave/ZigBee/Thread.

This is a problem I'd really like to solve the old fashioned way/I think it prevents too much building. Energy density, rechargability, etc are like CPU speed to me -- it will eventually be solved, and I can deal with replacing a device every month or swapping a rechargable battery (especially if the device can tell me it's low).

I really do think it will be Thread+Wifi routers that eventually get a built-in Thread antenna that win (at least wining me over).

If either ZWave or ZigBee had managed to get into the home router space, they would have won already IMO. There are probably annoying reasons they couldn't until now.

> So far, I've tried probably most of the home radio standards. Lutron was the most reliable, but it's also super-proprietary. My next house will just have conduits with low-voltage cables running to all the light switches, so I can use something like KNX instead of the radio-based stuff.

Thanks for sharing this and your other experience!

Also TIL KNX.

> I really do think it will be Thread+Wifi routers that eventually get a built-in Thread antenna that win (at least wining me over).

That actually had been the case for a while. A lot of WiFi routers had a built-in Thread (ZigBee) radio, but then nobody actually used them and the manufacturers stopped bothering with them. So now pretty much only Eero access points still have it.

> Also TIL KNX.

My dream is to have _actuated_ switches, that have full tactile feedback. So that the paddle will physically flip when switched remotely.

I commissioned an engineering company to look into that, but apparently this is not feasible at all with the NEC and UL requirements in the US. The only way is to use low voltage wiring to the switches and then use them to control line-voltage relays. This kind of system is popular in Europe, so you might as well just go with something like KNX.

> That actually had been the case for a while. A lot of WiFi routers had a built-in Thread (ZigBee) radio, but then nobody actually used them and the manufacturers stopped bothering with them. So now pretty much only Eero access points still have it.

Thanks for this context -- when I searched I only found "thread border routers" -- I couldn't find a router made by a well known brand that included thread functionality -- it always seemed to be "buy a router AND buy a thread border router".

Really surprised that I missed the wave on this and wonder if it was a "we want people to buy two things" rather than no one actually using it. Maybe I just have to wait for it to come back around?

Maybe the answer here is a USB powered device with an extra 2.4Ghz radio (running like.. OpenThread or whatever I need to do thread over an available antenna?) attached to the router?

What I don't understand is why I just use the existing router's 2.4Ghz antenna for this? The amount of confusion in the space and inability of devices to do multiple things is really annoying, to be frank. I can only surmise the reason this stuff is not easy/obvious is profit-incentive (outside of the difficulty of designing good standards of course!).

[EDIT] OK, so the antennas aren't the same, despite being the same frequency -- clearly this is to ensure speedy operation at the hardware level.

So the add-on antenna would probably work if I bought some parts from mouser:

https://eu.mouser.com/c/passive-components/antennas/?protoco...

[EDIT2] Nope, more confused. Multi-protocol antennas exist. Why is this not a set-and-forget option for all the routers??? Someone clue me in to the politics/power struggle or whatever the real reason is here. And then connected + taped something to my router.

> Really surprised that I missed the wave on this and wonder if it was a "we want people to buy two things" rather than no one actually using it. Maybe I just have to wait for it to come back around?

It's worse. There are _no_ new stand-alone Thread Border Routers on the market. You might find old stock of GL.iNet routers, and I believe there were a couple of other experimental devices.

If you want a robust Matter network, your best bet is to use Apple or Google devices as border routers. Or you can use a USB ZigBee stick with HomeAssistant.

> [EDIT2] Nope, more confused. Multi-protocol antennas exist. Why is this not a set-and-forget option for all the routers???

No market demand, so router manufacturers just don't bother. The initial versions of Matter were a burning trash fire.

Thanks for the color here -- sad but I get it.

Sounds like we're almost there and Zigbee/Thread are at least supportable with the same hardware. I can work with that I guess!

> No market demand, so router manufacturers just don't bother. The initial versions of Matter were a burning trash fire.

I remember hearing about this -- they fixed/improved it eventually but I guess the damage was done.

Hang on I'm curious: why can't such a thing be built with a wifi/other radio in it?

The UL requires a switch to be able to physically break the connection in a way that can't be actuated remotely. So the switch will need an additional physical cutoff switch. Which is funny, but workable.

The deal killer is the power dissipation requirement. A solenoid, both compact and powerful enough to actuate the paddle, will dissipate too much power if it gets stuck in the "on" state. And a small geared motor is not acceptable because the switch has to be bi-stable and can't be allowed to get stuck in the middle.

So if you do an integrated device, the paddle will just end up being an input device, rather than an actual current-interrupting component. And there just isn't a lot of space inside a switch for everything without going into Apple-like engineering.

But that would be fine. The biggest problem is not whether a relay in the switch would fail or not, it's that you want the wall switch position to be tactile and to reflect the state of the switch.

Yes, it might be possible, but also expensive. But there just isn't a lot of space available to support both a good tactile feedback, and to be able to interrupt the line voltage. There are requirements for high-low voltage separation that are difficult to meet, while staying within the allowed size for a switch.

Since I'm doing it for myself, I will selfishly just do a low-voltage system :) But I'm seriously considering funding a startup to do engineering for an integrated version.

The closest thing that I found to a _good_ smart dimmer was https://www.alibaba.com/product-detail/Zwave-Zks31-Knob-Dimm... (ZKS-31). It has a physical knob as a control, and it only misses the visual indication of the current state and simulated detents.

I'm really at a loss why nobody else is trying to do something like this, while doing crap like touch-sensitive switches with LED displays.

That is an expensive dev board for something like this…

Here is a esp32-h2 with thread and zigbee support for $5-$12

https://a.aliexpress.com/_mMfZEsX

I figure support for something like this is likely to increase faster than a $70+ board.

> why is it so hard to get a simple IoT button that runs local Wifi (really hoping for no base station) only and is battery chargable?

Battery life is atrocious and latency from deep sleep will be very bad. I’ve got Zigbee buttons from ikea that run on nimh batteries for a couple years now and only used like half of the charge. The hub is an usb dongle attached to the home assistant server, no issues.

> Battery life is atrocious and latency from deep sleep will be very bad. I’ve got Zigbee buttons from ikea that run on nimh batteries for a couple years now and only used like half of the charge. The hub is an usb dongle attached to the home assistant server, no issues.

So what do you consider to be "bad" battery life? I've got quite the tolerance, but the problem is that they don't even exist. Everyone seems to stop out on this at "it would never be worth it".

> Zigbee buttons from ikea that run on nimh batteries for a couple years now and only used like half of the charge.

This is intense for me, I'm happy with replacing batteries every 6 months if I could simplify deployment by 10x.

> The hub is an usb dongle attached to the home assistant server, no issues.

Maybe deployment isn't as hard as I'm making it out to be! That said, nothing easier than sending some packets to an IP address. I assume Zigbee APKs are easy... But for example if I search on crates.io (https://crates.io/search?q=zigbee) I don't see any obvious choices.

To restate what I want (and hopefully is sounds a bit more reasonable) I want to be able to buy one smart light bulb, configure it over BLE to connect to Wifi and for the rest of it's live configure it/change it via Wifi. I want that for basically every device, and I'm fine with swapping batteries every 1 to 6months if I could have that!

BLE should also work but you also want a dongle, so hardware wise it’s the same; ideally you also want a couple gateways (Shelly devices can do that out of the box btw, and new Shellies will be supporting Zigbee.)

You should look into zigbee2mqtt IMHO.

Yup, you're right -- looks like zigbee2mqtt is a huge unlock, hard to build without it since it supports so many things!

Not excited about having to essentially now also bring along a MQTT broker but... It's probably pretty painless to run most brokers and it's likely a single-machine-is-fine affair.

> Maybe deployment isn't as hard as I'm making it out to be! That said, nothing easier than sending some packets to an IP address.

I think this might be the case. Get a USB zigbee dongle and spend ~1 hour setting up Home Assistant and you're more or less done. Adding a new device consists of clicking a button in HA to enable permission for devices to join and then powering on the device. It will discover the network and report the features it exposes.

You can control devices via HA over wifi. Plus HA gives you an API that you don't have to maintain and update as you add new classes of devices to the network.

You'll spend far more time repeatedly replacing batteries with wifi devices than you will with configuring HA once.

Edited to add: one nice thing I forgot to mention is that using HA for your own homebrew devices lets you keep a single consistent API for those and commercial devices. You can build a little ESP32 device with custom sensors, displays, etc. and control those exactly as you would with off-the-shelf products.

Yeah these are all good points, thanks.

I really need to figure out how deep I want to go -- HomeAssistant is clearly the best off the shelf option. Maybe I'll set up HA first and then see if it really is worth trying to build something better.

thread and matter will, in my opinion, never matter for consumers. Why? It’s basically a walled garden.

Think HomeKit but a tiny bit more open, the open bit is, that a vendor can allow it to communicate with devices of other vendors. But they don’t have to.

Thread also needs more expensive SOCs, with Zigbee you only need a tiny micro controller with a few MHz of clock speed and a few KB of RAM. Thread and matter on the other hand can require megabytes of RAM.

Vendors which nowadays sell HomeKit devices can reuse their SOCs for thread matter, keeping their 3-4 times higher prices compared to devices with the same functionality from Zigbee vendors.

> thread and matter will, in my opinion, never matter for consumers. Why? It’s basically a walled garden.

I'd counter with the fact that walled gardens are incredibly popular, and in particular to consumers. Consumers don't care if the gate is locked or not, they care if the flowers are pretty and the tea at the garden party is nice.

> Thread also needs more expensive SOCs, with Zigbee you only need a tiny micro controller with a few MHz of clock speed and a few KB of RAM. Thread and matter on the other hand can require megabytes of RAM.

IMO prices of SOCs are going to zero. ESP32s are a great example of this. Once RISCV is more widely used and capable things will accelerate even faster.

> Vendors which nowadays sell HomeKit devices can reuse their SOCs for thread matter, keeping their 3-4 times higher prices compared to devices with the same functionality from Zigbee vendors.

I think we agree here...? I think that HomeKit device that is just a bit more open is going to win. But I think that HomeKit device gets adopted faster if it's just a router -- I can understand updating a router to get a smart home. What I don't want is confusion around whether I need a hub or not, or whether devices work together or not.

Buying a single router that acts as a hub + Wifi "repeaters" (IIRC that's what they're called) that can "extend" the signal (and along the way give other devices a point to connect to) makes perfect sense to me as a consumer. I already know what WiFi is, and I want better coverage, not worse. The smart home stuff just falls out of tech I am already familiar with, efficiency by damned.

Thread is a WiFi replacement, the devices talk IP over thread.

And it has an encrypted pairing process to your vendor controlled hub. Said vendor can allow or disallow it which other vendors may speak with said hub.

Here is the landscape we have: HomeKit: fully closed, requires certification from Apple. Very expensive and limited functionality.

Zigbee: fully open, anyone can make Zigbee devices and sell them without any restriction. Operates on the same frequency all over the world. Devices are super cheap. You can expand the protocol however you like as a vendor.

Z-wave: fully closed, several incompatible frequencies, requires certification to sell devices.

Thread and matter: semi closed, same ieee standard as Zigbee for data transfer. Vendors can allow it to talk to devices of other vendors. Requires certification. Same price tag as HomeKit, aka 3-4 more expensive than Zigbee.

All of them require hubs. And only with Zigbee you are guaranteed to have interop between all vendors and all devices sold across the globe. Thanks to Home Assistant. With thread the vendor can simply disallow you to use your devices with HomeAssistant, which is unacceptable by me.

Oh and, Zigbee has automatic range extension as part of its standard. Every device with a plug expands your network.

Thanks for all this context/explanation -- also the follow up. Automatic range extension (i.e. actually being a mesh and forwarding along messages) is an excellent feature.

> All of them require hubs. And only with Zigbee you are guaranteed to have interop between all vendors and all devices sold across the globe. Thanks to Home Assistant. With thread the vendor can simply disallow you to use your devices with HomeAssistant, which is unacceptable by me.

This is the one I want to push back on -- Thread over Wifi doesn't require a special Hub right? Taken with other info from this thread clearly in the real world it's not so simple to find the right hardware... but it's possible to just buy a thread device and use it over regular old wifi.

Sounds like Zigbee is closer to ideal than Thread or Thread/Wifi.

Maybe this is the startup someone needs to do -- some reasonably powered device to attack to a router/connect close to a router which supports Thread and Zigbee, has completely local management and call it a day. Is this just over-complicating a smart hub? Don't know.

Thread is using the same protocol as Zigbee, which requires specialized hardware to talk to it. You can’t get around a centralized hub when wanting to use them on your WiFi network.

Thread just adds an IP layer above Zigbee. Zigbee is on the same protocol layer as Ethernet or WiFi.

> Thread is using the same protocol as Zigbee, which requires specialized hardware to talk to it. You can’t get around a centralized hub when wanting to use them on your WiFi network. > > Thread just adds an IP layer above Zigbee. Zigbee is on the same protocol layer as Ethernet or WiFi.

AH, I've just realized that I've been using the wrong terminology.

I've been meaning to say Matter over Thread vs Matter over Wifi!

Matter seems like a decent way forward, and it can work only over wifi which is what drew me in to focusing on Matter. IIRC Matter/Zigbee isn't a thing (though it technically should be possible, Zigbee is just a transport as far as Matter is concerned right?).

[EDIT] works -> can work, Thread/Zigbee -> Matter/Zigbee

Thread and Zigbee implement the same IEEE standard.

Matter would be correctly the application layer protocol of thread and could be spoken over any transport. Like HTTP

But here comes the tricky bit, when you buy either Zigbee or matter devices each vendor will add its own extensions.

In the Zigbee ecosystem vendors out right refuse to communicate with devices from other vendors even though Zigbee is an interoperable standard.

That lead to the birth of zigbee2mqtt, literally hundreds of years of development time went into it to have full feature support for every Zigbee device that exists.

For thread and matter devices each vendor would have to do the same. And that won’t happen, leading to a fragmented ecosystem.

Welp that's depressing.

Thanks again for laying this out -- I've been seeing zigbee2mqtt everywhere and this explains why someone would add mqtt to the mix. Sounds like this is another thing that needs to be run/managed on the software side to be robust.

This is an insane goal (and who knows when I'll actually get to work on this project), but what I want to build is an all in one something that "just works". So roughly:

1. Pick a good enough physical comms stack to hit most things

2. Write software to fill in the rest

It's going to be difficult but it feels like the setup for all these tools is just hard, when it doesn't have to be if you could pin down the hardware/install instructions, then write a really decent software layer to pull it all together without making people go homelab.

That said, that's probably what home assistant devs thought before they reached the current level of complexity, I'm probably preparing to attack a windmill here.

I think my secret sauce here will be WebAssembly -- if I can nail down the hardware below, build/convert a ton of adapters via WebAssembly, and then build a compelling/easy to add/install/manage/configure UI on top of that, I might have myself something worth posting to HN someday.

IMHO, thread and matter will probably be as mature as homeassistant and zigbe2mqtt in the 2030ies. At the moment, Zigbee devices can work without any hub as long as you stick to one vendor.

Aka buy lightbulbs and switches from ikea and you can right out start using them, I believe you only need a hub to create groups of devices which then can get controled with one switch. You then could unplug the hub and still use them, only needing a hub for ethernet bridging and automations.

> Aka buy lightbulbs and switches from ikea and you can right out start using them, I believe you only need a hub to create groups of devices which then can get controled with one switch. You then could unplug the hub and still use them, only needing a hub for ethernet bridging and automations.

Yeah thanks for pointing this out -- just need a single Zigbee coordinator (if my light research has been correct so far) and I'm ready to go.

I think IKEA bulbs will also be in my future.

> Thread just adds an IP layer above Zigbee

To clarify this: Thread is not building on top of Zigbee, they are both independently built on 802.15.4

Correct, this makes it possible for one chip to speak both protocols at the same time with one antenna.

The usb stick sold by nabu casa does that.

Technically works but not well enough to move past “experimental”

> This experimental firmware has been available since December 2022. Through extensive testing, we have found that although it works in some circumstances, it has technical limitations that lead to a worse user experience. We now do not recommend using this firmware, and it will be experimental for the foreseeable future. Instead, we will focus on making sure the dedicated Zigbee and Thread firmwares for Home Assistant Connect ZBT-1 deliver the best experience to users.

https://www.home-assistant.io/connectzbt1/

They even removed most mentions of it where they talk about firmware, that’s a shame.

Does the hub requirement matter that much though? I mean if you want truly peer to peer, then yeah, but if you're already using Home Assistant you can plug a cheap ZigBee usb dongle into that.

So the bit I'm missing: how do you control them purely over WiFi? Do you run software on your phone that can control the target? Eg: app talks directly to the device over your network, instead of via a browser + Home Assistant running on a Pi. I can't think of any examples of a product that works this way without being cloud enabled (IE: there is a hub but you don't own it)

> Does the hub requirement matter that much though? I mean if you want truly peer to peer, then yeah, but if you're already using Home Assistant you can plug a cheap ZigBee usb dongle into that.

Maybe not, but I don't really want to actually run Home Assistant, I want the basics to hack on, really. Trying to pick the most open thing that will be easy to program without relying on using something like Home Assistant (not that its bad or anything).

> So the bit I'm missing: how do you control them purely over WiFi? Do you run software on your phone that can control the target? Eg: app talks directly to the device over your network, instead of via a browser + Home Assistant running on a Pi. I can't think of any examples of a product that works this way without being cloud enabled (IE: there is a hub but you don't own it)

Yeah that's my goal -- basically I want to be able to control the devices from anything web connected (and ideally, the same program running in multiple places).

My thinking is that I can build this without being cloud enabled if I "just" (famous last words) had Thread/Wifi.

With all the excellent feedback in this thread (thanks HN!), it's looking like a small SBC + a Thread/Zigbee/BLE dongle[0] is the way forward, and hooking that up to my router via USB so it's always powered and follows the router around (maybe velcro it on).

SBC (or something smaller maybe, but probably the SBC) so I can program it myself.

[0]: https://sonoff.tech/product/gateway-and-sensors/sonoff-zigbe...

The basics of Zigbee isn't Home Assistant, it's something like zigbee2mqtt with a USB dongle and then you interface directly to an mqtt broker.

For my automations I do just that and I bypass home assistant and control my devices directly over mqtt. It works very well.

Home assistant absolutely can own the Zigbee coordinator, it works very well, too (this is what I’ve been using for a couple years with the SkyConnect dongle.)

Yes, my point was just that you don't have to rely on Home Assistant if you don't want to.

> Yeah that's my goal -- basically I want to be able to control the devices from anything web connected (and ideally, the same program running in multiple places).

HomeAssistant provides a REST API for all devices connected to it. I don't even use its automation features, I just use it for the API to control my ZWave devices from other stuff.

https://developers.home-assistant.io/docs/api/rest/ (POST to /api/services/ to control remotely)

(Granted it's pretty heavy if that's the only feature you want, but hey, what you want does exist)

Oh yeah I’m aware, thanks for pointing it out. I also have zigbee2mqtt available for me for API-first interaction.

Setting up HA at least at first seems like a good idea so I can figure out the best parts and worst parts and have a baseline

> I don’t want to buy an IoT hub.

Different expectations. I don't want my things to know that wifi exists. It stops vendor lock-in, it ensures local communication, it means things work even if network goes down. It also makes sure they will never autoupdate or join Mirai botnet.

I've got a mix of zwave (fibaro), ZigBee (Ikea) and ble at home and I'm ok with that.

Yeah I think so -- I like to think I can control my router at least, so I don't have to worry about it. That said, probably not protected from the botnet case.

Also, unfortunately up until now I've been saying the wrong thing -- I mean Matter over Thread versus Matter over Wifi. Matter over Wifi seemed like a winner to me because I could just use it.

It looks like going forward I'll be plugging a small SBC into my Router's USB (+ ethernet) and connecting a Zigbee + Thread dongle. That should cover me for most communication options, then from there it's "just" a software problem :)

Same boat here, I like knowing that none of of my devices can get network access, all they can do is communicate with HomeAssistant.

And with Zigbee bindings most of my inputs are set up in a way that they still work even if HomeAssistant goes down.

Not that HomeAssistant has ever down, but I can imagine its SSD or something failing and not bothering moving it to a different computer for a few days while I get a replacement in.

> I don’t want to buy an IoT hub. Many IoT devices I want to control are powerful enough to run Wifi,

Having a lot of career experience in this area, I greatly prefer to keep my IoT devices off of my WiFi.

You don’t need a separate hub device for Zigbee or Z-Wave, just a simple USB adapter that you plug directly into your device controlling everything.

Keeping the low bandwidth IoT devices off of the main WiFi had a lot of advantages. It’s also much easier to rotate your WiFi password when you can do it all without reconnecting every light switch in your house, for example.

Thanks for sharing your experience here -- agreed that it's better to avoid the chatter and also rotating your WiFi passwords is indeed an issue to consider, that would be quite a pain.

The "Hub" device can be as simple as a USB stick that's attached to the machine running Home Assistant. That's what I have been running for years, a Z-Wave USB stick that passes through to a ZwaveJS docker container (which also communicates with HA).

So it's not like you need a big stand alone device that has to have it's own Wifi or ethernet or anything like that, it's just a USB stick.

Thanks! This is what I eventually got to. That said, I'm leaning towards putting the USB stick in a Pi or something like that, which is attached to and powered by the router!

Just want to have the one device and I think that's maybe the simplest way to get it without trying to run stuff on the router.

Basically, it is a hub, but it's more of an attachment to the router than anything else.

The number of companies that does this _is_ growing.

Shelly was early, the cheep chineese stuff was easy to hack but they eventually moved to cheaper and more esoteric chips where custom firmware is non existent or not as mature. This is changing back, though! The number of ESP-32 powered LED light controllers that I've seen on Ali that feature a USB port for reprogramming / have all the GPIO labeled ... even have a HA/ESP-Home/WLED logo on them is infinitely more than I saw in years past (a few is infinitely more than zero, right?)

Buyer beware - There's a mountain of products on the market that are advertised as "open source" which lures many of us in, but many of those products have poor quality hardware.

My heuristic for anything operating at mains voltages is "If I can find a product that looks just like this on Temu/Aliexpress, I'm not buying it". They're probably white label products sourced from the same factories and suffer from the same quality issues.

Relays found in smart plugs are often sketchy in my experience. About half of the ones I bought or set up for others make unsettling noises that made me worried about poor electrical connections and risk of fire. I only have two Shelly plugs but those don't suffer from these issues.

Tuya and their rebranded versions fall into that area too. Their power switches die early and they actually went from easily reprogrammable to hostile firmware. They have own cloud service you can't leave, only get an access code to - and the firmware prevents downgrades. Terrible company.

Tuya is just an IoT platform used by many cheap devices but I agree, it's low cost and cloud based which is a terrible combination. I wouldn't touch it.

Just buy the ZigBee versions, they work beautifully with HA

> Just buy the ZigBee versions, they work beautifully with HA

802.15 does have it's place but some of us prefer 802.11 unless battery requirements dictate lower power PHYs. Zigbee is also depreciated; if possible, seek devices using Matter for their interop.

> but many of those products have poor quality hardware.

Absolutely. Cheap hardware means corners cut... regardless of how open the software is.

Shelly devices are quite open and well made but easily 2x the cost of other wifi relay devices. Belkin WeMo devices are similar price to shelly and about as well made but their software leaves literally everything to be desired.

Knowing what risk is acceptable and how to identify if a particular component is built to a spec that obviates that risk or not is probably going to _always_ be part of the DIY scene.

I've been trying to find high quality, open/local controllable LED lights that have beefy enough electronics and heat control to not die in in a couple of years. Unfortunately, quality of construction is even more poorly tested/documented than open source/local control.

And even more unfortunately, price itself is not a very reliable indicator. Low price is usually a sign of poor quality, but high price is not a sign of high quality, but rather more often just an attempt to take advantage of people who don't know better.

The article does mention https://refoss.net/, quote:

    There is a crucial difference here, though: the Home-Assistant integration for Refoss devices, which interfaces directly with the monitor and needs no cloud connectivity, is written and provided by Refoss itself. Home-Assistant compatibility is the first bullet item on the above-linked product page.

Lots of “smart” products come with BK7231x chips that are flashable to esphome, nobody needs another custom protocol (even if open) since esphome currently supports local encrypted transport that’s going to be better than 99% of what the Chinese (or even western) companies are going to design for local communication.

Oh, and hobbyists mostly aren’t going to pay premium for those either, unless those come preflashed with esphome and sponsor hass project, and even then 90% people are still going to buy the cheapest option on the market:)

> hackable, local connection devices (cloud optional) with published APIs and sell them at a higher price

This business model doesn’t work.

Many have had this idea. They all run into the same problem: The target audience for hackable home automation devices doesn’t like paying a premium for anything they think they could DIY.

If you have a $70 nicely designed, documented IoT sensor but the DIY home automation people think they can put ESPHome on a $10 Amazon device and accomplish nearly the same thing, which one do are they going to buy?

If you go through the forums you can already find some semi-premium devices that are a little better constructed and might have better feature sets. They’re always followed by comments from people recommending a cheaper option.

Isn't that kind of what GL.inet does? They seem pretty successful.

> If you have a $70 nicely designed, documented IoT sensor but the DIY home automation people think they can put ESPHome on a $10 Amazon device and accomplish nearly the same thing, which one do are they going to buy?

I agree with you that targeting devs/people with an under-developed sense of buy/build doesn't work!

I'm hoping that the devs with money/slightly more accomplished who don't have time to mess with stuff would pick it up.

A bit of a jump but I think this was one of the big strategic mistakes of products like FirefoxOS -- aiming for the dev with money who can afford a $600 I-support-foss-and-mozilla signaling device that also happens to be a phone they can hack on may have worked better than targeting $60 feature phones.

> If you go through the forums you can already find some semi-premium devices that are a little better constructed and might have better feature sets. They’re always followed by comments from people recommending a cheaper option.

I think that's OK! It's similar to HN dropbox effect. IMO you actually want those people to find the cheaper option, those are bad customers for a premium brand.

The product has to actually be noticably better/more consistent/etc than the cheaper option though. And IMO there is a large subset of nerds that don't actually want to write 5 files and flash an OS to do smart home stuff -- they want to play at the application layer.

A good counter example might be the NAS industry.

This is all theoretical of course, so... We're just armchairing at this point.

How is that not exactly zigbee and matter?

Just wondering why anyone would go through the hassle of installing home assistant on Linux when the fantastic hassOS exists which will run perfectly virtualized.

Because we want to run more than just Home Assistant on the same OS? Because traditionally OS and application layers were separated? Because we trust mature Linux distros more when it comes to LTS and security patches? Because we already know our way around Debian/Ubuntu/Nix/etc.?

Absolutely this. Once you get into the game of running apps at home with certain quality assumptions you end up having to bolt on various things (VPN, DNS, log aggregation etc) that are better wrapped around the application instead of having them run within it. And having an AppOS typically just gets in the way of all that plus what edejong said that you already know how to do it on the typical production OSes and learning to do it for every AppOS is just cumbersome.

Seconded. My home server does many things, one of which is homeassistant.

Proxmox adds very little overhead. I'm running dozens of things alongside HAOS.

The OS is the path of least resistance and gives you the best experience for low maintenance.

https://community-scripts.github.io/ProxmoxVE/scripts?id=hao...

I'm also running dozens of things alongside HA and I don't have to use proxmox.

It's not hard to run HA in unsupported mode. The only real difference is an annoying reminder that you're unsupported. Everything else works, including plugins/add-ons.

I've run HA a bunch of ways. It doesn't really matter all that much. Use HACS to fill any gaps.

One-click updates work from the dashboard? I don't think they would.

Of course you don't have to go the proxmox route, but it is an easy route.

I have a proxmox cluster, so moving things between machines, high availability, and backups are a breeze. Had an SSD go bad a few months ago, and I just moved everything on that machine to another node until the new drive showed up. It was a pleasant experience.

There's plenty of other ways to achieve this, but this is what I chose and I'm happy with it. It's simple, and I can manage everything from my phone if needed.

Yes, one click updates work just fine. The only difference is the unsupported message which only appears after reboots or an update. Click ignore and it goes away.

> Proxmox adds very little overhead.

It's still running a second kernel and entire userspace stack. In my world that's not "very little overhead".

Using Proxmox with lxc containers, there is no second kernel. It uses the host kernel’s native cgroups and namespaces for process isolation. You can actually achieve the same with just systems and namespaces.

Having said that, I think if you prefer traditional distro packaging, you should absolutely stick to that.

ProxMox supports both VMs and LXC containers. You would use LXC containers for low overhead. No second kernel.

ProxMox supports it, but it's not what the linked script does, nor is it officially supported by HAOS.

Yep!

I'm aware of the tradeoffs here. For home assistant specifically, there's two options if you want to stay on the path of first-class support. Run it bare metal or in a VM.

Going a different path isn't a bad choice, or even a big downgrade.

I had fun with all the different ways of running home assistant 6+ years ago, and then decided to embrace a solution that required the least fuss and would hold up long term. I'm happy with my choice, and it gave me exactly what I was expecting.

> we trust mature Linux distros more when it comes to LTS and security patches

This. If I have to trust some huge container or custom OS where is the benefit of open source?

I used to use Home Assistant via Docker, but I've since switched to Proxmox with HAOS in a VM and a second Debian VM for everything else. My main reason for this is that it seems like the more supported scenario. For example, when the Voice Assistant stuff first came out the setup was only really documented via HAOS add-ons. I managed to get it working with standalone Docker containers but it was a pain to figure out. It really is simpler to just use HAOS IMO.

> fantastic hassOS

That is a very subjective opinion.

As was already mentioned, people rarely want to run a dedicated physical server for just a single purpose. The concept of Home Assistant Operating System requires exactly that.

Also, it is Debian-based. It uses the `apt` package manager which is slow. Some people may prefer something faster and more modern, like `pacman` or `dnf`.

> run perfectly virtualized

Fair enough.

But that obviously requires virtualization being set up on the server. If people do not use virtualization for anything else on their server, they may as well set up Home Assistant directly.

Finally, I think there is one more issue.

Many of the integrations which are possible with Home Assistant Operating System require physical hardware being connected to that server. A reader, a receiver, something like that.

But these home servers are often placed in some inaccessible locations, like an attic, where the data from sensors is unavailable. It may be impractical to run cables there. And the wireless devices may be too far away for a receiver located there to be able to read them.

So people need to come up with work-arounds to get their data to their server. They set up various signal proxies and thin clients which receive the data from the sensors on the spot where they are available and then send them over network to the Home Assistant server.

Unfortunately, from my experience, many integrations completely ignore this usecase. They are likely focusing on a happy path where everything is connected locally to "the one" server. And only then they behave nicely and work out of the box. But as soon as you need any special step or behavior, it is necessary to dig deeper and create custom layers to transport the data from your devices to the server.

Home Assistant Operating System does not make any of that simpler. Perhaps on the contrary, it forces you to use a specific Debian-based distribution with possibly outdated packages that you cannot easily upgrade without breaking Home Assistant.

Which is why it makes little sense to bother with it, in my opinion, for these kind of installations.

> Also, it is Debian-based. It uses the `apt` package manager which is slow. Some people may prefer something faster and more modern, like `pacman` or `dnf`.

Do people really care if it takes 5 seconds to parse a package index vs 1? I don't get this argument at all.

I wholeheartedly agree with you. This is one of the most bizarre arguments against it that I've ever come across.

And that's even before you realise it's based on fiction:

> Home Assistant Operating System is not based on a regular Linux distribution like Ubuntu.

https://github.com/home-assistant/operating-system

There is no apt or any other package manager on HAOS.

Yes, you are right. There is one more abstraction layer.

Home Assistant Operating System uses Buildroot which uses Docker to run container with Home Assistant Supervisor. And only that container is Debian-based [0].

[0] https://github.com/home-assistant/operating-system/blob/0c75...

And that's entirely inconsequential, since it's in an immutable container where `apt` will never be used.

I just installed python3 on Debian and Alpine. It takes 16s vs 4s (I ran the test three times, and kept the fastest measurement for Debian and the slowest measurement for Alpine).

Sure a one-time wait of 12s doesn't change my life. But I won't use apt/apk _once_; I'll use it every single time that I install something. It low-key bothers me when my flow is interrupted by having to wait for machines to do their job, increasing that by 300% doesn't help.

This wouldn't be a deciding factor for me. But it doesn't add points for the Debian-based approach.

A couple weeks ago I powered a laptop that had been sitting unused for several months. It had Ubuntu 22.04 installed. The initial `apt-get update` took some time to download new indexes, and almost 3 minutes to process them all afterwards, while I was right there staring at the screen wondering why I was there staring at the screen for so long, because this experience always happens as soon as any of my machines stay off for more than a couple weeks. apt is indeed very slow.

> Do people really care

I suppose it depends. I do care because I typically need to do it regularly. And it is nice to have it done quickly.

What about the ones running it in Kubernetes? ^^;;

I tried to install it on a raspi 4 with touchscreen for my wife. The raspi worked fine with Debian, esp. it's installer asks for the wifi and ssh keys, and therefore you can trivially connect to it.

Not so with the homeassistant installer. No wifi setup, no ssh access at all. You really need to cable it, nmap the new IP, and then I got stuck because the web server doesn't show up. Attaching the keyboard brought me into a restricted ha> prompt, where I cannot fix anything.

So far it's horrible

I’d suggest that you use a docker instance. The setup is trivial.

Not having HAAS has made little difference to me being able to do all sorts of stuff - and HACS gives you access to a whole bunch of additional stuff, and works in docker.

+1. I know the parent reads like “do it my way” but ha in docker really is simpler.

I did this a few months ago for a test home assistant setup and had the opposite experience. I forget exactly what I did, but it involved editing a file with the wifi settings and dropping my public ssh key on the SD card before installation.

If you use ethernet, no editing required. Web interface goes into setup mode automatically.

Worth noting that ha cli[0] (ha>) does have a `network` command to configure this as well.

[0] https://github.com/home-assistant/cli

Mind that you should not use a Pi with SD card for HA. I'm not sure what the official stance is, but: In my peer group failing SD cards were responsible for a vast majority of issues. Causes are probably a mixture of heavy logging and power outages; either from the grid, or user error not shutting down the Pi before disconnecting power.

At our house I run HAOS in a VM (on a beefy server). My wife uses the app on her phone (as do I), and we have a cheap tablet with the app for guests. On the laptops/desktops we also have access to the web UI.

As the article points out, remote access for the phones can be done via the commercial offering or a VPN (as in our case: wireguard on the OpnSense).

Completely anecdotal experience but I've been running HA on a Pi from SD for quite a few years now with no issues.

Wholly depends on how much stuff you’ve got. I’ve started having issues with the Linux io scheduler when the auto backups got large (1G+), the thing just hung and needed a power cycle.

> Wholly depends on how much stuff you’ve got

Also what SD card you have, the durability between different models differ a lot. The SD card I use for my dashcam been working for years (A "SanDisk MAX ENDURANCE" card), some other cheaper SD cards can stop working properly after just months if you're using them for write-heavy stuff.

Anecdotal agree, but I only use it for my lights (about 20 smart bulbs + 5 sensors + 4 remotes) and I never tinker with it. At least 4 years later, that little Raspberry Pi 3 + ZigBee dongle + sdcard are kinda forgotten about.

Interesting; my Raspberry Pi 3B+ + Zwave dongle + SDcard eventually got too slow (to the point that HAOS updates would fail). Switched it to an old ChromeBox and it's been no problems since.

You don’t need to nmap; instead head to http://homeassistant.local:8123

If you type "login" at the ha> prompt, you'll get a root shell.

This is something I also had to accept about HA. It runs in a VM in my case so it worked out-of-the-box, but you don't just ssh to it after installing it, and the ha> prompt is just a bit different. So far, it hasn't been in the way, although it occasionally takes time to find out how to do things.

It's very flexible though, and apart from devices in your house there are many outside sources of data to use, like weather data, sun elevation or trash pickup dates. The HA app on your phone gives you many sensors usable in a flow. The time spent on it usually results in something worthy of that time, in my experience.

Much respect to Home Assistant for making everything as accessible as it is, but it’s inherently a complex project. It also has to deal with trying to be everything to everyone, which makes it hard to identify the easy path through setting it up among all of the options.

There are two ways to get through Home Assistant:

1. Identify the easy path instructions, get equipment that matches perfectly, and follow the instructions to the letter. Use only equipment known to have great integration. Upgrade only when necessary. Change nothing as soon as it’s all working.

2. Be willing to spend a lot of time tinkering and debugging. There’s a big Home Assistant channel in one of the big Slacks I’m in where everyone eventually hits something that takes days or weeks to figure out.

Many companies have tried to package or use Home Assistant as the foundation for plug and play IoT hubs, but they all seem to end up with the same realization that it really needs a capable and willing human in the loop as soon as you deviate even slightly from the list of devices with excellent support. This isn’t even entirely Home Assistant’s fault: Most of these devices were never designed for third party control.

I got frusterated with HA's attempts to make is hard to run outside of their distro and installed openHAB. I find that works good enough for me.

Funnily, I had the opposite journey: I got plainly frustrated with everything OpenHab and was delighted with the versatile integrations and ease of setup with Home Assistant...

If you use openhab as they want it is easier. However if you don't want it it on a dedicated computer it becomes much harder.

I assume you meant to write "Home Assistant".

The data ownership reminds me a bit of an early business ummm transaction if Dr Phil:

1. Sell the gullible public long-term memberships to a gym, with long-term subscriptions.

2. Sell the subscriptions to a 3rd party.

3. Close gym. Subscription contract still valid.

https://www.celebitchy.com/8971/dr_phil_ran_a_health_club_sc...

It's very easy to be cynical. Home Assistant belongs to a non profit. While that in and of itself isn't bullet proof, it does go a long way.

For a long time I was running home automation using individual scripts and was happy with it. Then I found myself in a remote place where the ISP gave a shitty modem which hangs when there's no heavy usage ¯\_(ツ)_/¯

I had to automate restarting the modem when the Internet is down by power cycling a smart plug[1], Home Assistant turned out to be extremely useful for that. Official HW integrations and Node-RED was very straightforward to solve my problem. Since then I'm managing and monitoring various hardware devices in my home through HA.

What's interesting is that there are manufacturers who are not only fine with HA but work with developers of HA integrations which enable offline usage of their IoT products even though their official apps are completely enshittified.

Nowadays I checkout HA compatibility before I buy a IoT device.

[1] https://abishekmuthian.com/restart-modem-automatically-when-...

Thanks! Check out Lars' channel for some interesting insights into Home Assistant with remote sensors: https://www.youtube.com/@LarsKlintTech/search?query=home%20a...

I tried HA back in the day and got YAML-bound trying to get various sensors and controllers to integrate and work reliably. I revisited HA a couple of times over the years, but by then had become cosy with Node-RED and saw no strong reason to change. I understand HA's now more configurable through the front-end GUI, which is nice.

I've just integrated an office UPS with the Node-RED stock dashboard to log status, mains voltage and battery charge state - it took all of 5 mins, including the time to install the UPS NUT plugin for Node-RED via the GUI.

I love the ease of the visual, block-based configuration, and the ability to add codable function blocks to process and modify data.

The only things that are not so great in Node-RED are the dashboard look and feel, and the dashboard setup tools.

> Home Assistant has support for that remote option, and no others.

The openHAB Cloud Connector allows connecting the local openHAB runtime to a remote openHAB Cloud instance, such as myopenHAB.org, which is an instance of the openHAB Cloud service hosted by the openHAB Foundation (https://www.openhab.org/addons/integrations/openhabcloud/)

> There is also a container-based method that can run on another distribution, but this installation does not support the add-ons feature.

You can use the add-ons with the containerized version. This has been discussed elsewhere.

I don't really get HA. It seems oversized for what most people need for their own home automation. Maybe I'm just jaded because my house is fully KNX wired, but the only "addon" I need is NodeRed for some Dashboard and Integrations of ESPs that are just for additional monitoring. It runs in a lonely docker container just fine and does not need a million dependencies.

Then again, I also don't understand why people buy every "smart"/cloud based device and try to glue everything together - when the hardware fails most likely the vendor does not exist or no longer supports it anymore and then you start all over again.

So, this comment boils down to: “this free software project has too much capability, and there exists hardware that is reliant on cloud servers.”

Your house is wired with an alternative and you can't imagine people who DON'T have that infrastructure are looking for a way of doing smart automations?

I have been using HA for years and I love it, it does what I need it to do while operating quietly in the background. I don't have any devices that are "cloud based" so I don't care if the vendor goes out of business or not.

My stuff is a mix of wifi, z-wave, and my cameras are ethernet cabled but can be integrated with onvif.

My house was also built in 1958, there's no chance I'm running KNX cabling anywhere, much less all the places I have devices.

I started using home assistant when it first came out, found it too clumsy, returned years later, and found it too bloated.

A lot of volunteer work has gone into it but it lacks overall coordination of efforts and a usage model that is simple and consistent. That’s one of the downsides of open source: too many cooks and you get mediocrity, but accidentally when everyone is good hearted about it.

I had to do so much research on appliances I was adding that it was easier to just roll my own gateway and cloud. Now it is a vastly smaller code base that I control and can easily debug issues.

Maybe HA could refactor into a smaller set of modules that doesn’t require a huge set of assets from the get go?

Home Assistant is great, I have been able to push it to do things I wasnt expecting it to permit. Just running Python within a container arbitrarily interacting with the network and sensors. I used it to backend my own home web application.

I believe a lot of people who are upset with the product have radically incorrect expectations.

Looking forward to the day we might have home appliances without on board cpus, they will just be LAN wifi firmware devices. Something like HA could be used to make them as smart or as dumb as the user wants without giving the manufacturer any control over the UX

That’s literally Zigbee.

Feels like building my own smart Jarvis at home — kinda tricky, but super fun!

There's an excellent thread with someone doing just that, but Friday.

https://community.home-assistant.io/t/fridays-party-creating...

Is there anywhere that compiles a database of local control capable smart home devices? I tried briefly to search and I found databases of smart devices but none seemed to have that as a filter.

The Home Assistant docs at least document how the integration works by "IoT Class"

https://www.home-assistant.io/blog/2016/02/12/classifying-th...

For example Tado: cloud polling

https://www.home-assistant.io/integrations/tado/

Home Assistant is a toy when it comes to automation reliability. It's a good toy though.

I'll stick to my domoticz for the "if it ain't broken..." approach.

If you choose your hardware wisely, it's incredibly reliable. Most of my house is automated and I all I've done with it in the past year is add a few devices.

I will admit that low (or zero) maintenance is easier to accomplish if you know your way around a little bit.

I've never had HA itself fail. I've had it installed for 10 years and the only true failures were hardware (server, iot devices) or my own config mistakes.

I used HA for about a decade without so much as a hiccup.

What makes you think it’s a toy?

> Home Assistant has support for that remote option, and no others.

It's literally just a reverse proxy. Set up any you like. Wireguard, cloudflare tunnel, caddy with a security plugin, the options are limitless.

Is there a way to contribute to LWN without creating an account or having an ongoing thing? Does nobody use crypto?

Looks like they don't accept donations, sounds like it is much harder to accept them.

https://lwn.net/Articles/828428/ https://lwn.net/Articles/1019619/

You can wait for around two weeks for the article to be free to read, if you don't want to subscribe

I just want to support. I guess they have prepaid subscriptions and I can just pay for x months a year that I think is fair. I don't read it a ton but wanted to contribute.

A link for the first article in this series:

https://lwn.net/SubscriberLink/1017720/7155ecb9602e9ef2/

We changed the URL to this from https://lwn.net/SubscriberLink/1017720/7155ecb9602e9ef2/ and posted this https://news.ycombinator.com/item?id=44014505, to avoid splitting the discussion between the two parts.

They are two different articles, I don't think that was correct.

As if to illustrate the difficulty of the situation, I posted a reply to the other copy of your comment here:

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

Reply on news.ycombinator.com