How best to run Home Assistant on Linux

Installation
1

I’m struggling with the best way to run Home Assistant on a Linux laptop or Rasperry PI running Ubuntu. I don’t want to run HA OS natively — I want the general OS for other things.

I’m currently running HA OS in a QEMU VM and this mostly works. However my host only has WIFI networking and while I can run the VM with “user” networking, and can have it access the Internet and support the Addon Store, I cannot trivially the web UI from my host or my LAN. What I’m having to do is use “virsh console” to connect to the shell, and then login as root, and then run an SSH tunnel to set up inbound network access on my host. I have to do this each time it boots.

What I’d like is to run with “bridge” VM networking, have the HA OS get an IP address on my local network, and be able to access the web interface directly from my LAN.

However, I’m told I cannot easily bridge between the Ethernet interface of HA OS and the WIFI interface on my host.

Any suggestions?

2

Get a better host dedicated to HA OS that has wired Ethernet. Wifi is not suitable for server network connections.

3 Likes
3

I installed on my Ubuntu home server using a snap. That makes the network visible and access to the UI is via port 8123 on the server. Config files are accessible to the server file system.

The add-on system with repository support isn’t there though.

Tim

4

It is also an unsupported installation method. So you are on your own if something goes wrong.

5

I have it installed on a Linux host with a VirtualBox VM. Works fine. My previous internet provider had me stuck with a router that would somehow mess up DHCP for ethernet devices and drop them off the network regularly, so I had the wifi bridged through VirtualBox. AFAICT, the HA VM can’t tell whether the bridged connection is ethernet or wifi, it just sees a fake ethernet network adapter.

My current router is not insane so I now access my instance through ethernet but the WiFi is still connected, if my cat chews up the ethernet cable I can still access my instance.

6

Many things led to instabilities in my home automation system using HA hosts connected through wifi for a year and a half, but wifi connectivity of the host wasn’t the cause of any of those.
Ethernet is almost always better, but I think WiFi is good enough for most HA users if the host is in a place with decent reception.

7

I’d do a supervised install on debian bookworm. This is the approach I’ve used for years. With this approach you can run other things on the OS if you need to. People will indicate that running things on the base OS makes the system non-supported, but the HA software doesn’t complain. As you’ll be maintaining the OS, you’ll have the freedom to run what you desire next to HA. Just be aware you need to make sure any software you add doesn’t conflict with HA.

8

Supervised is a trap.

It seems like like a good idea until you look at all the requirements. The devs hate it and only begrudgingly support it.

While there are no plans to discontinue it (that I am aware of), they would love to drop support for it.

It is one of the most difficult install methods to maintain and will break every time Python is updated in HA.

It has very strict requirements for how you are allowed to use the OS.

I would not class it as “best” by any sense of the word.

1 Like
10

I agree with this. I started out with supervised but the installation was a hassle. For me it was a way to get started without investing in new hardware (I ran it on a pi 3b with 1G of Ram). A VM gives you all the freedom you need, more backup possibilities and with the improved availability of capable and inexpensive hardware, the small extra penalties in resources aren’t going to be holding you back once you decide to really go for an open automated home.

11

Welcome to the religion wars. There is nothing wrong with the supervised install. I’ve use it at multiple addresses for multiple years with good success. Over that time, There was one case where the supervisor app updated and it had a bug that cause the HA to fail to start. On rare occasions, the development team adds some capability in an effort to control an OS level function that cause me to make minor adjustments. Networking is the main culprit here. I’ve never had a python issue. It’s the best alternative to the HA OS install if you want to install on an ARM board and maintain control at the OS level. A VM install would needlessly waste the limited ARM board resource. I’d say the same thing for a small x64 platforms.

This link is a little dated, but in concept it shows my basic setup. You couldn’t implement what I was looking to do on HA OS, but with the supervised install you can add extra capabilities to have a fully function smart house. In addition to what is mention in that link, I run openVPN on the platform to create a mesh network between my locations that gives me remote access over cellular to the house without power. I also have a number of other small capabilities that I run on the board. It’s the supervised install that allows me to run openVPN and other apps on my ARM controller board. That said, I monitor resource utilization to make sure the added capabilities are causing an issue for the HA containers.

With any of the approaches you’re bound to have an issue at some point. If it appears the supervised install will meet you needs, then don’t be afraid to use it. While the supervised install method could be terminate in the future, so could all the other non HA OS install methods. I know that based on past history, when the development team discussed discontinuing support for the supervised install, the noise on the forum was loud enough that they back off.

Good luck with whatever approach you select.

12

I agree about Supervised, but breaking with Python updates is simply not true, as Python dependencies are handled in the HA Container. I think you are thinking about HA Core (venv) and its Python problems.

13

Thanks. Corrected my post.