Migration... fast start help needed after I red the Docu

[azakiller_aza]

I am stuck on OH2.4 and decided now to move on with OH3.4.4 (while I already ask myself if I should have gone to v4)

First I started to try-out how OH3.4.4 works and I am now able to do basically all to recreate my setup. But… as I have so many things, I am at the point where I want to serialize my work.
=> So I red below tips-and-tricks, which I find very good.

OH 3 Tips and Tricks

EDIT: Added more content to the editing the JSONDB section EDIT: Added the “Don’t Wait, Try it Out” section EDIT: Added autoupdate and persistence sections This is going to be a relatively sparse set of notes, tips and tricks, and other advice for setting up openHAB 3 through the UI. It will eventually be turned into a full tutorial and perhaps added as an addendum to the Getting Started Tutorial. But I don’t want to wait before getting some of these out in the open. It’s mostly just notes ri…

Here it says…

1. Create an exemplar using the UI
2. Open the API Explorer from the Developer Tools
3. Query for your exemplar and copy the JSON
4. Navigate to the “create” end point and paste in the JSON
5. Edit the JSON for your new instance
6. Click submit to create the new instance
7. Repeat steps 5 and 6 for all the other similar stuff.

Pt3, my template thing looks like this (and it works):

{
“channels”: [
{
“linkedItems”: [
“EG_WZ_Bar_Licht_Bar_Licht”
],
“uid”: “mqtt:topic:def72de12d:y01_eg_bar_licht:y_eg_bar_licht”,
“id”: “y_eg_bar_licht”,
“channelTypeUID”: “mqtt:switch”,
“itemType”: “Switch”,
“kind”: “STATE”,
“label”: “Bar Licht”,
“description”: “”,
“defaultTags”: ,
“properties”: {},
“configuration”: {
“commandTopic”: “cmnd/y_eg_bar_licht/POWER”,
“stateTopic”: “stat/y_eg_bar_licht/POWER”,
“off”: “off”,
“on”: “on”
}
},
{
“linkedItems”: [
“EG_WZ_Bar_Licht_y01_eg_bar_licht_ip”
],
“uid”: “mqtt:topic:def72de12d:y01_eg_bar_licht:y01_eg_bar_licht_ip”,
“id”: “y01_eg_bar_licht_ip”,
“channelTypeUID”: “mqtt:string”,
“itemType”: “String”,
“kind”: “STATE”,
“label”: “y01_eg_bar_licht_ip”,
“defaultTags”: ,
“properties”: {},
“configuration”: {
“retained”: true,
“qos”: 1,
“stateTopic”: “stat/y_eg_bar_licht/STATUS5”,
“transformationPattern”: “JSONPATH:$.StatusNET.IPAddress”
}
},
{
“linkedItems”: [
“EG_WZ_Bar_Licht_y01_eg_bar_licht_temp”
],
“uid”: “mqtt:topic:def72de12d:y01_eg_bar_licht:y01_eg_bar_licht_temp”,
“id”: “y01_eg_bar_licht_temp”,
“channelTypeUID”: “mqtt:number”,
“itemType”: “Number”,
“kind”: “STATE”,
“label”: “y01_eg_bar_licht_temp”,
“defaultTags”: ,
“properties”: {},
“configuration”: {
“stateTopic”: “stat/y_eg_bar_licht/STATUS10”,
“transformationPattern”: “JSONPATH:$.StatusSNS.ANALOG.Temperature”
}
}
],
“statusInfo”: {
“status”: “ONLINE”,
“statusDetail”: “NONE”
},
“editable”: true,
“label”: “EG_WZ_Bar_Licht”,
“bridgeUID”: “mqtt:broker:def72de12d”,
“configuration”: {},
“properties”: {},
“UID”: “mqtt:topic:def72de12d:y01_eg_bar_licht”,
“thingTypeUID”: “mqtt:topic”,
“location”: “WZ Bar Wandschalter”
}

Pt4 4. (Navigate to the “create” end point)… I assume this is “POST / THINGS”
=> My questions are
Q1: how I create the UID? Can I create one… or will the system do that? I mean this part in bold… “uid”: “mqtt:topic:def72de12d:y01_eg_bar_licht:y_eg_bar_licht”
Q2: Is it possible to use variables to replace reoccuring text like the MQTT-Topic?

I want to avoid that I break my current setup…

