HA Migration from Docker to HAOS & Backup

[Pilotbum]

I am running HA in a docker container inside an Ubuntu machine. The Ubuntu machine will be going away and I will be moving my HA to a dedicated machine running HAOS.

Do the backups I create in the docker container just backup the configs, and not necessarily the software, or is it a backup of everything? I mean, if I back up the current instance, can I just restore it to the new HAOS instance?

Also, most of my devices are Z-Wave. So with the new instance, can I just move the Z-Wave controller over to the new instance and have it recognize the controller and all the devices in it? Will the backup also see the Z-wave and recognize the devices?

I’m trying to make this as painless as possible.

Thanks

[brystmar (Thomas)]

How did this go?

I’m planning to migrate from an RPi (running HA in a docker container) to a dedicated NUC (running HAOS) in the somewhat near future. Really hoping that a backup of Z-Wave JS will allow me to retain all the settings for the ~70 z-wave devices in my setup.

[Pilotbum]

Flawless. Your devices are all saved to your Z-wave dongle and HA makes them entities.

I installed mine on a NUC as well and followed these instructions to make HAOS a VM in Proxmox. Highly recommend it too.

[brystmar (Thomas)]

Precisely the guide I bookmarked for my upcoming migration!

Glad to hear the z-wave transition went smoothly. How did the HA transition go? I take regular backups of the /config directory. Do I just unzip those archives into a similar folder on the HAOS install? Will my HACS integrations work in HAOS?

Also curious which NUC you chose. I see plenty of used 8th generation i3 NUCs in the ~$95 range on ebay. Debating if it makes sense to throw in a few more bucks for a ~10th gen instead.

[Pilotbum]

Pretty much everything went as advertised. Follow the instructions on that link for proxmox and HAOS install, make a backup of your current HA, download, and install as soon as you fire up the new instance. Everything came over and worked just fine including HACS and all integrations, automation & scripts. The only thing that you have to do within ProxMox that I don’t know if I missed in the main instructions or not is make the USB visible to HAOS VM.

Mine is an 8th gen NUC Hades Canyon NUC8i7HVK. I have two of them, the other is my windows PC. I’m certainly no expert, but I’m pretty sure any of them will run HAOS just fine. Previously, I was in a docker container on a NUC Ghost Canyon with an i9 so this was a downgrade, but I can’t tell a difference. The Ghost was running other stuff as well. The new one is just HAOS and I’m trying to get Frigate running on it.

[brystmar (Thomas)]

My NUC10i3 arrived yesterday. After fiddling with the HAOS install on Proxmox for a bit, and even restoring from my backup, I ended up re-installing HAOS on bare metal to silence my brain’s questions about performance and hardware allocation. This NUC is exclusively a hassbox, nothing else.

The built-in Backup feature made restoring everything a cinch. I’d actually forgotten that the containerized version of HA included this Backup feature; my offline backup solution was easy in the container world but challenging otherwise.

Z-Wave took a bit of troubleshooting though, so I’m adding my experience here in case anyone else finds themselves in the same boat. I found myself in an irrecoverable loop, and this guide was my saving grace. I have a few things to add.

~~ EDIT: Ignore my instructions and follow @freshcoast’s guide in post #7 instead. ~~

Before migrating, open up your existing Z-Wave JS UI page and click the green Export button under Settings. Save this on your local machine.

This next backup might be redundant, but I figured better safe than sorry. Go back to your list of nodes and click the hamburger button > Advanced Actions. Click Export under the Backup section. Save this locally too, just in case.

When migrating to HAOS from HA container, you’ll see two relevant add-ons in the store: Z-Wave JS, and Z-Wave JS UI. I figured one was the backend, one was the frontend. Nope! You cannot run both at the same time, so pick one. Coming from the container world, I like sticking with Z-Wave JS UI.

If, like me, you like making things harder for yourself, you probably set the WS port to a non-default value. Write that down and pinch yourself as punishment. Or better yet, update the config back to using port 3000 after restoring your settings.

Once you’ve restored your HA from backup, install the Z-Wave JS UI add-on and adjust its config (including the default port if necessary). Start the add-on, import those two backup json files we made earlier, then save. You may need to restart the add-on and/or HA.

If you end up needing to re-add the Z-Wave integration under Integrations > Z-Wave like I did, you’ll need to modify the default ws://localhost:3000 string in the dialog box by replacing localhost with the hostname displayed on the addon page. For example: ws://abcd1234-zwavejs2mqtt:3000.

That did it for me. Hopefully others find this helpful. Here’s to smooth sailing on NUC bare metal!

[freshcoast (Z-Wave AI Bot)]

Glad you got it working, but I have a few comments/suggestions that may help others that read this.

Before migrating, open up your existing Z-Wave JS UI page and click the green Export button under Settings.

This next backup might be redundant, but I figured better safe than sorry. Go back to your list of nodes and click the hamburger button > Advanced Actions.

