`type or paste code here`
I did a reset on DNS on my router and Its all working fine now
Thank you for all the suggestions
Cheers
`type or paste code here`
I did a reset on DNS on my router and Its all working fine now
Thank you for all the suggestions
Cheers
I just recently migrated to using HassIO via Docker on Unraid! And, Iāve been very impressed by itās perferformance and low resource usage ā itās working Great for me!
Update 09/03/2019:
Unfortunately after a week or so the docker container actually started becoming gradually more unstableā¦with the HassIO container continually stopping itself. I struggled with it for a while but eventually the HassIO container would stop on its own after a few seconds. In addition to the odd orphaned containers and quirky behavior with Unraid recognizing updates even if you donāt want to update, I couldnāt even use the HassIO features (eg take a config snapshot) because of this instability in Unraid.
So I switched over to running HassIO as VM in Unraid and it has been significantly more reliable! I used the video posted here and itās running great with the VM set to use up to 2 cores with 512MB RAM (keeping the VM footprint t minimal on my 8GB RAM Unraid server) and itās been far more reliable for over 3 weeks now!
Original Post Below:
In case it helps anyone else hereās a summary of what Iāve done:
My RPi that randomly died in early July, so I decided to take this approach to see how it might go . . . and Iāve been very impressed. As many have noted in this thread (and others) itās very snappy: full restart in ~20 seconds (vs minutes in my RPi 3), config validates in about 3 seconds (vs 30 in my RPi), etc.
Iām really quite happy with it and enjoy the thought that my Unraid server resources are being maximized because itās a modest server running on an Athlon II X4 620 with 8GB RAM. And I really wasnāt fond of having to block off RAM & CPU Cores for a VM.
Currently the HassIO Supervisor docker container is only using ~47MB RAM, and the actual HomeAssistant Docker container is using ~120MB RAM. CPU utilization seems to stay at similar level as before idling from 4-8%. So the resource utilization is very minimal.
Because I wanted to use HassIO, I was very excited to find that Digblur has already done most of the hard work and provided a Docker template for Unraid for HassIO and he provides alot more details on his Youtube video here, so definitely check that out!
It was pretty easy to get it installed. However, I was concerned that it uses the intel-nuc docker container repository which did not seem right to me . . . so, after breaking down the logic of the actual HassIO installation script (found here), itās clear that HassIO should use the correct docker repo based on the architecture of the system and intel-nuc is not right for an Intel/AMD x86 based PC like my Uraid server.
Instead you should use: homeassistant/qemux86-64-homeassistant
You can know for sure if you get x86_64
as the result from running uname -m
command at your Unraid Terminal:
In addition, after tracking downthis thread for Unraid I gleaned some super useful info. (because Iām not a Docker expert by any stretch) to help me quickly get my Z-wave stick back up and running too with the mapping also shown belowā¦
Hereās my docker configuration screen for an Athlon II X4 620 (x86 64-bit) PC server running my unraid:
After installation, I did experience the single odd issue that Digiblur calls out on his Youtube video, with the non-standard docker for HomeAssistant not starting in Unraid. But the little trick Digiblur notes on his video worked perfectly and itās never been an issue since!
As he notes there are some oddities observed in Unraid when HassIO installs addonās that are actually other containers. And, honestly I wasnāt too happy with the LetsEncrypt container in HassIO anyhow (it often failed to renew my certs). So rather than re-insall the various add-ons I used on my RPi (e.g. Samba, SSH, LetsEncrypt, etc.), I opted to fullfill as much of these with Unraid Apps (Dockers) instead.
Iām using the very easy and elegant NGINX Proxy Manager docker app for Unraid to manage all SSL certificates, and provide domain routing & security to HomeAssistant. And, thatās the last hurdle I had to get past . . . which took some additional debugging of IP addresses, but the main thing I learned the hard way was that Web Sockets must be enabled for the proxy host pointing to HomeAssistant! Once I figured that out then I was able to simplify my config back to what made sense and remote connections and logins started to work as expected! Thereās yet another useful thread regarding NGINX Proxy Manager setup where I posted a bit more detail on my discovery journey on this!
Other than that, I was able to do a HassIO restore, and was on my way . . . I did have some HomeAssistant configuration cleanup to do since this pulled down the absolute latest version and my RPi was not fully updated (esp. the new Users and user profiles setup), but once I got that all cleaned up and added back in the Integrations I needed (e.g. TP-Link, Emulated Roku, Z-Wave, etc.) everything started working wonderfully!
Iām curious as to what add-ons you had issues with installing as a VM.
I wonder what reasons you have to prefer a docker version of Hassio vs VM.
Also from a backup perspective I wonder how the snapshots work on a docker vs a VM. I know on unRAID you canāt take snapshots of a VM natively so that is a bummer.
I am personally confused on what path to use for my Hassio. Not sure if to go the docker or VM path on my unRAID server.
I know you are asking digblur and not me, but Iām pretty sure he prefers straight Home Assistant on unRaid.
I actually prefer Hassio in the VM as it keeps things more together. Running supervisor as an āappā was interesting, but ultimately the whole environment felt very fragmented compared to running it in a VM.
Snapshots in hassio work the same either way. These are snapshots of your configuration directory and addons. They will be either stored in unRaidās appdata directory or the storage allocated to the VM, depending on what route you take.
Thanks for your input! I feel the same way.
One question I have for you is do you HAVE to assign logical CPUs? I have an AMD FX-4100 which is only 4 cores and would not like to designate 2 cores for this VM. I am wondering if you do CPU pass through only if that is enough.
I started with HA as docker so of course that is my preference. I have tried both methods along with running hassio in docker. I kept going back to straight docker.
It just keeps things simple for me. No dependency on anything as it is all modular. Easy to troubleshoot, configure and even rollback if needed. For instance it allows me to run two copies of HA on the same MQTT server with ease.
I donāt need snapshots as all of my files are backed up in real-time and versioned automatically. I just pull the files I need or reference them when needed. Crashplan docker does that part.
My way isnāt the best way for everyone. I say try it all and use what you are comfortable with.
Thanks @digiblur!
I went the VM route, but still not certain if I will stick with that. I personally like to compartmentalize and would prefer to have a simple way to just go back in time if I make a mistake on my HA setup to roll back, so make use HassIO in VM to keep snapshots of that, and figure out how to backup NR. OR may use NR inside Hassio to backup those together. I have heard NR inside Hassio is more limiting but I assume you can use multiple different instances of NR (i.e. a NR docker and a NR inside Hassio) together with MQTT so link them together (?).
What did you mean by this example below?
All of my containers are separate from each other. I have to NodeRed containers, I can swap back and forth where I want things pointed etc. I do only have one MQTT container running as I really donāt need two. Both my Prod and Dev copies of Home Assistant point to the same MQTT container. That way I can test how different devices work and such on dev before I upgrade my prod.
I found all of this easier for me based on trying different Hassio installs as I felt locked in if something didnāt go right on an install, upgrade, or reboot. If Hassio fails to boot for me right now, big deal, NodeRed still runs and so does MQTT. Of course I donāt get the add-on store but with unRaid I havenāt found Iām missing much as they have a whole slew of container templates that allows me to install stuff with just a couple clicks.
I also need to consider moving HassIO into docker. Samba is just too unreliable when with HassIO in a VM, most of the time I cant get to my files.
Interesting. I have no problems with Samba in VM on UnRaid. I do use the samba addon as though the VM were its own actual machine.
Great stuff.
I started with Hass on Unraid Docker, migrated to UbuntuVM with normal install, moved to RPI with hassio, over to Intel NUC with docker-compose and am now full circling back to Unraid Dockers.
Randomly decided to do a quick search for a hassio vm and this thread came up, 10 minutes later I have a fully working HassioVM. Iāll test it over the coming weeks and see if that is a better way to go than regular dockers, but thank you for the effort neither the less. Itās certainly piqued my interest
Like you I ended up using a VM vs docker in Unraidā¦Iāve updated my post above to try and save others from the same struggle but the VM has been far more reliable.
Unfortunately after a week or so the docker container actually started becoming gradually more unstableā¦with the HassIO container continually stopping itself. I struggled with it for a while but eventually the HassIO container would stop on its own after a few seconds. In addition to the odd orphaned containers and quirky behavior with Unraid recognizing updates even if you donāt want to update, I couldnāt even use the HassIO features (eg take a config snapshot) because of this instability in Unraid.
So I switched over to running HassIO as VM in Unraid and it has been significantly more reliable! I used the video posted here and itās running great with the VM set to use up to 2 cores with 512MB RAM (keeping the VM footprint t minimal on my 8GB RAM Unraid server) and itās been far more reliable for over 3 weeks now
The VM is much cleaner and everything is consolidated. Trying to use Unraidās own containers was a fun experiment but quickly became a mess. I still have leftover orphan images that I havenāt figured out how to get rid of.
@cogneato I totally agree! For me, the initial concern was regarding resource sharing and utilization . . . fearing that a VM would require more resources from my fairly limited Unraid server (re-using older hardward with only 8GB RAM)ā¦
But, with shared CPU utilization itās actually negligible, and after I set up the āsystemmonitorā component in HomeAssistant, I can now see that the VM with HassIO uses marginally more RAM than it did in the Docker container. So Iāve been able to decrease my RAM allocation to only 512MB and itās using only 57% of that but running just as fast, and more reliable.
Any one know why the updater shows as unavailable?
@digiblur any hints on how i get a BLE dongle passed thru on Unraid (straight docker, no VM)
Otherwise loving your work. So much faster on my server (and i can reuse the nuc i had it on)
Iām interested tooā¦
Are you both referring to the regular Home Assistant container (non-Hassio)?
I passed through easily from Unraid to the VM, but containers arenāt something Iāve done. I asked @digiblur and itās simply a matter of adding the device in the container settings once youāve plugged it in and found the dev name in the main system log of unraid.
Iām running Hassio container (app).
In your snapshop whatās the usb bluetooth device and how do you find it? The network is host, or bridge?
I donāt run the supervisor app. It was an interesting experiment but I found it to be a disaster in terms of container management. This guide and post is for installing as a VM. If using unraid apps is your only option, youāre better off using the normal Home Assistant container and the rest of unraidās available apps instead of using Hassioās.
That said, you check the unraid system logs to find the device.