Moving an OH 2.5.6 Installation to OH 3.1.0

Setup, Configuration and Use Migration
1

I had a Topic last July, how to migrate 2.5.6 to 3.x.x in Windows 10. I have gotten the recomendation to install new and copy the userdata to 3.x.x

I have bought a 2nd small windows server and installed 3.0 and moved the conf files and added all userdata files from 2.5.6, including the jasonDB.

Status:
I had all Thing defined via the Paper UI - they seam to be lost.
Item same thing. Only the ones I had defined in the .items file are there from conf
Rules are there from .rules file from conf
The sitemap seams also to be lost, even if it was in conf
(ther is more, but let us start with Things, Cannels and the sitemap)

Any Idea how I can avoid to start from skratch?

Thanks for any help

2

I don’t think that’s correct. There are lots of things in userdata that needs to be fixed to work in OH 3. If you just copy them over there is no chance to fix them. I believe the advice is to install 2.5, copy your 2.5 config, then upgrade that to 3. But that’s on Linux. I don’t know about Windows.

Not surprising since one of the thing that needs to be fixed is the names of the Things. It’s a simple find and replace. Any reference to org.eclipse.smarthome needs to be replaced with org.openhab.

Same problem.

We’d need to see error messages to find out what’s going on with that.

3

Many Thanks. I have to investigate further.

To your statement “I believe the advice is to install 2.5, copy your 2.5 config, then upgrade that to 3.”
Not sure if I have got it right: I hope upgrade is the change of the name the org.eclipse.smarthome, right?

So I have edited the filenames in jasonDB and in the files also the class entry, everything that had org.eclipse.smarthome to org.openhab.

Still no of my OH 2.5.6 Things visible in the WebInterface, but the things are in the file “org.openhab.core.thing.Thing” like the one below. If I enter a new Thing (astro:sun) this is visible and appears also in the file. Have the old ones a syntax problem? No clue - blind spot.

I have listed one:

“knx:device:c0f9bee7”: {
“class”: “org.openhab.core.thing.internal.ThingImpl”,
“value”: {
“label”: “Bad_Spiegel”,
“bridgeUID”: {
“segments”: [
“knx”,
“ip”,
“dbf80abc”
]
},
“channels”: [
{
“acceptedItemType”: “Switch”,
“kind”: “STATE”,
“uid”: {
“segments”: [
“knx”,
“device”,
“c0f9bee7”,
“Bad_Spiegel”
]
},
“channelTypeUID”: {
“segments”: [
“knx”,
“switch”
]
},
“label”: “Bad Spiegel”,
“configuration”: {
“properties”: {
“ga”: “1/0/0”
}
},
“properties”: {},
“defaultTags”: []
}
],
“configuration”: {
“properties”: {
“pingInterval”: 600,
“address”: “1.0.17”,
“readInterval”: 0,
“fetch”: true
}
},
“properties”: {
“firmwareversion”: “Unidirectional devices”,
“firmwaretype”: “BCU 1, BCU 2, BIM M113”,
“firmwaresubversion”: “Property based device management”
},
“uid”: {
“segments”: [
“knx”,
“device”,
“c0f9bee7”
]
},
“thingTypeUID”: {
“segments”: [
“knx”,
“device”
]
},
“location”: “O_Eltern”
}
},

4

On Linux one installs OH. That installation process also can upgrade and that does all the changes necessary. On Windows there is no installation. You just unzip the files. So there is no process that runs to do the upgrade changes for you.

If you’ve just copied your userdata folder over then you likely have a number of other changes to make inside userdata/etc too in order to upgrade. Beyond that I’ve no idea what else needs to be changed. I don’t think there has been a lot written on upgrading on Windows and I don’t even possess a Windows machine to look at.

5

Out of curiousity, why Windows? If you’re using a server just for openHAB, I would think this it’s significantly more expensive than a Raspberry Pi.

