A kernel developer plays with Home Assistant

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

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.

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

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.

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!

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

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

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.

Its not prohibited here. What technical decisions are questionable?

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

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

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

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

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

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)

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

How is that not exactly zigbee and matter?

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

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

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

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

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

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.

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

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

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.