Migration from openhab 2.5 to openhab 3 on docker

Hi,

as I couldn’t find information about the migration for openhab 3 I am opening that ticket.
My current installation is on docker with the image for build 2.5.10 and I’m planning to upgrade to openhab 3 now.

Is it possible (and advisable) to just pull the new openhab 3 version to do the migration, or should i create a different container and migrate my setup manually?

1 Like

It depends. If you’ve done all your configs in text files I think you can just pull and go. If you’ve done some stuff through the APIs or UIs you might need to change some stuff in JSONDB. Primarily replacing all references to org.eclipse.smarthome with org.openhab

2 Likes

Is there some information on steps to take for migrating from Openhabian to an OH3 docker image?

Yes I have my items, rules and sitemaps all currently in config files.
I’m planning to replace them as far as possible with the new openhab 3 ui standards.

As a second docker container i host a openhab cloud instance for the app (with sitemaps) and push notifications. Will this also work after the upgrade

If you plan on replacing them with OH 3 UI anyway, I’d recommend rebuilding your config rather than copying the files over. Discover your Things and then use the new “Create equipment from Thing channels” to create your Items, for example.

Not really. But the all that’s really required is to copy /etc/openhab2 to a conf folder and /var/lib/openhab2 to a userdata folder and mount those new folders into the container as volumes per the instructions for running OH in Docker. But realize that the Docker instance is just openHAB. No Mosquittio, Frontail, or any of the other stuff that openHABian installs and configures for you.

1 Like

Last time I checked the OH2 to OH3 upgrade in the container worked very well! :slight_smile: You might need to manually remove some OH1 add-ons from the addons.config file if you haven’t removed them before the upgrade. It will log some warnings on startup that OH can’t find those OH1 add-ons.

That should already be done automatically during the upgrade by the big list of upgrade commands.

It’s probably a good idea to first start the container with some empty volumes so the initial data is initialized. Then you can have a look at how it is structured and the file permissions. Once you know what the structure looks like, you can replace the files using the same structure with your openHABian files.

After the files are in place you also have manually update some paths in files to the paths in the container, see:

It would be nice if one day the backup/restore scripts can simplify migrating OH between OS-es and distro’s. :smiley:

1 Like

Went for a fresh installation with rebuilding my config with the new UI. Took me some time but now it’s working fine. Really enjoying all that new nice features :grinning:

1 Like

I have quite some config in OH2, both in textual form and PaperUI. Is it possible to upgrade to OH3 keeping the existing config?
I would then gradually migrate the config to the new system, probably using python for the rules.

Test config should move pretty readily except for anything referencing the old time library.
For Python. HABApp uses Python 3.

1 Like

This means both changing the file names of the json config files, e.g.

userdata/jsondb/org.eclipse.smarthome.core.items.Metadata.json

to

userdata/jsondb/org.openhab.core.items.Metadata.json

and replacing org.eclipse.smarthome by org.openhab in the content of the *.json files (e.g. in the “class” attributes), right?

I assume so. I’m rebuilding from scratch so I don’t know if there is more that needs to be done.

1 Like

I migrated from OH2 to OH3 with Docker. You should save everything beforehand, especially the HABpanel configuration needs to be exported separately. After the migration the majority is working without problems, however you have to throw away your .thing files/config to be able to maintain it via UI. Also the 1.x bindings have to be replaced, incl. the telegram calls. If you use date calculations you have to change many of them, as ORA Java has another concept.