I have nothing against Windows, which I use daily, but I’d only put OH on Windows if I had an old PC to use. And even then, I’d still prefer an RPi since it consumes less energy and doesn’t need a fan.

6

The zip file contains files update.lst, update.ps1, update.bat. As far as I understand these files describe the steps that are being done during upgrade from 2.X to 2.Y to 3.Z.
Btw. same/similar scripts are executed during upgrade through .deb files.

1 Like
7

Easy answer: All Automation of this House is on this server. So is the program ETS to edit KNX.
ETS runs only unter Windows and not on a Pi. But anyhow, moving to a Pi does not simplify a migration: In that case from Windows 2.5.6 to e.g. Openhabian.

1 Like
8

I had a topic in June on this: Trouble updating OH2 in windows
I struggled with the Update tool. Either I manage to recover, so that the tools “update” work or I manage to edit the Files in a way that they work. If you would be so kind and have a look the the earlier topic. Maybe you see a way there or I made a mistake. To be clear: I used the Update.bat from 2.5.6 then and not the one from 3.x.x. to migrate to OH V3.

9

There is an update tool in Windows. I started with this (see topic Trouble updating OH2 in windows) before I ended (hopefully not the end) here.

10

I defined two KNX objects in the empty 3.1.0 installation and compared the KNX device Thing to the 2.5.6 version. In bold what is new: The only thing I cannot recover from the 1.5.6 version is this entry: “88fb6ef769”, from the channel. So it probably can be left out and be added later via the interactive tool…

“knx:device:1e7e51f6bf:88fb6ef769”: {
“class”: “org.openhab.core.thing.internal.ThingImpl”,
“value”: {
“label”: “DALI Gateway 1.0.6”,
“bridgeUID”: {
“segments”: [
“knx”,
“ip”,
“1e7e51f6bf”
],
"uid": "knx:ip:1e7e51f6bf"
},
“channels”: [
{
“acceptedItemType”: “Switch”,
“kind”: “STATE”,
“uid”: {
“segments”: [
“knx”,
“device”,
“1e7e51f6bf”,
"88fb6ef769",
“FL_Buero”
],
"uid": "knx:device:1e7e51f6bf:88fb6ef769:FL_Buero"
},
“channelTypeUID”: {
“segments”: [
“knx”,
“switch”
],
"uid": "knx:switch"
},
“label”: “Büro Wand”,
"description": “”,
“configuration”: {
“properties”: {
“ga”: “1/6/14”
}
},
“properties”: {},
“defaultTags”: [],
"autoUpdatePolicy": "DEFAULT"
}
],
“configuration”: {
“properties”: {
“pingInterval”: 600,
“address”: “1.0.6”,
“readInterval”: 0,
“fetch”: true
}
},
“properties”: {
“manfacturerfirmwarerevision”: “10”,
“firmwareversion”: “BCU 1, BCU 2, BIM M113”,
“manfacturername”: “ABB”,
“firmwaretype”: “BIM M112”,
“firmwaresubversion”: “Unidirectional devices”,
“manfacturerserialnumber”: “0002a56da050”
},
“uid”: {
“segments”: [
“knx”,
“device”,
“1e7e51f6bf”,
"88fb6ef769"
],
"uid": "knx:device:1e7e51f6bf:88fb6ef769"
},
“thingTypeUID”: {
“segments”: [
“knx”,
“device”
],
"uid": "knx:device"
},
“location”: “EG_Keller”
}

11

Dear all
Making progress:
Items Json file edited and they are in OH 3.1.0 recovered
Sitemaps recovered
No errors in rules

Things did not move. I guess I didn’t manage to pick the right changes when I edited the file. I defined the physical layer “Things” new as I did it in a one by one relation to Items when I started in Release 1. Now they reflect the KNX physical actors. Took me about 8 hours of work to link 22 Things with 112 items.

I tested my Sitemap in the Basic UI by walking with my iPhone and had to adapt a few rules. Miner issues.

Only thing that is missing is the enabling of the OH cloud service to access per iPhone remotely.