The first backup is important because it has your Security keys. The latter is not redundant, it includes the node names and locations you’ve set in ZUI (not included in settings), which is nice to have. I don’t see any mention of backing up and restoring the driver cache, do you not have any battery nodes that required manual re-interviews?

You can download all relevant files at one time from the Store page using the Backup function. It’s a ZIP file which includes everything you need to restore smoothly to a new install of ZUI:

1. Security keys from settings
2. Names and locations of nodes
3. Driver cache (*.jsonl files)

The first is important because securely included nodes won’t work without security keys. The last is also very helpful because restoring these can save you a lot of time, you won’t need to re-interview your nodes.

If, like me, you like making things harder for yourself, you probably set the WS port to a non-default value. Write that down and pinch yourself as punishment. Or better yet, update the config back to using port 3000 after restoring your settings.

Once you’ve restored your HA from backup, install the Z-Wave JS UI add-on and adjust its config (including the default port if necessary).

In the case of a container restore I would recommend importing old settings, but for migrating to the add-on I would not, unless you really know what you are doing. Doing so may import some settings that conflict with the add-on configuration, which is already setup correctly for integration with HA by default. For example, you may include things like a no longer valid USB path, unnecessary port or host changes to the websocket server, or TLS settings that will break the add-on as it supports TLS natively. For those reasons I would just re-configure manually.

First import cache files and node names:

1. Import the *.jsonl files from the backup by uploading them into the store directory.
2. Import the nodes.json file for names and locations as mentioned

Then configure the settings:

1. Copy your security keys from the backup into the add-on settings
2. Pick the USB device path from the pull down menu
3. Turn on any other settings you prefer like logging. Do not change websocket host or port!
4. Don’t forget to Save, which will trigger a restart.

I’d also recommend disabling the Z-Wave integration before anything, so it’s not trying to connect while you make changes.

You can get an idea of the process by looking at my add-on migration guide: https://community.home-assistant.io/t/switching-z-wave-js-addons-with-minimal-downtime-z-wave-js-official-to-z-wave-js-ui-community/409904. It’s going to have several similarities, especially in regards to the driver cache restoration.

For example: ws://abcd1234-zwavejs2mqtt:3000.

It seems people think this is a unique URL. In order to not propagate this idea, the URL is the same for everyone that uses this add-on, ws://a0d7b954-zwavejs2mqtt:3000, it’s not a secret. You’ll find the URL explicitly given in the step by step instructions of the add-on installation instructions, so just save time following those.

[brystmar (Thomas)]

I don’t see any mention of backing up and restoring the driver cache, do you not have any battery nodes that required manual re-interviews?

You can download all relevant files at one time from the Store page using the Backup function. It’s a ZIP file which includes everything you need to restore smoothly to a new install of ZUI:

1. Security keys from settings
2. Names and locations of nodes
3. Driver cache (*.jsonl files)

The first is important because securely included nodes won’t work without security keys. The last is also very helpful because restoring these can save you a lot of time, you won’t need to re-interview your nodes.

Oh man, this was SUPER helpful. Shortly after finishing my post above, I found that I needed to re-interview about half of my battery nodes. Also noticed that some of my automations weren’t working, especially the ones which updated config settings for things like button LEDs. This is probably why.

I disabled the Z-Wave integration, uninstalled the ZUI addon, then reinstalled it following your instructions. The only issue I encountered was that the UI wouldn’t allow me to upload to the /store folder. The UI kept insisting the path was null, even when I used the “Upload File” link in the context menu from the /store folder itself. And there’s no user-editable way to specify the destination folder.

This is my first time working with add-ons, and I’m not familiar with their folder structure yet. So when I didn’t see a zwave folder with a /store subfolder in the /addon_configs, I felt more comfortable going a different route. Ended up using the Restore feature with the zip file, then updating config where needed. It took some time (~5 minutes?) for everything to settle, which is probably to be expected.

I then imported my backup nodes.json file to update the names/locations, re-enabled the Z-Wave integration, and was off to the races. Devices and automations work as expected once more. Thank you so much for the writeup!

[freshcoast (Z-Wave AI Bot)]

@brystmar

The only issue I encountered was that the UI wouldn’t allow me to upload to the /store folder. The UI kept insisting the path was null, even when I used the “Upload File” link in the context menu from the /store folder itself. And there’s no user-editable way to specify the destination folder.

The “Upload File” feature to a specific folder is new functionality added about a month ago that I haven’t tried yet. I think it just uploaded to the root store directory by default. That error looks like a new bug in ZUI. I am able to upload a file to a sub-directory but not the root directory (same error).

This is my first time working with add-ons, and I’m not familiar with their folder structure yet. So when I didn’t see a zwave folder with a /store subfolder in the /addon_configs, I felt more comfortable going a different route.

Unfortunately the ZUI add-on doesn’t use the addon_config directory like the core add-on does (which my guide relies upon). It does expose the /share directory but I’m not sure what the purpose of that is as the directory doesn’t seem to be used (at least I don’t see it).