Oh3.4 -> oh4.0.2

Setup, Configuration and Use Migration
1

Hi,
Just wanted to check if my upgrade plan is “optimal”, recommended, etc. or it will not work…
current system: OH3.4 running on raspbian 10 (buster) - so, manually installed.
since i need to jump to 11 (bullseye) for java17 compatibility, I’ve decided it would be best to switch to openhabian and then restore the config.
so the plan would be:

  • openhab-cli console backup
  • manually backup config of mosquitto and zigbee2mqtt services
  • backup entire sdcard with the current working setup
  • burn the latest 4.0.2 openhabian image to the card
  • initial setup
  • openhab-cli console restore (this will work?)
    • most of my things and items are file based, but some of them are UI defined only. what will
      happen to them? can they also be backed up and restore with the CLI commands?
    • do I have to manually install all the bindings and addons that I had, or backup/restore will do it?
  • manually reinstall mosquitto and Z2M services and restore their configs.
  • deal with breaking changes, fix the rules, transformations etc…

any thoughts, comments welcome :slight_smile:

2

Do not restore/backup between different version. That’s not supported.

Backup 3.4 config, install openhabian with oh3.4, restore and then upgrade to oh4.x

3

ah, crap. thanks for the info.
then maybe I should upgrade OH3 to OH4 on the existing system. someone wrote a procedure how to install java 17 on debian buster.
and then take the backup of OH4, burn the latest openhabian to the sd card and restore OH backup…

4

openjdk 17 is not provided/available on Debian Buster.

According to the migration FAQ: openHAB 4 migration FAQ

  • Get a new SD card (preferrably an “Endurance” labelled one) and keep the old one as your fallback
  • Run option 50 to create an OH config backup and copy it to some box of yours
  • Download and flash openHABian 1.8
  • Put the SD in your Windows system and open the first (only) partition. Edit openhabian.conf and set clonebranch=openHAB3. That should result in (latest) OH3 being installed.
  • Also put your backup zip file there, name it initial.zip. That’ll auto-import the config during install.
  • Now put the SD in the Raspi and turn it on. Let openHABian do its install magic.
  • When finally done, login and run openhabian-config menu option 03 to upgrade to OH4
1 Like
5

someone provided instructions how to manually download and install java 17 from zulu on debian buster.
Upgrade OH3 to OH4 - Setup, Configuration and Use / Migration - openHAB Community

i have done it and it works, I am now running OH 4.0.2. on debian buster raspbian.
so now I can fix all the issues, make it stable, and then do openhab-cli backup, and restore that backup on a fresh openhabian machine.

6

But reported to work with some caveats. There is a post I can’t seem to find recently where someone reported success restoring an OH 3 to an OH 4 system. It’s important to manually run the upgradetool in that case.

But it is true in general that approach is not guaranteed to work so is generally unsupported. Not supported does not mean it can’t ever work though. There are just too many variables for us to predict and help if things go wrong.

1 Like
7

I managed to get to a working oh4.0.2 setup on raspbian buster. also kind of unsupported scenario :slight_smile:
Even though everything works I am trying to force myself to a clean migration on to a fresh latest openhabian
this machine is running for 4-5 years and had survived many upgrades since oh2.X, numerous java versions etc…
also zram looks interesting, to prolong the life of the sd card, but I am not sure at what stage of stability it is nowadays…

8

It’s been part of openHABian for years now. I’d say it’s pretty solid.

9

what is the difference between openhab-cli backup and openhab-cli backup --full ?
–full makes a significantly larger file. I just want all my settings, bindings, things, items rules, config etc…
is it better to go with normal command or full?

10

Full includes the cache and tmp folders. Full is rarely necessary unless you are running a long term on an unsupported version of OH and need to be sure to capture the installed add-ons.

11

Thinking about my migration strategy.

Currently running a 3.4.2 package install on RPi4 booting from an SSD. Would prefer to keep it that way and not venture into Openhabian.

Because of the Bullseye/java 17 dependency, can I first build a new Bullseye platform and then install my 3.4.2 system on to it? I’m assuming 3.4.2 is compatible with the newer OS/Java?

Later when 4.0.x becomes more stable I can use the update tool to migrate 3.4.2 to 4.0.x

12

when i upgraded java to 17 and made it system default java (but keep in mind this is on buster, so unsupported scenario), my oh 3.4.4 started crashing with massive java exception errors, so I stopped it and upgraded to 4.0.2 as this was the plan anyway. so, not sure it can run on java 17, i think you will have to install java12…

13

Bullseye yes. Java 17 no. 3.4.2 will not run on Java 17.

Java 11.

14

Ok so first build a Bullseye/Java 11 platform and get 3.4.2 running
When I’m ready to make the migration to 4.0.x, backup the 3.4.2 system and update to Java 17
Then update to 4.0.2 or alternatively run the update scripts.
Is one method preferred over the other?

Then deal with the breaking changes…

15

Assuming you’ve installed using apt, the upgradetool gets run as part of the apt upgrade.

16

thanks for the clarification…as usual very helpful!

17

I’m not sure about 3.4.2 but 3.4.4 works with java-17 fine for me. I’m using it on Fedora-38 server:

# rpm -qa openhab openhab-addons java-17-openjdk-headless
openhab-3.4.4-2.noarch
java-17-openjdk-headless-17.0.7.0.7-5.fc38.x86_64
openhab-addons-3.4.4-2.noarch
18

Then let me state it a different way. OH 3.4 is not supported when running on Java 17 and it is known to not work in some circumstances.

19

The required java version in the pom.xml[1] and the git message says something opposite:

so we can make sure the build keeps working with both Java 11 and Java 17.

$ git branch --all --contains a54ef35adc5dfae1f2c092b5a09df8eb33badfd1 | grep 3.4.x
  remotes/origin/3.4.x

[1] Add Java 17 to GHA CI build matrix by wborn · Pull Request #2817 · openhab/openhab-core · GitHub

20

A build that succeeds does not imply that all known issues with Java 17 have been fixed. :wink: It’s just one of the first steps in supporting a new Java version.

See for instance Add support for running openHAB with Java 17 · Issue #1316 · openhab/openhab-distro · GitHub which was only closed with OH4 because there was still more to fix regarding JavaScript compatibility issues and support.