I’ve been putting off an upgrade to 4.x so long that 5.0 is out; I’m ready to pull the trigger in the next few weeks. Can I go straight from 3.4.5 to 5.0, or must I first upgrade to 4.3 and then to 5? Should I wait for 5.1? As you can tell, I’m not usually quick to jump on upgrades (have been on board since 1.something, so I’ve done a few and most have involved some level of cleanup). Appreciate any guidance.
I did a test migration to 4.1 a while back – nothing terrible happened, but it was a limited test since I was on a separate machine and did not have my Insteon or ZWave devices available.
The number of breaking changes between 3.4 and 4.3 is much greater than the number of breaking changes between 4.3 and 5.0.
Theoretically you should be able to upgrade straight to 5. But be aware that OH 5 required Java 21 and there are no official releases of Java 21 built for 32-bit ARM. If you are running on an RPi, moving to OH 5 might require changing the operating system also.
If you do jump straight to 5.0, make sure to review the announcement thread for each version of OH between 3.4 and 5.0 for all the breaking changes you may need to deal with.
I can only recommend considering a docker image installation. I have been updating OpenHAB since 3.4 using docker and never had an issue. You create volumes (I use external ones, so I have access to them through my file system) and keep them, i.e. OPENHAB_CONF and OPENHAB_UDERDATA and whenever there is a new version, you pull it in docker. Delete the old containers and instantiate the new images - DONE. No data migration necessary, add-ons are auto-installer. Only community add-ons must be manually re-installed.
Thanks rich, but can I access them through the host system? My installation (docker desktop) let’s me view log files and develop scripts using MS Visual Studio code directly on the sources.
Yes, of course. They are just files. You’ll need permission to access them, but they are not encrypted or bundled in an archive or anything like that. They are just folders, same as host volumes you would mount.
For example, here’s my nextcloud AOI volume:
root@nextcloud:/var/lib/docker/volumes# ls -l nextcloud_aio_nextcloud/_data
total 1236
drwxr-xr-x 42 www-data www-data 4096 Oct 13 18:30 3rdparty
-rw-r--r-- 1 www-data www-data 26350 Oct 13 18:30 AUTHORS
-rw-r--r-- 1 www-data www-data 34520 Oct 13 18:30 COPYING
drwxr-xr-x 2 www-data www-data 4096 Oct 13 18:30 LICENSES
-rw-r--r-- 1 www-data www-data 44247 Oct 13 18:30 REUSE.toml
drwxr-xr-x 56 www-data www-data 4096 Oct 13 18:30 apps
-rw-r--r-- 1 www-data www-data 2395 Oct 13 18:30 composer.json
-rw-r--r-- 1 www-data www-data 3400 Oct 13 18:30 composer.lock
drwxr-xr-x 2 www-data www-data 4096 Oct 23 09:01 config
-rw-r--r-- 1 www-data www-data 3810 Oct 13 18:30 console.php
drwxr-xr-x 24 www-data www-data 4096 Oct 13 18:30 core
-rw-r--r-- 1 www-data www-data 8188 Oct 13 18:30 cron.php
drwxr-xr-x 12 www-data www-data 4096 Oct 13 19:32 custom_apps
drwxr-xr-x 2 www-data www-data 4096 Oct 13 18:32 data
drwxr-xr-x 2 www-data www-data 32768 Oct 13 18:30 dist
-rw-r--r-- 1 www-data www-data 331 Oct 13 18:30 index.html
-rw-r--r-- 1 www-data www-data 3485 Oct 13 18:30 index.php
drwxr-xr-x 7 www-data www-data 4096 Oct 13 18:30 lib
-rwxr-xr-x 1 www-data www-data 596 Oct 13 18:30 occ
drwxr-xr-x 2 www-data www-data 4096 Oct 13 18:30 ocs
drwxr-xr-x 2 www-data www-data 4096 Oct 13 18:30 ocs-provider
-rw-r--r-- 1 www-data www-data 1002223 Oct 13 18:30 package-lock.json
-rw-r--r-- 1 www-data www-data 7336 Oct 13 18:30 package.json
-rw-r--r-- 1 www-data www-data 2825 Oct 13 18:30 public.php
-rw-r--r-- 1 www-data www-data 4521 Oct 13 18:30 remote.php
drwxr-xr-x 4 www-data www-data 4096 Oct 13 18:30 resources
-rw-r--r-- 1 www-data www-data 26 Oct 13 18:30 robots.txt
-rw-r--r-- 1 www-data www-data 1361 Oct 13 18:30 status.php
drwxr-xr-x 3 www-data www-data 4096 Oct 13 18:30 themes
drwxr-xr-x 2 www-data www-data 4096 Oct 13 18:30 updater
-rw-r--r-- 1 www-data www-data 383 Oct 13 18:31 version.php
If I were to do this frequently, I’d probably add group rw permissions to the volumes folder so I don’t have to be root to access them. I usually use a host volume. But I wanted to make sure no one sees the thread and things one cannot access the files from a Docker volume except through the container.
I don’t know where Windows Docker Desktop puts volumes, but I bet it works pretty much the same. Maybe somewhere in AppData.
I did a dry run upgrade to 4.1 when it was current – from a fresh OS install up to OH. It went pretty smoothly, although since I shut it down and waited for a better time to actually go live. That came back to bit me recently when we had a power outage and our standby generator also failed. First the first time in fieve years, all my IT gear started cold at the same time …. and OH was doing unpredictable things. After a few days, I realized the OH 4 system had started and connected to my MQ broker and myopenhab with the same credentials as my 3.4 system, blocking them from being accesed. Enough was working that I was chasing all sorts of red herrings. Taking the OH4 service down (and disabling it this time!) resolved everything cleanly.
I’m an avid Docker user, but hadn’t been using it on my rPi dedicated to OH. I will do so on this next go around. I have been running a 5.0 instance in Docker to proxy a few ESPhome devices – set up before I found the esphome binding backported to 3.4. I’ll probably move the OH volumes to my NAS as well, although I got 5 trouble free years out of the SD card from the 3.4 instance and am starting with a new one for the rebuild.
Just to close the loop, I successfully updated to 4.3.8 yesterday on a new Raspbian OS image using Docker. I also moved my openhab/* folders to my NAS. Only upgrade hitch was the version file required to trigger the upgrade was not included in the backup I made from the old system. After that, the only issues I had were self inflicted (a virtual switch that requires resetting after restart) and two Insteon devices that won’t come online. I’ll post a separate thread for that.
