There’s no easy means. When I converted over to MQTT 2 I created one Generic Thing in PaperUI, stopped OH, then copied/pasted/edited that entry in JSONDB to create all the other MQTT Things/Channels I needed. It worked pretty well.
This has indeed been argued over quite a bit. Probably about a thousand posts have been made over it.
I’ll provide a bit of a tl;dr here for why it makes a difference. I am not reopening the discussion about how/whether to change this in openHAB 3. I’m just explaining how it works now and why.
It all started with openHAB 1.x. In this version of openHAB everything had to be configured with text files. The text config files are all a custom syntax based on Xtext (including the Rules DSL which is sort of a sibling of Xbase). So all the text config files you see are essentially hold overs from openHAB 1.x. Because everything was in text files, and one of the problems with these file formats is there is no file writer, automatic discovery was impossible. Every Item had to be configured with binding specific information, some of which had to come from watching log files for magic numbers and api keys and the like.
openHAB 2.0 was a near complete rewrite of the openHAB core. It introduced a pretty extensive REST API, moved to Karaf, internal storage for configuration (JSONDB), web based UIs for configuration, and the concepts of Things, Channels, and Links. Most of these changes including the JSONDB and new concepts were introduced to allow for automatic discovery of devices. But these changes and the rewrite involved a whole new way for bindings to work meaning that all the old OH 1.x bindings were no longer compatible with OH 2.
To address this problem an OH 1.x compatibility layer was created which is kind of a mini version of the openHAB 1.x core running on top of OH 2. This means that OH 2 has two minds, the old OH 1.x mind and the new OH 2.x mind. When dealing with OH 1.x bindings and addons we are dealing with the OH 1.x mind. Everything else uses the OH 2.x mind. This is why beyond installation, you can’t do anything in PaperUI (REST API) with 1.x bindings.
I’m not sure if the text config parser is part of the compatibility layer (I don’t think it is) but it is a similar hold over from OH 1.x. The loading of configs from the text files is a wholly separate subsystem of OH from the JSONDB. Thus there are two sources of truth in OH 2 that both feed into the internal memory of a running OH instance. It’s currently configured such that the text configs override JSONDB but there are still conflicts that can occur. But the main point is all the stuff you do in PaperUI is stored, loaded, and processed completely separately from anything done in text based configs. This is why it makes a difference.
Also, in addition to the fact that there is no writer for the text based config files, apparently the Xtext libraries that are used to parse them tend to be slow, especially for parsing Rules on an RPi. But reading and parsing JSON is super fast. So the more that is in JSONDB the faster loading and restarting.
But, it shouldn’t make a difference at runtime as Elias mentions so I don’t know specifically what that references. But the MQTT 2.x binding is a complete rewrite from scratch of the MQTT 1.x binding so there might be some bug or other in the 1.x binding that doesn’t exist in the 2.x binding.
For completeness, just to reiterate the controversies involved with this stuff. (I do not list these for discussion here, just for information. Everything that can be said has already been said).
- OH 3 may drop support for 1.x addons.
- OH 3 will completely replace PaperUI with a new unified web based UI. Some of the studies/prototypes for this UI have included the ability to copy/paste/edit Things and Items in the browser.
- OH 3 will address the problem caused by there being two sources of truth in the config files.
- I would not be surprised if OH 3 moves to some more standard format for text based configuration. YAML has been discussed. Perhaps it would be written so multiple formats can be supported. But this means there will be support for text based configs. Importantly, there will be a migration path between text based configs and REST API created configs. But likely the text based configs will be imported and loaded into the internal JSONDB (or what ever may replace that) and the internal DB will become the single source of truth
- Rules DSL will be replaced with the Next Gen Rules Engine (i.e. JSR223/PaperUI Experimental Rules) as the default. No one is talking about dropping Rules DSL completely, but it will no longer be the default.
All of the above have been proposed and discussed at length largely to address the problems with the current text configs. But ultimately what happens and what doesn’t will depend on what the developers work on and manage to complete. An important feature that I push at all times is that there is a way to transition into all of these changes.