Migration of text based things and item into UI based in openhab 5

Setup, Configuration and Use Migration
1

Hello,
I have a lot of text based things and items from an old openhab release which I want to get rid of.
Is there a way to migrate them so that I can afterwards maintain them using the UI?
It seems that there’s a way for items, but I didn’t find a way to migrate things.

Is there probably a tutorial which I didn’t find?

2

Bulk import for Things is not implemented.

For bridges you are probably best off recreating those by hand. Just make sure to use the same IDs for the Things as is used in your text files.

For Things that are discoverable, I recommend just letting OH discover them. Set the Thing ID to the same as the IDs of the old text based Things and everything else should work just fine.

For Things that are not discoverable (e.g. HTTP, Exec, Generic MQTT, etc.) what you can do is manually create the Thing (again being careful to use the same ID), click the code tab, select DSL at the bottom and paste your text based config.

Make sure to remove the text based definitions for the Thing(s) you are working on before recreating them in the UI.

This approach lets you move slowly and deliberately, testing everything is working as expected as you go. This is why I recommend it.

But if you just want to do everything all at once and hope nothing breaks you can do the following.

Go to Developer Tools → API Explorer → things → GET all available things. Execute and save the result body in a text file somewhere.

Next remove your .things files.

Go to Developer Tools → API Explorer → things → POST things. Unfortunately you can only post one Thing at a time. So you’ll have to select one Thing’s JSON from the result you got on the previous step and paste it into the body for the POST call, execute making sure you get a 200 return code, and repeat for each remaining Thing.

The order of the JSON is not hierarchical meaning some Things will be created before their bridges. So using this approach you’ll likely not have a fully working config until you are done.

Of course, you can use a hybrid of this approach and the former approach, using the API only to recreate those Things that cannot be automatically discovered instead of pasting the definition into the code tab.

Now that OH has added a file converter to the API (i.e. translating between the internal JSON and the file based YAML and DSL config formats) it should be possible to implement an importer for Things similar to what already exists for Items. You can look to see if an issue is already open to add this (I think there is) but if not create one on the openhab-webui repo so this doesn’t get forgotten.

3

How can I find out if my MODBUS Bridges and/or Things are discoverable?

And why should I use the same ID’s as in the text files? They don’t correspond any more to the naming conventions I defined for myself.

4

For any add-on you can tell by reading the add-on docs. For example, in the Zigbee docs it has a whole section about “Discovery” and it states

The binding will automatically discover the device features and provide channels linked to device functionality that it is able to support.

The modbus binding docs says this:

Device specific modbus bindings can take part in the discovery of things, and detect devices automatically. The discovery is initiated by the tcp and serial bridges when they have enableDiscovery setting enabled.

Note that the main binding does not recognize any devices, so it is pointless to turn this on unless you have a suitable add-on binding installed.

So unless you have another binding that works with the modbus binding that is capable of doing discovery the answer it no.

Because it saves you from having to relink all your Items. If you change the ID, you will have to recreate the links for every Item.

5

My modbus things and items are defined in files. Is it correct, that if I want to create them in the UI, I have to stop openhab, remove the files and start openhab afterwards?
My questions about persistance:

  • Which item data is the key for the persisted item values?
  • Are the persisted values automatically removed if I remove the item file?
  • Is there a way to change the item key in the persited data?
6

No, removing the files will be sufficient. OH will unload and remove any Thing defined in the removed files.

The Item name.

No, persisted data can only be removed manually.

Note, every time you edit a .items file, every Item in that file is removed and recreated anew when the modified file is read by OH. If persistence data was removed when the Item is removed, you’d never be able to edit your .items files.

You can define an alias in the persistence config to map the new name to the original name so you don’t lose any data.

7

When I repace a file based item item_oldName with an UI based item_newName,

Aliases {
    <itemName1> -> <alias1>
    <itemName2> -> <alias2>
    ...
}

is item_oldName the itemName or the alias?

8

newName is the item name, oldName is the alias.

This is more obvious when configured through the UI.