Not gone. There is a behavior that has been part of OH 2 since the beginning that no one realized would impact the roll out of MQTT2. In short, if you have “Show legacy 1.x bindings” turned off, OH will not show a 1.x binding that also has a 2.x version. What no one realized is that on the upgrade it will also uninstall the 1.x binding and replace it with the 2.x version. This one thing was the source of a huge amount of the problems experienced by most of us.
But if you enable “Show legacy 1.x bindings” you can install and run MQTT 1.x just as you always have.
If you are using the MQTT 2 binding, you should be running the 2.5 M1 version. There were tons of bugs fixed in that short month between 2.4 release and 2.5 M1. Do you have the same problems with 2.5 M1? Have you filed an issue?
Why? I’ve not seen that recommendation. Quite the opposite in fact. And there is a way to duplicate the eventbus using a short rule and an event Channel that subscribes to all the topics below a certain point.
That setting does not remove 1.x bindings (except in the situation described above). Fixing problems like this are almost always solved with Clear the Cache.
The big thing I notice though is that all of the problems sited are with individual bindings. While certain bindings like MQTT should be rock solid and reliable (and the roll out of MQTT 2.x was a huge problem and the 2.4 version was neither rock solid nor reliable at the 2.4 release) there will always be a mix in the quality of individual bindings. Every binding has it’s own set of developers and maintainers. Some have been all but abandoned. Some are new and undergoing active development. So there will be problems like these. It can’t be helped as far as I can tell without limiting the number of bindings to just a dozen or so highly controlled and maintained bindings as opposed to the 330+ we have now.
But even for this problem there have been some talk about ways to address it. I’ve seen ideas floated to allow OH to run multiple versions of bindings which will let us break the binding versions from the OH core version. That way we can find and install any version of a binding through the PaperUI interface. I’ve also seen talk of having a rating and comment system so we can rate and comment about the quality and usability of individual bindings.
No no no no! OH 3 plans to change the format of text based configuration and provide a way to migrate your existing text based configs to the new format. The way that text based configs are loaded will like change too (i.e. you have to initiate the load instead of OH polling a directory).
And the replacement for PaperUI will also have text based find & replace in the text configs through the browser if you don’t want to maintain your configs separately in text files. And OH 3 will have a way to do everything through the UI for those who prefer to, including sitemaps (or whatever sitemaps become).