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.
1 Like
@finityYou are correct. Clean and simple.
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.
4 Likes
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.
2 Likes
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.
I’ve split that flame war out into its own thread, so it’s not polluting the otherwise relatively constructive discussion here.
1 Like
Good call. But it did end up constructive in the end
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.
The SSH add-on has worked reliably me. I did set a password instead of the shared key that is recommended.
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.
Fortunately no, Home Assistant and the add-ons are independant.
Really?
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.
Ssh always works for me even if HA is off. There are times where it screws up but all you need to do is restart the container or reboot.
Edit: but I’m not using hassos
1 Like
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.
2 Likes
It’s a completely separate container. It keeps running even when Hass.io isn’t ‘up’. You can see it’s running in Portainer etc. All the containers (hass.io addons are containers) run independently of Home Assistant.
1 Like
As others have pointed out. It is a separate container. I can ssh into the system and stop/start/backup/restore, etc HA independant of the state of the HomeAssistant container. I also have access to the config files and can make changes or corrections.
1 Like
In other words if ssh is not working, there is more wrong with your system than the home assistant container.
2 Likes
well, that’s good info to know.
I don’t use hassio so i was just going by others reports on things they (…thought…) they were experiencing.