I have installed new 4.2 on RPI 5 and added Remote openHAB Binding, question is how to repoint all items to OH 4.2 MQTT when OH 2.5 will be removed ? As example 1 item which I get values from MQTT running on OH 2.5:
It largely depends on what you want out of this upgrade. OH 4 provide a whole lot more than OH 2.5 and if you want to take advantage of the new stuff you might go down one path but if you just want what you have working now working in OH 4 you might go down a different path.
If you want to try what’s new I would follow this overall approach:
- From Settings → Model, create some Locations to represent your house.
- Pick a binding to migrate.
- Install that binding on OH 4
- Start to discover or creating the Things for that binding
- Once the Thing(s) are create, at the bottom of the Channels there’s an option to “Add Equipment to Model”. This will let you create the all the Items assocaited with that device all in one go. All the important stuff will get set including the
unit. - Migrate over the relevant rules that operate on those Items. If you have rules that need Items you don’t have yet, make sure you mirror those using the remote openHAB Thing. Consider if you want to move to one of the new languages for rules. Blockly is an excellent choice if you are not great at programming. You don’t have to migrate the rules now but it’s a good opportunity to experiment and see what works best for you.
This approach is going to be the least amount of work overall and it gets you into some of the new stuff in OH 4 like the semantic model and such.
If you just want to duplicate exactly what you have on 2.5 I’d use this overall approach:
- Create all the Items from the Remote openHAB Thing.
- Move over the rules, adjusting for the many many breaking changes.
- Pick a binding and install it.
- Discover and create the Things for that binding.
- Assuming it’s a .items file based Items which was pretty standard for OH 2.5, edit the file and replace the channelid with the ID of the newly created/discovered Channels. If these are managed Items, you can click on the Channel → Add Link → Select the Item and save. Then navigate to Settings → Items → The Item → and remove the link to the Remote openHAB Channel.
- Your sitemap should mostly just work as is, though there are a whole lot of new features available to you now.
Thanks for suggested options !
I am in the similar boat. When I migrated from OH1 to v2 the rules all broke down so I moved the logic/device binding in NodeRed and do not use bindings to things, I only need mqtt.
Basically I use HABPanel only and all items are defined in ‘items’ file. Now I jump from v2 (habian) to 4.3 (in Docker) and do not know how to populate the Items with values
I see them listed, I have a broker definition and it works fine (posting LWT and Birt messages properly)
UID: mqtt:broker:ohabssl
label: MQTT Broker
thingTypeUID: mqtt:broker
configuration:
publickeypin: false
lwtQos: 0
What is the new syntax for this part from the old items file?
... { mqtt="<[ohabssl:hab/val/kujna/light/led:state:REGEX((.*))], >[ohabssl:hab/set/kujna/light/led:command:ON:1], >[ohabssl:hab/set/kujna/light/led:command:OFF:0]" }
I see this as example but it is not a full example
Switch Kitchen_Light "Kitchen Light" {channel="mqtt:topic:..." }
I have 700+ items
You’d do it the same as you would in OH 2.5. Either write a rule to populate the state if the items you want initialized or issue updates to the items using the REST API or the karaf console.
That’s the OH 1.x binding syntax. OH 1.x bindings haven’t been supported since OH 3.0.
Nothing like that exists any more. You must create a Generic MQTT Thing and set up a Channel with a subscription topic and command topic and any transformations required.
Then you link the Channel to the Item. That’s what you show above, a link. Only links are supported in OH 3.0+.
Please do not neglect reading the Getting Started tutorial. The users that have the hardest time are old OH 2 users who skip it. They have even a harder time than brand new users. MQTT is one of the examples in getting started.
The last section of the tutorial includes some tips and techniques for creating a lot of Things when that is necessary.
Unfortunately there are no shortcuts here. OH’s architecture changes in OH 2.0 and complete the transition to that new architecture in OH 3.0. The OH 1.x bindings do not fit that new architecture.
However, you didn’t have to move everything all at once. If you can run your old insurance and the new insurance at the same time, you can use the remote openHAB binding to link the two so you can gradually move your config over time instead of all at once.
Wow it feels like every major version is a new software. I liked the low level / text file / hack3r way of managing OH. This is now click-click
I will run both OHs in parallel for now and see how things will go. My only motive for now is the broken Google Home integration on v2.I will add only these as Generic MQTT things
As I did not find this in the guide… can I add / edit my OH setup from text files or now it is all in a DB? Including things etc…
The level of abstraction that is introduced is yea…a deal breaker
Yes, you can still use text files except for MainUI widgets and rule templates. Evening is in the docs for syntax and such.
Heck, you can even write rules in jRuby and JS Scripting to create all the Things, Items, and such in code if that floats your boat.
Getting Started isn’t the only way to do everything, but it’s the main way to learn what can be done and how it all works together.
It may be a deal breaker for you and that’s fine. But it’s the only reason features like automatic discovery of Things, auto generation of UIs, Blockly for rules, etc are possible.
But you don’t have to use the new stuff, except for Things. And you didn’t have to use the managed configs (I.e through MainUI or the rest api). Though given it’s been just short of four years since the drop of support for 1.x bindings, it’s hard to call the requirement to use Things new.