Home Assistant Community

A avid Hassbian and Docker User tries Hass.io


A bit of background:

I’ve been a HomeAssistant user for a little over two years (I got a second service anniversary badge on the forum so I am assuming its been around that time). I started on a Raspberry Pi before Hassbian and Hass.io were available. It was a manual virtual environment install at that time. I’m not trying to brag/boast about my experience with Home Assistant, I am a fairly basic user. What I gave this background for is to show that I’ve tried most of the install methods and can provide comments on the differences based on that experience.

All the details of my current setup are detailed on my GitHub repo (link below). This includes the hardware I run on, the automations I use and all the devices I have connected.

I haven’t tried Hass.io to date as I tend to avoid bleeding edge releases when it comes to Home Assistant. I value stability and ease of use. When Hass.io (Resin.io host) was first released it had some growing pains. I decided to stay on Hassbian until things smoothed out and my lock of knowledge about Docker meant I was more comfortable with my current setup as things progressed. A post from flamingm0e on the forum about his Docker setup got me to try Docker. After getting my setup going with Docker based on his post, I really understand more what is going on under the hood with Hass.io.

What’s the goal here?

  1. I see a lot of users on the forum post about how much a pain in the butt Hass.io is. Lets see if its really as much of a pain as some users make it out to be. What’s the install process like? What’s it like to customize it and tweak settings?
  2. (maybe this is 1a) Do the pros of easy add-on use and the “appliance” model outweigh any roadblocks that are easier on a Hassbian, Venv, or traditional Docker installation? Is there really that much flexibility and customization options lost?
  3. I try to help out on the forum as my way of giving back to this project. As a lot of users are going the way of Hass.io, I can’t really help that subset of users. I tend to just ignore posts in the Hass.io forum. This will either make me a Hass.io user or at a minimum teach me some basics.
  4. I’ve seen quite a few posts about making the conversion asking how-to or pitfalls to be aware of when making the switch. Hopefully this exercise can answer some of those questions.


  1. I am installing Hass.io on top of Ubuntu, this is different than installing Hass.io with a HassOS host (new method) or Hass.io with a ResinOS host (old method) directly on a Pi or other compatible hardware.
  2. Based on 1, I’m not going to install anything or run anything from the Ubuntu side of things (after initial install of course). I actually turned off SSH to take away the temptation.
  3. The time things take are relative, slower/faster hardware or a slower/faster internet connection will definitely change things. For example, restarts on a Pi vs. restarts on a Intel Core series PC with an SSD are night and day.
  4. As I am using a spare SSD for the Hass.io install, I have a fully functioning system after a SSD swap and reboot of the host. As I said earlier I value stability and ease of use, if Hass.io becomes a pain, this whole exercise may not go very far.


Part 1: The Install

Here we go!

Pre-8:51: I made a backup of my entire Docker setup which includes my Home Assistant configs and the backup of all my existing containers (Unifi controller included).

8:51 Starting Ubuntu 16.04LTS install ( 16.04 used due to an apparent conflict with Pi-Hole on 18.04 which I may install later)

8:59 Ubuntu installed and restarted. Installing all available Ubuntu updates. (switched over to a ssh connection so I can copy/paste commands)

