Upgrade from 2.5 to 3.0, using MQTT 1.x binding

Setup, Configuration and Use Migration
1

I am planning to upgrade to 3.0. However, most of my system is MQTT based (a huge number of items, all configured in .item files…), using the old 1.x binding, in which I use two different binding “things” one that will retain the messages and the other that will not retain the messages.

What is the best strategy to upgrade? Define all MQTT items in the new UI? or can I keep them in the text files (default.items etc.)?
How shall I deal with my need of having two MQTT Broker things, one with retain and one without retain?

2

You can keep them in files (after upgrading your syntax to the v2/v3), but the UI is very friendly. Your choice.

Certainly unusual! So are you currently publishing the same messages to two different brokers, where one retains and the other doesn’t?

1 Like
3

I have moved all my thing definitions (including KNX and MQTT) to UI.
I started that with 2.5 and finished it now for openHAB 3.
And looking back i would say that was the best decision and i should have moved completely way earlier.

But you have to test how that fits in your two broker approach as @hafniumzinc already mentioned.
Usually i would add one Bridge for each broker and then use several things and connect them to the needed brige.
Difficult to say something detailled without knowing the environment.

About Items:
I am still using item files partly. (I am not ready to switch to UI completely. :smiley:)
But this is now problem, when you add the things with proper naming uids.
You can then easily assign the channels to items in files.

4

I would also recommend using MAIN UI to configure.

you can set up the retain per channel of a thing.

image
image790×887 29.7 KB

After you do a couple of channels using this form look at the code tab and you can copy paste similar items. However you can’t change the channel channelTypeUID: just delete the wrong one and create a new one.

So this is the way you can do it in a thing file OH2 or OH3

Bridge mqtt:broker:myMQTTBroker [ host ="192.168.1.148", secure =false, clientID ="myMQTTClient" ]
{
    Thing topic Kettle "Kettle in Kitchen" @ "Kitchen" [ availabilityTopic ="tele/kettle/LWT", payloadAvailable ="Online", payloadNotAvailable ="Offline"] {
    Channels:
        Type switch : PowerSwitch  [ stateTopic ="stat/kettle/POWER", commandTopic ="cmnd/kettle/POWER", on="ON", off="OFF"]
        Type string : WarmMode [ commandTopic ="cmnd/kettle/TuyaSend4"]
        Type number : temperature "Temperature [%.0f °C]" [ stateTopic ="tele/kettle/TUYARECEIVED", transformationPattern ="REGEX:(.*DpId\":5.*)∩JSONPATH:$.TuyaReceived.DpIdData∩JS:HEXtoDEC.js"  ]
      }
}

Note the transformationPattern above is different in example because I doing it a different way below and no warm mode.

This is from the Code tab section of OH3 Geriatric Thing

UID: mqtt:topic:myMQTTBroker:Kettle
label: Kettle
thingTypeUID: mqtt:topic
configuration:
  payloadNotAvailable: Offline
  availabilityTopic: tele/Kettle/LWT
  payloadAvailable: Online
bridgeUID: mqtt:broker:myMQTTBroker
location: Kitchen
channels:
  - id: Switch
    channelTypeUID: mqtt:switch
    label: Boil the Kettle
    description: ""
    configuration:
      commandTopic: cmnd/Kettle/POWER
      stateTopic: stat/Kettle/POWER
      off: OFF
      on: ON
  - id: Temperature
    channelTypeUID: mqtt:number
    label: Kettle Temperature
    description: ""
    configuration:
      stateTopic: stat/Kettle/TEMPERATURE
      unit: °C

This happens when you get something wrong.

Sorry @Confectrician you awesome VSCode Extention is not being used as much by me to do things and items anymore (just test things and items) However rules and transformations still 100% VSC

Now after setting up the model with all the locations of your house you can create equipment from thing. This will create all the Items you want. Use the weather binding to do it and it even has an advanced mode.

It checks to make sure the item name is unique however this is one way once its created you can’t edit it like this.

So my recommendation is to Try it with another instance of openHAB you can use the same MQTT Broker and control it exactly the same. Then what I am doing is moving it a section at a time.

Don’t forget do a backup of your current system.

5

So enough work for me left. :stuck_out_tongue:
I am doing all of my things too via ui as written above, since it prevents me from looking for errors for hours. The useable and more comfortable thing configuration in openHAB 3 is a real gamechanger for me.

1 Like
6

Thanks for the input, the fact that I can define retain or not to retain per channel solves my problem :slight_smile:
I have made a seperate OH3 installation for testing. There is one thing that I do not understand - where do I add the " <light> [ “Lighting” ] " such that I can get Google and Alexa to discover the item?
Switch SonoffDoorLight “Utomhusbelydning Dörr” <light> [ “Lighting” ] { mqtt=">[broker_no_Retain:cmnd/sonoffMiniUtomhus/POWER:command:*:default], <[broker_no_Retain:stat/sonoffMiniUtomhus/POWER:state:default]" }

7

Its easy easy easy now. After creating item add meta data and just click on the ones you want.

1 Like
8

Have I understood it correctly that I can not include an expire conditions to the items that I create in the UI?

9

No. You can add expire conditions, and it’s now built in to openHAB: no binding needed. Just click Add Metadata when you’re in your Item, and choose Expire.

1 Like