I’ve given myself a little project for the summer…
It’s been two years since I rebuilt my home server and now I’m going to do it again. Last time, I wanted to move Home Assistant to Docker in order to make it easier to maintain than my previous approach of simply installing the Python modules. Keeping dependencies up to date was a chore, and Docker eliminated that hassle.
It’s not perfect, though, and there are advantages to running the Home Assistant OS. The OS version of Home Assistant is designed as a complete solution to run on either a dedicated device, such as a Raspberry Pi, or inside a virtual machine. It has an add-on store, making it easier to add features, and can be updated to the latest version directly through the user interface.
I’ve managed with Docker so far, and it’s worked well for me. I don’t need many of the add-ons that would be useful when running on a dedicated device, such as SSH access and Samba file sharing, as I run those on the underlying OS. The thing that’s tipping me towards the change is Z-Wave.
I use the basic Z-Wave integration, which has been deprecated. The recommended option is now Z-Wave JS. Unfortunately that’s not included in the Home Assistant container. To use it, I’d have to install it separately and configure the Home Assistant integration to use it. I’d then have something else to maintain myself. It might be as simple as another Docker container, but it’s still an overhead. If I was running Home Assistant OS I could install it as an add-on with a couple of clicks.
While I can understand the reasoning behind the change to Z-Wave JS it is slightly irritating. I’ve been running Z-Wave for years now using the integration built in to Home Assistant. The change to Z-Wave JS means that the recommended method is no longer available using just a Home Assistant container.
It’s not a pressing issue and not something I need to do immediately. The documentation states that “If you are currently running on the zwave or ozw Z-Wave integration and it works fine, there is no need to switch over at this time to Z-Wave JS. It is important to know is that most development focus currently goes to Z-Wave JS. The previous implementations are still provided as-is. They will NOT be removed without proper notice but in time there might come technical dependencies that render one or both of those integrations unusable.”
If history has taught me anything, though, it’s that it’s only a matter of time until I need to make the switch – eventually there’s bound to be one of those dependencies that renders the integration unusable…
So I decided to move from Home Assistant on Docker to Home Assistant OS. As well as making it easier to install and run Z-Wave JS it would also be interesting to try the full Home Assistant experience. I often recommend Home Assistant to people and advise them to use Home Assistant OS, as it’s the easiest way to get started and is suitable for users with less technical experience, so I felt I ought to know what that experience was like.
That left me with two options to consider. Home Assistant on a dedicated device or Home Assistant running as a virtual machine on my server.
I decided to take the second approach. I also thought that it would be a good opportunity to upgrade my home server to something with a little more grunt – particularly CPU cores and RAM. Virtual machines require more resources than docker containers and additional CPU cores would be particularly useful.
I ended up with an Intel NUC. The spec is overkill – a 6 core/12 thread i7 with 32GB RAM, a 512GB NvME drive and a 2TB hard drive repurposed from my old machine.
I obviously don’t need that level of spec for Home Assistant but I’ll also be running other things on it – including, possibly, Zoneminder… although more on that in a future instalment.
Over the next few weeks I’ll be documenting my setup. I’m going to start with a clean slate rather than import the configuration from my current installation. It’s an opportunity to clear out accumulated junk from my configuration and also to see what Home Assistant is now like for a new user starting from scratch.
I’m also planning to consolidate some of the other services that run on my server into Home Assistant – so, for example, rather than running InfluxDB and Grafana separately I’ll be using the Home Assistant add-ons. My rule of thumb will be to run everything under Home Assistant where I can.
There will be some exceptions. I’ll still run Apache on the host OS, as it will act as the gateway to Home Assistant OS and other services, which means that I’ll also be managing LetsEncrypt and dynamic DNS on the host. Those things are necessary to allow external internet access to my systems.
For anyone new to Home Assistant and without previous Linux experience, I would strongly recommend that you don’t open up incoming ports on your router and expose your system to the internet. The best way to get secure access to your Home Assistant installation from outside of your home is to use Home Assistant Cloud. It’s only a few pounds a month and it helps to fund Home Assistant. I subscribe for the easier integration with voice assistants, but I think I’d subscribe even if I didn’t need that simply to support a product that I use every day and is invaluable to me.
It’s worth repeating. Don’t open up your home network to the internet unless you are very sure that you know what you’re doing. Even then, it’s a risk. I’d be reluctant to do it myself if I didn’t need to run other services that don’t currently integrate into Home Assistant, and I try to have multiple layers of security. Home Assistant cloud is much safer, as your local Home Assistant instance only needs outbound access to the internet, with the cloud service taking care of remote access.
With the project defined, I’m hoping to increase my blogging frequency from my usual fortnightly posts to every week. So next week I’ll be looking at which base OS I’m going to use on my home server…in Home Automation