9:00 Updates installed, installing dependencies listed at: (https://www.home-assistant.io/Hass.io/installation/#alternative-install-on-generic-linux-server)

9:03 Dependencies installed, restarting

9:07 Docker installed following the convenience script (https://docs.Docker.com/install/linux/Docker-ce/ubuntu/#install-using-the-convenience-script)

9:08 Installing Hass.io, per (https://www.home-assistant.io/hassio/installation/#alternative-install-on-generic-linux-server) Hass.io installed, navigating to the IP says preparing Hass.io. I had to run this as the root users to get it to install, something that is not noted in the Docs. With Sudo or just using the plain command it could not create the required directory. (edit: This is in the docs, I apparently just can’t read)

9:09 It’s Ready!

9:09 Lets pause the clock here as I need to install the ssh add-on and downgrade to 76.2 as that is what my current config is running (I don’t want to fight any conflicts from the upgrade).

9:17 And were back (give Hass.io a 8 minute credit from here on out). SSH add-on installed and 0.76.2 installed. That was pretty easy.

hassio homeassistant update --options "version=0.76.2" did the trick

9:18 Lets install the duckdns/lets encrypt addon. This was super fast and simple. splitbrain provided a great guide for Hassbian/Venv users which I think is great and quick, however, this was next level easy. (https://github.com/SilvrrGIT/HomeAssistant/wiki/Let’s-Encrypt-Setup-(Hassbian,-Python-Virtual-Environment))

9:19 That add-on is running. Make sure to put your domain and token in “quotes”

9:20 Let’s get samba running so I can move my config over easily.

9:22 That is running, and it works well. Its nice that the system auto checks your add-on config and won’t save it if it’s incorrect.

9:23 Lets stop and move the disk over to my normal server. I don’t have a monitor/keyboard/mouse on my server so I used another computer for initial install.

9:30 Swapped over and booting up. Boot up time from power off state seems similar to other install methods.

9:37 Restarting HomeAssistant, I moved the config over (via samba the share) and removed some stuff I knew would throw errors until I install more add-ons (ie. mosquitto will error out until the moquitto add-on is running, same goes for Unifi based device tracking).

9:41 Ok, that was smooth. Let’s get mosquitto, TasmoAdmin, RPCshutdown, Portainer, Unifi Controller , NUT installed.

These went relatively smoothly. I ran into an issue with the Unifi controller and port 1900 which required some searching on the forum and the Unifi forum. Port 1900 is used for UPNP which I don’t use and don’t recommend you have on unless you have a specific reason to be using it. In the port settings for the add-on config just delete the 1900 from the port association line and it wont try to bind to that port.

Nut took longer than it should have as I didn’t notice I had the nut sensor in my Home Assistant config pointed at the wrong IP, this should have taken less time, this was my error, not anything to do with Hass.io. However, the IP issue aside, this was a super easy install compared to when I tried to install via ‘normal’ Docker or directly on my previous ubuntu host.

I was using HADockermon in my current Docker install which doesn’t seem to be available. However, using the Hass.io menu I can start/stop/restart containers so I’m not sure I need that container any longer.

The RPCshutdown container is a nice thing to have, I previously used this to shutdown computers around the house when we are gone and lost the ability when switching to docker. I need to figure out how to add more than one computer to the config through.

Restarts seem to be just as fast as traditional Docker or a Venv install were. RAM and CPU usage are on par also, if not a bit lower than my straight docker install.

10:34 Done, time for bed. I would say I was done with the install of everything at ~10:15. The rest of the time was tweaking things in my config.

Part 1 Summary / TL;DR

I expected this to go pretty smoothly, and it did. I think the switch could be done in under an hour if I didn’t run into some of the hiccups. The add-on experience is great, quick and simple to install and simple to configure. I don’t think I could have installed all of those programs to Ubuntu directly that quick and setting up a Docker Compose file took longer as there was some learning to be done as a new user. Hassio provides a much lower bar for entry and getting up and running.

The real test is going to be how flexible this system is when I want to tweak stuff. I’ll have thoughts on that in the future.

1 Like


Thanks for the information so far. I’m looking forward to the flexibility reviews. I’ve been here for a little over a year and being an old unix/linux guy I am most comfortable at the command line. I’ve always found canned packages to be a hinderance to me. But in that respect I am not like the majority of people that like things very much so plug and play. Hass.io is a great entry point into that world. It will take a lot of people like you who are willing to take the time to play with Hass.io and figure out how to do things using the system to really get it to plug and play. Thanks again for taking your time to put this together.

1 Like


Part 2: One Week Later

My plan was to let Hass.io install get it setup and then let it run for a week. One of the things I really try to maintain with my Home Automation is stability. I have to leave town for work sometimes or just get busy with life and don’t want to have to mess with Home Assistant to keep things going to fix an issue.

Hass.io has been super stable. I did run into one issue with the cpu speed sensor where it would cause elevated processor usage and slow the overall system down. I think I had this once before on Docker also, not sure what causes it. There is a pull request to add a note about it now (https://github.com/home-assistant/home-assistant.io/pull/6511) I removed that sensor (I don’t really need it anyway) and processor use is < 2% unless I’m restarting or installing something.

I added pi-hole and Dasshio to the list of containers. I’m amazed that with all this running I only use between 30 and 40% of my 4GB of available RAM.

The other change I made was migrating to Lovelace as my default UI, I found the conversion add-on and figured I would just give it a try to see how it worked. I was amazed that it converted my current setup into a single file and everything was just like it was. Easy peasy and done.

I did initiate two pull requests to the documentation to try and ease the pain going forward based on some items I discovered.

Whats the plan going forward?

  • Backup testing. Snapshots are easy to make. How does size compare to my past manual methods. What is the restore process like, how long does it take, how seamless is it?

  • Security. Initial testing says its secure, none of the sky is falling hass.io opened ports for me were true (shocked, lol) However, I still need to look into this more.

  • Long-term ease of use. See the second goal from the first post.



Part 3: Backups and Restoration

This was a big one for me, how easy is it to back things up and how easy is the restore. I figured I would give Hass.io a bit of a worse case scenario. When I started this hass.io adventure I ran it on top of Unbuntu and was running on an dell optiplex desktop. Lets try and throw a wrench in the works, switch back to a Raspberry Pi (oh how I love your tiny power draw) and also switch to HassOS at the same time. So not only a backup and restore but switching host devices and operating systems.

I pulled a fresh full backup moved it to my desktop and then pulled the plug on the optiplex. Prepared the SD card for the Pi and fired it up. HassOS came to life with relative ease and speed. I added the samba add-on, moved the backup I just made into the directory and told it to restore.

The first two times it didn’t seem to take action, not sure what was going on behind the scenes. The third time I knew the wheels were turning when I lost my connection. I may have just not been patient enough, not sure what the glitch at first was.

At this point I fired up ‘The Waiting’ from Tom Petty and decided to see what happens. It was already midnight when I started this grand idea so I decided to go to bed and see what things looked like in the morning.

By the time I got to bed and got settled I had the front end back with my setup mostly intact. After plugging in my zwave stick and USB for my UPS and giving her a restart I was mostly back. I run a number of add-ons and some of them didn’t come back, it seems the more fringe cases of dasshio and nut didn’t come back with the restore. Full list below.

I have my add-ons config saved in a separate backup file so these were easy to copy/paste and restore once installed. However, given that all the information is there to restore them, I am not sure why they are not restored.

I have seen a number of people post on the the forums that backup and restore doesn’t work. I wonder if this is an issue of patience sometimes. On the server my daily backups were completed within about a minute. Last night after the switch the same backup took 4 minutes. I wonder if some, especially those with big configs, aren’t waiting long enough for the backup to complete. A nightly backup is great to make it something you don’ have to think about.

Same goes for the restore. It took awhile, especially on the Pi. When I think about downloading and installing 9 add-ons and restoring the config and getting everything to make that run it doesn’t seem like an excessive time to restore when I think about it.

Conclusions on Part 3?

The backups are dead simple (see above automation) and If you want a full restore its there, if you just need to find some code you lost you can easily navigate through the tar file and pull it out.

Restorations I have to dock a few points as ALL of my add-ons were not restored. If I were someone who ran alot of custom add-ons I would be a bit miffed that I had to restore all that.

My biggest advice is be patient, take a look at the size of your backup files and keep in mind that all of that has to be written to disk and run through the CPU. Given that a lot of users run on a Raspberry Pi, the limited CPU speed and disk speed can make this seem like a lengthy task.

Lets compare the restore time to Hassbian or Hassio ontop of a generic linux distro. Hassbian and Hassio for that matter, the HomeAssistant restore time is basically the same. Move the backed up config files into the new config directory and restart. The big difference comes with getting to that point. Hassbian is pretty hands off, getting ubuntu installed and hassio installed on top would probably take about the same time as the entire restoration I just made.

Add-ons is where things get interesting too. Running Hass.io in docker would be about equal to get the extra things setup. Docker-compose makes this really easy. I call this effort a draw. Now getting all those extra things going on hassbian and I would have been up really late, installing the unifi controller, setting up duckdns and getting my certificate going takes quite a bit of time. Big win for the hassio/hassos method here.

Whats the plan going forward?

  • Security. Initial testing says its secure, none of the sky is falling hass.io opened ports for me were true (shocked, lol) However, I still need to look into this more.

  • Long-term ease of use. See the second goal from the first post.



Its nice toread a post like this especially when written by someone who has the skils to write almost novel like!
My backup apporach is a little different. I use syncthing to always have the config directories synced to my main computer and a small laptop. The files are also backed up to dropbox every day midnight frommy main computer. This way I always have a working set of config files even if I fuck something up. I always see to it that my configs work when they are sent to dropbox. Using syncthing I can change the config on my main computer and they will be automatically synced with the HA computer within 30 sec.
This workes perfect for me. I run on a ubuntu with docker. Not Hass.io



Part 3a: Backups and Restoration (again)

Ok, my longterm goal has been to get back on ESXi and have HA among other things in virtual machines on a single low power host. I had kind of given up on this for awhile due to having issues with ESXi and networking but I seemed to have worked through those issues.

So last night I worked through the ESXi setup and created a couple of Ubuntu virtual machines that I use as base images when testing other things or sandboxes for messing around. Everything went smooth with those VMs so I created a HassOS virtual machine. Had a couple of hiccups in getting it going as it is being started from a VDMK which I have never done before. EFI boot, and changing the disk type I think it was ended up doing it. I beleive the devs are currently trying to make this process easier.

Well then lets try transferring over to this new virtual machine. My nightly backup automation ran last night as it has every night and I pulled that image down to my laptop, shutdown the Pi and booted the VM. I setup the samba addon to drop the backup file into the backup directory. Restarted HA to make it look for the backup file and then did a wipe and restore.

It came up much quicker this time as there is a lot more processing power available to process the restore. Long story short, everything is up and running and needed no intervention on my end to restore it.

Doesn’t get much easier than that!

1 Like


Did you manage to create the VM with an expanding disk? Everything I tried would not give me the ability to resize the disk. Eventually it filled up and then crashed and would not recover.

I’ve ended up with a DietPi based VM with the Hassio docker installation which (so far) has worked flawlessly.



I resized it and HA saw the increased size. However, system monitor doesn’t seem to reflect that, it says Ive used 40% of my disk. Well see how that part goes. My log doesn’t get very big and I am decent about cleaning up the daily snapshots. The command line side of hass said I have 12+ GB left though.



Any guide that you followed to create a hassos VM? I’d like to do something very similar (single host for HA and some other VMs for testing)? Are you using VMware?



I like your information. Maybe you can point me in a better direction? Apples/oranges – in the same crate [container]?

Tinkered with openhab on Rpi3B+ and did not like it. Love HA. It is ‘Etchered” to SD card and running nicely with WU, konnected, ups, FedEx, text-to-speech, DirecTV, tuya, chamberlain garage door (myq), skybell, ASWRT. [Want to add my Omni Pro II.]

Everything is wonderful. However, I am confused by determining “best practice” to add Docker, NodeRed, OmniLinkBridge, MQTT. Although I love trial and error, and I enjoy reading through all the forums and documents, I need a pointer now so I can “finish” in this lifetime. As I understand it, there is a move afoot to “move MQTT platforms under the component”…

I read that hass.io is “containerized” already and that is where I am confused. I added configurator, samba share, mosquitto broker, and migrated to Lovelace.

I am sold on Docker and want to install. So what is the best practice to add it, then NodeRed, OmniLinkBridge. Do I uninstall the mosquitto broker and put MQTT in Docker?

… more reading to do… :sweat_smile: h



So hassio is running in docker.

If you install hassio it creates two docker containers. A supervisor container and a home assistant container.

For clarity (or maybe not) you installed Hass.io onto your raspberry Pi. The operating system is HassOS which is a very stripped down minimal operating system developed to run just Hass.io.

Those are just containers being added to docker. An “add-on” is just a container specifically designed for Hass.io. Its designed to be installed through the Hass.io menus and interact with Hass.io/Homeassitant as needed in a seamless manner.

You already have it installed if you installed Hass.io!

Look for an add-on. That is your easiest path for installation.



May be the wrong place but portainer is not very helpful to me with docker - or maybe it is running into this issue also. so i tried it in cli: (please pardon the lack of proper formatting. NOOB to this. fair with linux; super with windows… (DOS ok, fortran -forgot…)

docker run -d --name=“omnilink-bridge” -v /opt/omnilink-bridge:/config -v /etc/localtime:/etc/localtime:ro --net=host --restart unless-stopped omnilink-bridge
5a1c67e5358df195Sbba25608027f 11070c166f51a832a508500d57144377cad

docker: Error response from daemon: error while creating mount source path ‘/opt/omnilink-bridge’: mkdir /opt: read-only file system.

I don’t feel comfortable blindly changing permissions. Any idea what gives here? it did same way in portainer….

add-on git



Are you running hassOS or hassio ontop of another linux operating system?



no. afaik just hassio on RPi3 by-the-book install. Added add-ons from community- they do not show up in Portainer. Only OnmiLink does and it won’t start because “Error error while creating mount source path ‘/opt/omnilink-bridge’: mkdir /opt: read-only file system”.

Addons= configurator, DuckDNS, Logviewer, MariaDB, Mosquitto broker, NGINX HA SSL proxy, NOte-red, Portainer, SSH&Web terminal, Shaba share, motion eye. The all work.

Do I need to find the opt that Omnilink wants to use and chmod?

this is in the script

Binds [ /opt/omnilink-bridge:/config. 
/etc/localtime:/etc/localtime:ro ]

TIA for your input



I don’t beleive you can run docker containers on HassOS unless they are an add-on.



I think you can with the portainer add-on. It ties into the docker socket and allows for straight docker but probably requires mapping volumes



Many thanks for input.

This is the error message that I get:


error while creating mount source path ‘/opt/omnilink-bridge’: mkdir /opt: read-only file system

Back to my nightmare aka headache (ha) with Hass.io (HA). My ffamily misses me.

Recap : hass.io image -> RPi3. Portainer for Docker. Other images [only] show that were installed by system. git Omnibridge -> Portainer (which is Docker ce).

**Will not start. Get error listed above.**

Inspection of the container:


Args [ OmniLinkBridge.exe, -i, -c, /config/OmniLinkBridge.ini, -s, /config/WebSubscriptions.json ]
Config { ArgsEscaped: true, AttachStderr: false, AttachStdin: false, AttachStdout: false, Cmd: mono,OmniLinkBridge.exe,-i,-c,/config/OmniLinkBridge.ini,-s,/config/WebSubscriptions.json, Domainname: , Entrypoint: null, Env: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin,MONO_VERSION=, ExposedPorts: [object Object], Hostname: hassio, Image: omnilink-bridge, Labels: [object Object], OnBuild: null, OpenStdin: false, StdinOnce: false, Tty: false, User: , Volumes: [object Object], WorkingDir: /app }
Created 2019-02-17T21:50:26.285372923Z
Driver overlay2
GraphDriver { Data: [object Object], Name: overlay2 }
HostConfig { AutoRemove: false, **Binds: /opt/omnilink-bridge:/config,/etc/localtime:/etc/localtime:ro**, BlkioDeviceReadBps: null, BlkioDeviceReadIOps: null, BlkioDeviceWriteBps: null, BlkioDeviceWriteIOps: null, BlkioWeight: 0, BlkioWeightDevice: , CapAdd: null, CapDrop: null, Cgroup: , CgroupParent: , ConsoleSize: 0,0, ContainerIDFile: , CpuCount: 0, CpuPercent: 0, CpuPeriod: 0, CpuQuota: 0, CpuRealtimePeriod: 0, CpuRealtimeRuntime: 0, CpuShares: 0, CpusetCpus: , CpusetMems: , DeviceCgroupRules: null, Devices: , DiskQuota: 0, Dns: , DnsOptions: , DnsSearch: , ExtraHosts: null, GroupAdd: null, IOMaximumBandwidth: 0, IOMaximumIOps: 0, IpcMode: shareable, Isolation: , KernelMemory: 0, Links: null, LogConfig: [object Object], MaskedPaths: /proc/acpi,/proc/kcore,/proc/keys,/proc/latency_stats,/proc/timer_list,/proc/timer_stats,/proc/sched_debug,/proc/scsi,/sys/firmware, Memory: 0, MemoryReservation: 0, MemorySwap: 0, MemorySwappiness: null, NanoCpus: 0, NetworkMode: host, OomKillDisable: false, OomScoreAdj: 0, PidMode: , PidsLimit: 0, PortBindings: [object Object], Privileged: false, PublishAllPorts: false, ReadonlyPaths: /proc/asound,/proc/bus,/proc/fs,/proc/irq,/proc/sys,/proc/sysrq-trigger, ReadonlyRootfs: false, RestartPolicy: [object Object], Runtime: runc, SecurityOpt: null, ShmSize: 67108864, UTSMode: , Ulimits: null, UsernsMode: , VolumeDriver: , VolumesFrom: null }
HostnamePath **/mnt/data/docker/containers**/db39460e732a38318e23b50f4ba83b656f30a8d5d8d1e4fe2413ebd48f9f7dba/hostname
HostsPath /mnt/data/docker/containers/db39460e732a38318e23b50f4ba83b656f30a8d5d8d1e4fe2413ebd48f9f7dba/hosts
Id db39460e732a38318e23b50f4ba83b656f30a8d5d8d1e4fe2413ebd48f9f7dba
Image sha256:e2dcb83c01c4045c8ad13a181fe3ec78a77c5e6c4927b189589e277cdd713504
Mounts [ [object Object], [object Object] ]
Name /omnilink-bridge
NetworkSettings { Bridge: , EndpointID: , Gateway: , GlobalIPv6Address: , GlobalIPv6PrefixLen: 0, HairpinMode: false, IPAddress: , IPPrefixLen: 0, IPv6Gateway: , LinkLocalIPv6Address: , LinkLocalIPv6PrefixLen: 0, MacAddress: , Networks: [object Object], Ports: [object Object], SandboxID: e6dd5a855e58e1e7605c3025b0437f28bd5534d63ba514ad40f506793c539460, SandboxKey: /var/run/docker/netns/default, SecondaryIPAddresses: null, SecondaryIPv6Addresses: null }
Path mono
Platform linux
ResolvConfPath /mnt/data/docker/containers/db39460e732a38318e23b50f4ba83b656f30a8d5d8d1e4fe2413ebd48f9f7dba/resolv.conf
RestartCount 0
    Dead false
    **Error error while creating mount source path '/opt/omnilink-bridge': mkdir /opt: read-only file system**
    ExitCode 128
    FinishedAt 0001-01-01T00:00:00Z
    OOMKilled false
    Paused false
    Pid 0
    Restarting false
    Running false
    StartedAt 0001-01-01T00:00:00Z
    Status created

I have tried to create directoris with 777 rights just to see if it works.

Any advice on where/what/why?