[azakiller_aza]

@azakiller_aza

def72de12d

While I understood now that the bold-part of question one represents the MQTT-UID… I start to have doubt that I really extracted the THING itself… it looks more like the CODE-PART/Channels of the thing.
=> how I extract the THING-TEMPLATE in the api-explorer? Is it not under

[azakiller_aza]

I seem to have clearly not extracted the full thing… because it must look like this:

It seems to me that I do something wrong in the api-explorer and it only shows me the channel part but not the Thing - Config.
=> anyone who can give me a hint, how I extract a full-thing-config from Api-Explorer, so that I can create 90 similar ones based on them? I want to avoid that I have to do the manual Thing creation by UI one by one.

Thanks

[rlkoshak (Rich Koshak)]

@azakiller_aza

I am stuck on OH2.4 and decided now to move on with OH3.4.4

That’s a huge jump. Take it slowly, study the Getting Started Tutorial, and don’t try to do too much all at once.

@azakiller_aza

Pt3, my template thing looks like this

You’ve used quotes. Please use code fences.

```
code goes here
```

That will preserve the spacing and make it much easier to read code, logs, etc.

@azakiller_aza

Q1: how I create the UID? Can I create one… or will the system do that? I mean this part in bold… “uid”: “mqtt:topic:def72de12d:y01_eg_bar_licht:y_eg_bar_licht”

It depends on the binding and the type of the Item. In that particular case, the random part comes from the MQTT Broker Thing. That’s what tells OH which Broker the Thing belongs to.

I recommend always replacing the randomly generated UID for all Things, Items, Rules, and everywhere else they are created with something human readable and meaningful. For example, the ID for my MQTT things looks like mqtt:topic:mosquitto:garage_sensor_reporter and my MQTT Broker Thing’s ID is mqtt:broker:mosquitto.

@azakiller_aza

Q2: Is it possible to use variables to replace reoccuring text like the MQTT-Topic?

No.

@azakiller_aza

I start to have doubt that I really extracted the THING itself… it looks more like the CODE-PART/Channels of the thing.

The bulk of any MQTT Thing is going to be channel configuration stuff. Your JSON posted above looks like a full MQTT Thing’s JSON.

@azakiller_aza

I seem to have clearly not extracted the full thing… because it must look like this:

“editable”: true,
“label”: “EG_WZ_Bar_Licht”,
“bridgeUID”: “mqtt:broker:def72de12d”,
“configuration”: {},
“properties”: {},
“UID”: “mqtt:topic:def72de12d:y01_eg_bar_licht”,
“thingTypeUID”: “mqtt:topic”,
“location”: “WZ Bar Wandschalter”

Look at the bottom of the JSON you’ve pulled.

The order doesn’t matter.

[azakiller_aza]

@azakiller_aza

eem to have clearly not extracted the full thing… because it must look like this:

Copy of Things
Ahhh many thanks… so it a full Thing-Json I pulled but it is not in the order :slight_smile. Now that you tell it I see it.
=> I will try now to create a “template-Thing” and then create them as you proposed in your howto by copying them.

Migration
yes thanks for the tipp to take-it-easy. I have my old installation running and build up the new one in parallel. I saw already from your howto’s that the fast way means then to do it multiple times.
=> I will go from zero and the good thing with mqtt and homematic is that you can link those things to two running OH on the same time.

Many thanks btw for the great docs you created.

[rlkoshak (Rich Koshak)]

@azakiller_aza

I will go from zero and the good thing with mqtt and homematic is that you can link those things to two running OH on the same time.

Another good thing is you can use the Remote openHAB add-on to link the two OH instances so they work together. For tricky bindings that hav hardware dependencies you can migrate all the Items and Rules and UI stuff first and leave the hardware and Things on the old instance, or you can move the hardware and Things first and leave the Items and Rules and stuff on the old OH instance and move them over gradually.

Given that OH 4.0 release is a week or two away, you might do well to migrate straight to 4. It will not be significantly more challenging nor all that different to jump straight to 4 and in the end it will probably be less work than to upgrade to 3.4 and then upgrade to 4.

[azakiller_aza]

Many thanks

I was not aware that we are so near to the realease ov v4
=> In that case I rather go directly to v4 and try that Remote openHAB add-on as well.

Good thing with vmware on synology is that I can try to migrate directly to v4 by doing a snapshot