Set-up steps for migration from openHABian with OH 3.4.3 to v5 in docker in LXC

Setup, Configuration and Use Migration
, , , ,
1

Yes, this is a mount full :slight_smile:

I have spent some time on reading, and came to the conclusion to abandon my rPi setup (that served me well since OH v1), and move to a Proxmox cluster with two minis and a rPi has 3rd quorum member, because OH has become an integral part of the property, (bores, gates, irrigation), and associated buildings (house, shed, garages)… hence, it needs a 100% up-time. The latter is not a problem as we have a whole of property UPS with 75 kWh of capacity, and had no outage for the least 12 years.

I am seeking input from fellow OH users with similar experience in OH in a Proxmox LXC set-up to validate the setting, before I even install OH.

My migration path:

  1. based on forum posts is to install OH 3.4.3 in docker;
  2. then copy my openHABian files where they are supposed to go, and start OH.
  3. Snapshot it,
  4. then clean up items/rules no longer needed,
  5. snapshot,
  6. then install OH v4 and do what ever changes it brings; I think there is a conversion script that needs to be run.
  7. snapshot
  8. install v5; check, and if good
  9. snapshot

The first step is the OH docker-compose file, which I think should look like this:

version: '3'
services:
  openhab:
    image: openhab/openhab:3.4.3
    container_name: openhab
    restart: always
    network_mode: host  # Required for UPnP/SSDP discovery
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro
      - ./openhab_addons:/openhab/addons
      - ./openhab_conf:/openhab/conf
      - ./openhab_userdata:/openhab/userdata
    environment:
      CRYPTO_POLICY: unlimited
      EXTRA_JAVA_OPTS: "-Duser.timezone=Australia/Brisbane"
      OPENHAB_HTTP_PORT: 8080
      OPENHAB_HTTPS_PORT: 8443
      # USER_ID: "1000"      # Uncomment and set if using non-root host user
      # GROUP_ID: "1000"     # Uncomment and set if using non-root host user

This should work to connect via VScode; does UPnP, and allows for exec to at least echo and bin/sh should work. I have no dongle business or other things to connect to OH other than a MQTT broker, for which I thought I use eclipse-mosquitto instead of mosquitto.

Does the above docker-compose look OK for the stated purpose? Thanks.

2

The upgrade tool runs at all upgrades automatically except for manual installations (i.e unzip the archive to install). You’d need to run it manually if you restored a backup from an old version of OH to a newer version, and you’d want to run it prior to station OH after the restore.

Other than that, it looks reasonable.

I’m not sure you need to install 4.3 first though. You can probably go straight to 5 and have less work over all updating your configs. Just make sure to review all the breaking changes for all the releases between 3.4 and 5.1 (if you are willing to wait until the end of the week due the next release).

1 Like
3

:slight_smile: thank you!

So, do I understand this correctly, that I could install v5, copy the 3.4.3 files over, then run a script, and it should work, except for manual tweaks required based on release docs?

4

Yes.

Or you can run 3.4, copy over your files, then upgrade the container and the upgradeTool will be run automaitacally for you.

The nice thing about Docker is to change the version all you have to do is change the one line of your docker-compose file. So that would be the least manual approach.

The steps would be:

  1. copy my openHABian files where they are supposed to go
  2. run OH 3.4.3 in docker using the volumes populates in 1
  3. Snapshot it,
  4. then install OH v5 and do what ever changes it brings
    1. snapshot,

The upgradeTool will run automatically. But note that the number of things the upgrade tool does are relatively minimal, especially if you are running a text file based config. It doesn’t do magic.

The biggest changes you’ll have to deal with will be with units (OH 4 made their use much more explicit but consequently broke some ways people were using them in OH 3, particularly with %), the semantic model (some tags moved around a little and there are way more of them), and the MQTT binding was broken into separate bindings (i.e. if you used Home Assistant MQTT, that’s a separate binding now).

Just be sure to read the release announcements for 4.0, 4.1, 4.2, 4.3, 5.0, and if you wait a few days 5.1. The list of breaking changes do not get relisted for subsequent reelases so you need to look at all the release announcements between your initial version of your final version.

Also note that with docker services do not get installed in the traditional sense. You download an image (e.g docker pull openhab/openhab:latest) and you run one or more containers based off of that image. The containers are to be considered ephemeral and any data that is to be preserved is mounted into the container using volumes (e.g. that ./openhab_conf:/openhab/conf line).

Running docker-compose will do the download of the image and the starting of the container(s) all in one step. So there really is not a time when you can copy over your configs before OH starts in the container for the first time. I just thought of that this morning, and it’s why I swapped the first two steps above. It’s not a big deal if you did start OH before copying over the configs through.You’d just copy over the empty default ones the OH container will populate your mounted volumes with when it sees they are empty.

Also, snapshots are great and simple enough. But all the files that OH ever touches are going to be in those three folders you mount as volumes. So you could just tar/zip up ./openhab and get a complete ad full backup of your OH config.

Also, when an OH container starts up and sees that it’s running a different version of OH from what the configs are for, it will create a backup of everything for you and put it in ./openhab/userdata/backup.

There will also be an upgrade.log file created under ./openhab/userdata/logs which shows all the stuff you currently see now when doing an apt upgrade of OH so you will always know what the container did.

1 Like
5

While I already marked the solution, I’d like to briefly report back that my trial migration went well. That is a direct upgrade of 3.4.3 to 5.1.0 in docker. The upgrade script fixed a few things. You mileage will vary based on what other bindings you have.

Here the docker-compose section relevant for openhab: (change your timezone); first 3.4.3, then 5.1.0 ←- update to whatever as time goes by :slight_smile:

services:
  openhab:
    #image: openhab/openhab:3.4.3
    image: openhab/openhab:5.1.0
    container_name: openhab
    restart: unless-stopped
    ports:
      - "8080:8080"
      - "8443:8443"
      - "5007:5007"  # LSP for VSCode extension
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro
      - ./openhab_addons:/openhab/addons
      - ./openhab_conf:/openhab/conf
      - ./openhab_userdata:/openhab/userdata
    environment:
      CRYPTO_POLICY: unlimited
      EXTRA_JAVA_OPTS: "-Duser.timezone=Australia/Brisbane"
      OPENHAB_HTTP_PORT: 8080
      OPENHAB_HTTPS_PORT: 8443

Here the bash file for my relevant changes: (I named it fix_rules.sh)

#!/bin/bash

# Backup first
echo "Creating backup..."
tar -czf openhab_conf_backup_$(date +%Y%m%d_%H%M%S).tar.gz openhab_conf/

# Fix getZonedDateTime() -> getZonedDateTime(ZoneId.systemDefault())
echo "Replacing getZonedDateTime()..."
grep -rl "\.getZonedDateTime()" openhab_conf/rules/ 2>/dev/null | while read file; do
    sed -i 's/\.getZonedDateTime()/.getZonedDateTime(ZoneId.systemDefault())/g' "$file"
    echo "  Updated: $file"
done

# Fix /etc/openhab paths -> /openhab/conf paths for Docker
echo "Replacing /etc/openhab paths with /openhab/conf..."
grep -rl "/etc/openhab/" openhab_conf/rules/ 2>/dev/null | while read file; do
    sed -i 's|/etc/openhab/|/openhab/conf/|g' "$file"
    echo "  Updated: $file"
done

echo "If something breaks, restore from: openhab_conf_backup_*.tar.gz"

Maybe it helps someone.