@Codec303
Me (and probably most of people runing raspbian) use rpi for multipurpose projects (not only HA), so we are running it usually with pi user.
So for changing HA in command-line we are changing from pi to homeassistant and viceversa… and allways fighting with file permissons. Think about i.e a custom integration that download youtiube song playlists with youtube-dl command-line, and reproduce them on sonos via MPD. You will allways in trouble between pi and homeassistant user.
I think that use ‘homeassistant’ user its a bit “HA centric vision”. Now that hassbian is dead, I think that can ‘10’ kind of people:
Those who want a RPI to only run HA, dont touch a CLI, (and dont know how to count in binary) => could use HASS.IO
Those who use RPI user for more things than HA (and know count in binary) => use raspbian + venv under pi user.
Any services you run should run as separate users, this is just good practice. Dealing with file permissions just means learning how to work with them.
I run many things on my HA system(s), only Home Assistant runs as homeassistant, and I’ve got no issues with permissions
Me (and probably most of people runing raspbian) use rpi for multipurpose projects (not only HA), so we are running it usually with pi user.
I am currently running Raspbian for multipurpose projects, i have Grafana, Nodered, etc. installed, along with HA. I’m using the ‘homeassistant’ user for the HA install, as described in the install guide, and it works great for me. I imagine most people who followed the install instructions step-by-step will also be using the ‘homeassistant’ user.
So for changing HA in command-line we are changing from pi to homeassistant and viceversa… and allways fighting with file permissons. Think about i.e a custom integration that download youtiube song playlists with youtube-dl command-line, and reproduce them on sonos via MPD. You will allways in trouble between pi and homeassistant user.
I don’t own a Sonos myself, and don’t use MPD, but I have not had to ‘fight with file permissons’. I just make sure the right commands run under the correct user and mainly use NodeRED to automate HA restarts and updates.
NodeRED is running as ‘pi’ user and HA is running as ‘homeassitant’ user.
There is nothing stopping you installing HA as the ‘pi’ user, if you prefer to do so, you just need to do things differently when setting up the VENV.
It basically is. Hassbian was just Raspbian Lite with any dependencies added ontop that installed the latest HA on first boot.
We also had some extra tooling for adding some more functionality.
There’s serveral reason for why the ´homeassistant´ user was added.
First it runs the HA process and any subprocess as a user with fairly limited permissions.
Second it avoid having conflict with installed packages by the user.
The placement of the .configuration directory is the same as Home Assistant has used for as long as I’ve used HA and wasn’t something I would want to change to avoid deviating from the current documentation.
The scripts(hassbian-scripts) where placed according to how Debian specifies preferred install locations and couldn’t have been in a home directory since they where used by the homeassistant user and the pi user.
Finally, please don’t run a service with an account that basically has root privileges as the pi account on Raspbian has. It’s a potential security nightmare.
I was reading through this and trying to work things out and unfortunately there seems to be mis-communication and personality clashes coming into the comments and half the comments seemed to be an argument and really not helpful at all.
We all have questions about the change and being downright dismissive, even if someone has assumed incorrectly, has made these comments slightly unpleasant to have to read through. It may not have been meant to be that way, but that is the way it reads to me.
Bottom line, the VENV is always going to be supported and is the way to go if you have more complex needs. For the basic user just wanting a Home Assistant hub on a basic network, HassOS and HassIO is the way to go. I know that HassOS can do some of the fancier stuff but I am generalising.
I wanted to say a huge thanks for the dev’s for keeping Hassbian running as long as it has been and also for clearly stating the reasons why the change to is being made. It makes sense to focus on the main system and not worry about so many distributions.
Also a big thank you to the people who have explained things clearly as, when filtered through, all the questions about migration are answered in the comments and the main article.
Too right @brendan, this thread has got a bit toxic.
People shouldn’t dismiss docker (without hassio) either. If you need extra binaries within your container, you can add some stuff to the docker file and build your own container. Or you can enter the container and add the application you want. This can be automated so it happens on every update.
I thought I borked my venv system. I cannot even remember what I did. It just wouldn’t work.
I installed the same version of ha via docker. I pointed it at the old venv config files in /home/homeassistant/.homeassistant and it worked straight up. Every now and then for fun I update the venv and use that instead. They behave exactly the same.
I started HA with ~version .25 running in a venv. When it came time to move to a newer release of python, I found it easier to adopt Hassio at that time. The move was simple and has been remarkably stable. Updates are generally clean and thanks to wonderful developers, keep getting better with fewer truly breaking changes.
My setup is fairly clean, I have a single subnet and do not use VLANs. My managed devices/sensors are connected either by IP (including mqtt) or ZWave . I have worked in IT for many years, and frankly, want to minimize the amount of maintenance when I come home, so I appreciate the almost appliance like option of Hassio. But for those that have more specific needs, other options are available. What is right for you… the universal maxim of IT, “It Depends” applies.
Thanks for this. I would switch to hass.io but running a headless RPi makes it difficult for me relying on SSH being loaded by HA. When I tried it some months back whenever I had issues with HA I could not log in and check what was going on. At least this way I suspect I will be able to SSH in if I get problems with hass.io.
It wasn’t that the SSH add on wasn’t reliable, it was that, as far as I know, home assistant needs to load for it to be loaded. So if you have a problem with HA loading, you can’t SSH in to figure out what’s going on.
I’m surprised to hear that. I’ve seen a number of threads on here where people have had a problem with hassio running and they also lost the ability to SSH in to fix it.
Every add-on (including Home Assistant (it can be considered as an add-on in this context)) are separate docker containers, that do not rely on each other.
