A virtual python environment is not the same as supporting the scripts used to run HA. There are more things, init scripts, integration of duckdns, … . By using manual install even in a venv your almost completely on your own. I don’t think I like John Rambo as my home automator.
It’s absolutely no different after “RIP Hassbian” than it was prior to “RIP Hassbian”.
I guess we’ll be sorry to see you go…
1 Like
If you think retiring Hassbian is such a big loss why don’t you roll up your sleeves, take over the task of maintaining it and give something back to the community.
The reason I do it are two reasons:
-
to do my best to help the person who is misunderstanding how things work.
-
to the best of my ability make sure that incorrect information isn’t glossed over so that it isn’t promulgated as “true” and thereby causing confusion for new people.
But at a certain point there is no further benefit in continuing. I’m there… The point has been made.
4 Likes
Absolutely. I think the main issue is the documentation not clearly differentiating between HassIO and HassOS. I’ve been meaning to submit a PR to change the wording, but havent had the opportunity yet.
I’ve written this before, but will do it again to the benefit of anyone new who is also confused about the situation, and doesn’t understand why not having Hassbian doesn’t matter too much since you can just do the VEnv yourself if you have dockerphobia.
HassOS is a minimal linux install which has Docker on it, with HassIO preinstalled. It runs headless, which is to say that that computer running it has no GUI (if you attach your RasPi to a monitor, it won’t give you an interface to use. HassOS can be installed on more than just a Raspberry Pi though, It can be installed as the base OS on many systems, but if you have a more powerful machine I would recommend just HassIO so you can still use the machine for other things.
HassIO is a way of installing Home-Assistant inside docker. It includes a supervisor container and a container running Home Assistant. It allows you to install AddOns which are separate docker containers. The supervisor container of HassIO takes care of managing the other containers used for home assistant.
You can also add your own containers to Docker without HassIO caring about them.
You can run HassIO on a linux install that has a GUI, or one that is headless; in either case you can still use this computer to do other things, with docker running in the background.
Home-Assistant is the specific python program. This is what’s actually running at the core of every HA install.
Hassbian is a SD card disk image which is a Raspbian installation with home Assistant in Virtual Environment, pre-installed.
So, to summarize, the most popular install on a RasPi is HassOS, which is:
HassOS->Docker->HassIO->Home-Assistant+AddOns
On other devices (such as desktops, laptops, servers, NUCs), HassIO is the popular choice, which is:
LinuxOS(usually)->Docker->HassIO->Home-Assistant+AddOns
If you’re using Hassbian, that’s:
RaspianOS->PyVENV->Home-Assistant
6 Likes
This is great, add some screenshot of how a clean Hass.IO looks compared to a Home Assistant stand alone install looks and that will help understand the newcomer what he is going to get.
I’ll say it again, I am running Raspbian->Docker->HassIO->Home-Assistant+AddOns on a Raspberry PI3b+ and it works flawless on SSD over USB and no SD (sd tray empty), this possibility should be mentioned for people who really want to run on SSD and not in the SD card. IMO. At least until HassOS supports booting from USB Drives.
My english isn’t good enough to write newcomers guides, but I really feel the confusion when I was new: Hass.IO HassOS Hassbian, HA, HomeAssistant, “Hass.IO in a Docker” etc.
1 Like
I am not mad, but implying i don’t know how to perform updates/upgrades or how to handle a venv is not really an argument. I am able to use docker. The point is everybody says it is so easy you just have to start over this or that way. I don’t know why i should start over with HA.
HassOS at least the last version i used does not give me an easy way to just copy my scripts, files, etc and use them inside HA. For example to use a notification by VOIP/SIP I had to install linphone and put a script i already used before on my pi and can trigger alarm calls to my cellphone. Using docker you can put this inside your HA container and risk loosing it everytime you make an update to HA.
HA should make life easier, it is not an end in itself. I have a real life and a family. I don’t wan’t to spend hours on reinstallation every time HA is updated. This leads to the next pseudo argument “get on and maintain it yourself”. If i don’t waste time on reinstallation why should i put my time and effort in maintaining a distribution on my own?
I’am not simply trolling, I have given arguments. If you keep using your old hassbian install security is an issue.If you manually install on a different distribution or OS compatibility is an issue. The problem in this thread is everybody here is already convinced their way is the only way to do things, you cannot see somebody uses a different approach based on his own experience. I have gratitude for the people who have put time and effort in HA. For me it is/was a system to use and easily extend using my own skillset. I didn’t have to learn the internal workings to put in some of my own things. Switching to HassOS implies I have to abandon these and start writing plugins, components, … for problems I have already solved.
There is even no easy migration between an hassbian install and HassOS.
I have used HA for more than 3 years, but the migration was never my intention. The service is quite stable and easy to extend in a lot of ways, but installing HA using docker restricts this. HA give you commandline sensors and switches, but container isolation makes it difficult to use these features. If there is an easy and secure way to use such features I am glad to keep HA. For example I use mpd to play sounds and notifications (tts) to a bluetooth speaker. There is no way to configure this inside HA. mpd is restricted to the homeassistant user connecting from my raspberry pi (on purpose). Using mpd with bluetooth is complicated enough (the problem is keeping the connection alive and not speaking to /dev/null)
Nobody here has given a real solution, only “start from scratch”.
Even the changes inside HA moving away from yaml to a more “database” like configuration makes it different to backup only your config. There are a lot of discovered devices in my configuration. These are “hidden” inside the homeassistant installation directory.
These are small problem, but a lot of them. The most answers i got where implying I didn’t read the documentation or did not know my way around a linux system. Ignoring things I already said.
The only real improvement was the clarification that hassio is not hassos and can easily used independend. This would be the only solution usable for me, but still requires a start from scratch for my configuration, since there are no migration tools scripts or howtos.
If you lose ANYTHING when you update a docker container then that’s your fault and your ignorance. The config, backup, and other volumes are and have always been persistent. You should NEVER store anything you want to keep anywhere else other than those non-volatile volumes. Additionally, to MIGRATE to Hass.io/HassOS, if you backup the folder with all your config files including sub directories, you can just copy them back to the new HassIO version of those folders and restart HA. Then you will be 99% of the way there.
You are overthinking this and making it out to be much harder than it actually IS.
You have also had it explained that as before you can continue to maintain Raspbian exactly as you should be doing now. The venv works perfectly well under Raspbian as it does right now.
It seems like you are just pissed that stuff is changing!
I originally used the all-in-one for a Raspberry Pi which was depreciated maybe almost 2 years ago now… but I didn’t sook about that, I just saw the writing on the wall and went to HassIO. I also played with a Raspbian-Lite and then installed hass.io in docker on top before I migrated to a NUC. Downtime in every case was less than an hour.
2 Likes
Hmm, you do seem upset that someone has decided not to maintain your installation method as they also probably have a life, but are not willing to put any effort in your self to go forward.
As people have already mentioned you can maintain it yourself, but your concerns seem to be that any updates are not tested against your install or maybe insecure, yet you are willing to install packages (linphone and other s you mention) that is not part of the original install anyway, is the expectation that the maintainer of supposed to support that or you? seems a bit contradictory there
@haraldrt the only reason I suggested that you might be a good hassbian maintainer is because you seem like you have the required skillset(s) to perhaps do that. We all contribute in our own ways, I am no more than a dabbler when it comes to code, I have perhaps a total of 10 lines total across all the open source projects I have ever been involved in. So I try and support people, push them towards solutions if I can, remind people about how to post a useful question, and all those things devs do not always have time for.
You however seem to have a good number of the required skills, and an eye for security which is more important every day.
So why not throw your hat in the ring and contribute some time? Keep hassbian alive, extend it to generic linux installs on amd64, make it better.
Or do what @DavidFW1960 did and move to another solution. Just don’t try and tell us we made it too hard for someone with your skills.
For those assuming the “death” of Hassbian is the end of the world… I installed using the old AIO installer, some three years ago. That install is still running, through many upgrades, including OS upgrades. If you’ve got Linux skills then this isn’t just “not hard”, it’s trivial and should be second nature.
The end of Hassbian means that you’ll have to manually upgrade to (Raspbian) Bullseye rather than running the Hassbian suite command that does that - unless somebody picks up the Hassbian suites and maintains them.
How about Don’t panic? There’s nothing to worry about here. Just keep using Hassbian. Upgrade the underlying OS as required, install new versions of Python and rebuild your venv as required, and basically keep on doing the things you’ve already been doing.
Hassbian is little more than Raspbian, Home Assistant in a venv, and some scripts. It just wrapped all this in an image you could flash.
No more than before.
Not at all. If you’re using any modern Linux based OS then there’s nothing to worry about at all. Debian based is nominally easier, since the docs are primarily written around that, but CentOS, SuSE, it’ll all work. Heck, you can get this fully functional on FreeBSD if you want - just see the list of installation guides.
Once more, there’s zero need to migrate off your existing install. Just continue to keep the underlying OS updated, and pay attention to Python version deprecations.
For reference, my primary HA instance is a manual venv install, using the guide I linked to above, that mirrors the Hassbian setup. I do this because, like you, I have a bunch of scripts for things like notifications, sensors, switches, and more. I know I could do all this in Docker, I just have no interest in doing so 
5 Likes
I know I said I was done with this but I just can’t help myself…
I’m not sure what you mean by this.
There are no “scripts used to run HA” outside of the venv except the system service to start HA at boot. Since that is already installed and running on your system then how would that need to be “maintained” or else cause your HA to inexplicably stop working?
What exactly do you mean by “init scripts”?
I never implied anything of the sort. Please show me where in my posts where you think I did.
Again, I never said that. As a matter of fact I literally said that nothing in your install will change.
Just keep doing things exactly as you were doing those things before and the results you achieve will be exactly the same as they were before now.
You don’t have to switch to anything different.
Just keep doing things exactly as you were doing those things before and the results you achieve will be exactly the same as they were before now.
the solution is the same as i’ve said almost every post above:
Just keep doing things exactly as you were doing those things before and the results you achieve will be exactly the same as they were before now.
You were going to have that happen whether Hassbian was still continued or not. So that is a moot point in regards to this discussion.
Just keep doing things exactly as you were doing those things before and the results you achieve will be exactly the same as they were before now.
No it’s not and no it doesn’t. The best solution is one i’ve already given and doesn’t require you to start anything at all:
Just keep doing things exactly as you were doing those things before and the results you achieve will be exactly the same as they were before now.
And just for completeness and to remove any ambiguity at all I will say this once more with gusto:
Just keep doing things exactly as you were doing those things before and the results you achieve will be exactly the same as they were before now.
4 Likes
These “hidden” files are still just files that can be backed up in any manner you wish. You’re just complaining for the sake of complaining because you don’t actually understand what the system is doing.
2 Likes
@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 
2 Likes
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.
1 Like
It’s in the works. There’s nothing stopping your form using it as is right now but I can’t predict the future of Raspbian that it is based on.
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