I messed up my configuration by incorrectly trying to set my store to a local directory thinking that would be necessary so I could back the data up like I do with my HA docker config.
So now I am trying to backup the store and build a new instance of zwave-js-ui with the correct configuration. But I don’t want to mess it up again so I have a few questions.
I notice that the docker compose example found here has a commented out section to change the store to a local directory. But the maintained version found here doesn’t have this comment. Is it a good idea to change the store to a local directory or should I just be using the backup feature?
volumes:
- zwave-config:/usr/src/app/store
# Or by using local folder
# - ./store:/usr/src/app/store
Should I use image: zwavejs/zwave-js-ui:latest or is it safer to lock in on a version and change it when you want. If I use latest will it pull newer versions when started if there is a new version? I don’t think I would want that. So I was thinking I should use image: zwavejs/zwave-js-ui:8.13.1 which I know is working with my HA instance.
In order to fix my instance I want to backup the store, build a new instance and restore the store files. There seems to be 2 ways to back up the store. If I open the Store tab, select all the files and click on the gear there is a “backup” option and a “restore” option. If I use that will all my changes carry over to the new instance? I think it is but I want to make sure I don’t need to use the backup found in setting to get “everything”.
That is what I mentioned in my reply to your other comment. Use a local path if you want to easily access the files from the host filesystem. If you are backing up the container from within the host, than local volumes are usually easiest. If you are using the backup functionality in the UI, then it doesn’t matter much. It’s mostly your preference.
I always use version tags, again it’s a personal preference. The downside is you need to edit the compose file each time. The upside is it won’t change unexpectedly.
You don’t need to select any files. Just click the blue cog, Backup, then Yes. The download will contain all of the required files. This zip file can be used to restore.
If you are worried, just copy your network keys somewhere (should do that anyways). That’s the minimum you need to backup. At worst you can just re-enter those on a new setup. The Z-Wave network is stored on the controller.
I am glad that you agree that locking on a version makes sense. I wasn’t sure if after you install the container it would check if “latest” was still current or if you had to force it to rebuild somehow. Sounds like for former so I will set my version. I didn’t upgrade HA for 2 years last time so I doubt I will be upgrading again very soon, haha.
I think I will go with letting the store remain local since the backup process is easy enough to use.
If you run docker compose pull, it will pull all the containers. If latest is a new version, it will update. If you run docker compose up -d without pulling, not containers will be upgraded, which is common mistake.
If you add a version tag, and edit the compose file setting a new version, and then perform a docker compose up -d without pulling first, it will detect the missing image and pull it automatically.
That’s great info. I have been using docker but I am new to compose.
The -d is helpfull also. I was using redirection to files and & to put it in the background and was meaning to research if that was the right approach. I see now that the logs are viewed using docker compose logs -f -t
That’s better because my log file was going to get huge eventually.