@flamingm0e “Partially” agreed. So just for understanding a “virtualized” environment would be the same as a docker “containerized” environment. Which one is better , and any pro/cons and limitations we expect to face in each of the approaches.
If I get some easy instructions to start with, then I try to get a shot at it. Can you please post the exact link and some steps to start with.
Thanks for the advise.
here is a basic guide on how to install and get started:
not quite.
the python virtual environment encapsulates the python process and versions, but not the entire application stack.
a docker container is an entire application stack containerized.
Personally I find Docker much easier to use and manage. I also get the benefit of installing other containerized applications.
It’s really just a matter of installing Docker on your device, and running a script. All of that info is provided directly in the Home Assistant documentation.
Ok, I would try learning the ropes to run thru the docker. I read elsewhere and in this thread as well, that in a dockerized approach, we have some limitation on Add-ons, or we have to create a separate container for each add-on. Is it so, or is it a rather cumbersome approach and would it render any limitation in functionality.
Can I have any guidance on this approach of how to add add-ons in separate containers.
Thanks.
In a normal Home Assistant Docker install, there are no Add-ons.
You have to understand what add-ons are first.
If you install HASSIO, it runs a very minimal base OS, and runs docker. Hassio really consists of 2 docker containers, a supervisor and the home assistant docker. Add-ons are only available on hassio, and when you “install” an add-on, it is just downloading a docker image to run. The Add-on ‘engine’ just has some preconfigured options for you to connect these add-ons to Home Assistant. So even in Hassio, an add-on is just another docker container.
When you run normal Docker with normal Home Assistant, there are no “add-ons”. You can duplicate almost everything hassio Add-ons do, manually, if you understand Docker and how the system works (you don’t have to know everything about Docker, but understand bind mounts and communication between containers). You essentially just have to look at what image the add-on is based on (most of them are just normal docker images wrapped up for hassio), so you would run the normal docker image, and make the connections into Home Assistant yourself.
It’s more work, but you have more flexibility and you are not at the mercy of hassio releases, or dealing with the bugs that creep up on the hassio installs.
Thanks for the startup help provided.
So I was able to do a quick crash course on the basics of docker, installation of docker on RPi3 and then homeassistant. At first the concepts are a bit confusing to make the distinction between Home assistant, HassIO, HassOS, Hassbian and still continues a bit. The image and container also appeared to be same until I read they are not. The image v/s container v/s volume is still to be clarified by myself. Taking random bites of info here and there.
As of now I am unable to understand the user of docker-compose , although I have got it installed, I am unable to understand where to put docker-compose.yml files, and can there be many files or just one, and can we use any other names for these files and how do they come handy and so on…Leaving it parked for the while.
After docker I pulled home assistant image as guided over here Installation on Docker by running the following
$ docker run -d --name="home-assistant" -v /path/to/your/config:/config -v /etc/localtime:/etc/localtime:ro --net=host homeassistant/raspberrypi3-homeassistant
Post the docker command I was able to access the docker container at localhost:8123. Have created the account and logged in, did some basic location and weather settings in the configruation-yaml file. Have created a folder as /home/pi/homeass/config to hold my config file.
Then i found that portainer.io is good tool to visualze and GUIzed the interaction with images and containers, so I pulled it from here Portainer.io
$ docker volume create portainer_data $ docker run -d -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer
Now portainer is running at localhost:9000 .
Onwards I came across some threads to install Hass.io as a docker images (without flashing on SD card) , which should add the supervisor dock to my existing home assistant container (or installation whatever it is) to ease out the process of adding addons and basic configuration for a newbie like me.
Reading thru the following threads :
https://www.reddit.com/r/homeassistant/comments/8t9wd9/docker_image_of_hassio_ha/
https://github.com/home-assistant/hassio-build/tree/master/install#install-hassio
https://triradiate.wordpress.com/2018/07/16/hassio-on-docker-on-lubuntu/
and
https://community.home-assistant.io/t/hass-io-via-docker/60720
I understood I need to run the following (and read the script to some sketchy level of understanding that I could do).
curl -sL https://raw.githubusercontent.com/home-assistant/hassio-build/master/install/hassio_install | bash -s
After the script I guess i have the following running containers in my docker registry. I guess the “homeassistant/armhf-hassio-supervisor” image is added by the hass.io script above.
Afterwards I logged in the home assistant again to see if the supervisor and addons menu dock is added to my instance or not. However it still show the same bare bones menu items. So as I expected from the thread, I cannot see the Hass.io option in my home assistance docker as desired below
Hass IO on Home Assistant Docker
Can you please help further how to sort it out.
Thanks for the guidance.
anywhere you want. wherever the docker-compose.yml file is is where you run the command from. the commands for docker-compose expect the file to be in the same directory as where you run the command.
No, installing hassio with the script does NOT add it to your existing container. You have to remove your existing container, and use the hassio container if you want hassio. It also stores the config in a different location.
start over and make sure your home assistant container has been deleted first.
So I understand I have to delete the original non-Hassio installation of home assistant I did earlier. To do I presumed, to stop the container first, delete container and then presumably the associated image.
To stop and remove container
Then deleted image, assuming the HassIO script would download its own image (hence no need to waste space on this existing image):
Then to start with a clean slate I also wanted to stop and delete the container and image for hassio_supervisor
But somehow this container gets restarted automatically when stopped or killed, i have even tried tinkering with the restart settings. However to no avail, it keeps being alive itself, hence I cannot delete its image file.
Without resetting the hassio_supervisor docker, I tried running the curl script , which ran quickly with the [info] output messages, however at the end of script, there is no new homeassistant or hassio container created or pulled. So when I open the browser at localhost:8123, there is nothing shown.
Dont know how to then start over again with a clean slate to have the hass.io docker image running on port 8123.
systemctl stop hassio-supervisor.service
Sure, tried that by issuing this command first and then trying to delete hassio_supervisor container and image, however to no avail.
This container even after issuing the command magically keeps restarting itself.
Will try posting some images for this behaviour.
===================================
Success this time, maybe due to expert touch by @flamingm0e 
.
Was able to stop service and then subsequently remove container and image.
Gearing up for starting over again, which supposedly should start with the following for Rpi3?
curl -sL https://raw.githubusercontent.com/home-assistant/hassio-build/master/install/hassio_install | bash -s – -m armv71
Thanks.
So, well re ran the script to install Hass.io docker again, apparently it completed successfully
I assume by " [Info] Run Hass.io " it means , to open the browser and point it to localhost:8123 or hassio.local:8123.
So I did, but to my dismay nothing is shown the default blank page still shows.
The network manager is running fine and aint blocking anything in the firewall rules.
However a check for status for hassio supervisor service now shows it is stoppped
Dont know why it has happened, becuase the install cUrl script anyways “enables” and “starts” the service for use and hence throws the “Run Hass.io” message.
The only container to be running in portainer are :
I can see there are no port bindings for hass.io supervisor container. Is it like so, or would it run without any explicit port bindings as well. Is the port 8123 still consumed by old homeassistant docker , hence not assigned to the supervisor docker.
Any help to move forward is appreciated.
==========================
Still not working even when service restarted with
systemctl start hassio-supervisor.service
===========================
Ok looks like a clue.
The service is trying to pull landing page image from a repository that does not exist anymore, its 404. Is it the same on other parts of the internet as well or maybe a problem only with me. So how to fix it , and redirect to a working repository ?
Help returned with smiles and thanks.
You’re getting confused between installing hass.io and installing home assistant in docker. If you see supervisor, it means you installed hass.io @flamingm0e is not a ‘fan of using hass.io and prefers home assistant in docker. My preference is running hass.io in docker so I get all the addons as part of hass.io and managed in hass.io. Whereas the alternative requires you to install seperate docker containers and manage the relationships between them all so they can talk to each other. Neither approach is wrong they are just different approaches and you are tying yourself in knots as you don’t really understand the differences.
I did use the script by Dale3h to install hass.io in docker and was really happy with it.
Well thanks yeah, the confusion was initially there, but if you see the progression of the thread it is sorted out, and I removed an earlier home assistant docker container/images to go the hass.io way. For Hass.io (docker container apporach), i read the thread where even @flamingm0e relplied himself .
This is my preference too, hence I am trying to go this way. You can see all above installation approaches and screenshot to substantiate my claim
Absolutely , althgouh a more Pro approach, this way would require extended learning and learning all nuts and bolts, which may come after a while if I get a quick working start and some initial success.
Can you please point the link to this script, and before running it, I assume I should remove all previous container/script to start afresh.
Ok found it , is it the one ?
The only difference is I am not (niether do I want to) start from a new Raspbian Stretch Lite image, I already have the latest Jessie running, would it make any difference or break of functionality. ?
Thanks.
That is the script.
I 1000% recommend using stretch lite NOT Jessie. Stretch is the latest version of Raspbian and I don’t know why you would want to go backwards!
Is there some reason you don’t want to use Stretch?
Not really, I installed a while ago and let it be, moreover on top of it , I have a running Pi-Hole acting as DNS for all home network devices. So didnt want to upgrade and break any functionality to spend hours in setting up everything again.
But if disto upgrade to stretch is mandatory for going this way then I would have to think about it. Possibly taking an image backup of the current installation, putting an in place upgrade and then trying the script.
We’re talking about a Raspberry Pi where an upgrade is as simple as flashing a card. Is there a reason you need to avoid this?
If I were you I would keep your existing SD as is and then using a second new SD card install Stretch / hass.io in Docker and then see if you can bring your two existing apps over to the new system either standalone or using the available hass.io add-ins… Then you are running latest and supported version of everything. This will make things much easier as you move forward with HA upgrades.
If for some reason you have difficulty transferring Pi-Hole and your Dash setup then you haven’t trashed your original setup.
I agree re: second sd-card. There is a Pi-Hole addon for Hass.io and it’s easy to use I believe. (I don’t use that add-on myself)
Sounds good. For information, can I switch a fully installed (with addons) and setup instance of Hassio on SD Card from one Pi to another Pi . I mean to say are there any configuration variables within HassIo config, which are bound to or fixed on a specific Pi MAC Address and may break when I insert the same SD Card in another PI to make it work.
I was thinking of discarding my Pi exclusively for PiHole and Dash Button instance, and get everything working on one Pi only with Hassio and Pihole+Dasher addons.
Thanks for the information.
You may have an issue if you use wireless but for ethernet, no issue.
