Looks like I’ll be done with OH then.
Didn’t realize that about the MQTT 2 Binding, will definitely throw a spanner in the conversion.
I’m assuming there’s an openHAB-specific reason for that limitation, as I’ve never seen it before in Eclipse’s MQTT server. I couldn’t find the reasoning in the forum discussion either.
It isn’t that the MQTT itself works differently. Its that the MQTT 2 binding is set up and configured in very different ways from the MQTT 1 binding. So the conversion isn’t always as simple as “copy topic from here to there and I’m done.” It still works with Mosquitto just fine, or optionally you can now install an embedded broker as a Misc add-on instead of using Mosquitto, though it you need security or already have Mosquitto set up I’d stick with it.
I found that if you have a lot of similar type Items that use MQTT (e.g. a bunch of Sonoff devices) the following approach works.
create a Generic MQTT Thing to represent one of the devices and add the channels for all the topics you currently pub/sub to. For the command/status topics you need only one Channel.
Open the JSONDB file and manually add the rest of your Things using copy/paste/edit, using the Thing you just created to copy from.
Presto, all your SonOffs now have Things.
Next change the old binding configs to link to the proper channels and you are good to go. So far I’ve only run into one thing that I was doing with MQTT 1 that I can’t do with MQTT 2 but that is because of a bug that David already knows about and there is an issue for it. Others have run into issue with outgoing transforms, particularly JS outgoing transforms. If you rely on those, you will for now need to use a Rule. With the work arounds though, I don’t think there is anything that MQTT 1 can do that MQTT 2 can’t. It’s just setting it up is significantly different.
Others resort to .things files instead of the approach I used.
I’m sorry to see you go but if you are not willing to accept the compromise and no developer is willing to step up to help maintain the compat layer, it’s hard to feel bad about your going. It can’t be helped. It is impossible to meet your demands. OH will be here if you ever change your mind.
This has been resolved in 2.5M1 and outgoing transformations are now possible.
I hope a removal in next iteration means in OH 3 not in OH 2.5 ? That would let users 1 or 2 years to decide if they will do the jump to OH 3 or remain to 2.5 and the time to prepare them.
Until that day, no feature has to be broken in OH 2.5 and we can leave the compatibility layer unchanged even if not maintained.
Removing the compatibility layer today in 2.5 would be a total disaster IMHO for most of the users and really not fear.
The only OH1 binding (except persistence - I don’t know exactly for transform bindings what I am using !) I am using is the Vera binding but the only reason is that I have not yet take the time to move all my Z-wave network.
Quick reply, hoping it’s not going to be too far Off Topic:
Z-Way binding: used to work (for me flawlessly) in OH 2.2.
I’m not as an advanced user as many here, so i don’t know exaclty what changed in the compatibility layer or apis or what in moving to oh2.3, but as a result the “listener mode” in the binding config has been removed (i know there is a thread about it both on the forum and on github somewhere).
Prior to testing the zwave binding by Chris I’ve also tried going zway-embedded mqtt binding- OH2.4, and zway-mosquitto-OH2.4 (the latter with more success), but both of these solutions implied for me a lot of extra work per device/thing/item, some random disconnnects and reconnects from the MQTT broker and less transparency compared to the old zway binding.
All this to say: if there was a way to keep the compatibility to that binding in OH3.0, i’d be really happy, unless i’ll find myself to be as proficient as i am in zway (network reroutings/heals on command, direct associations,timings control, parameters editing, zniffer, achieving consistent status reporting etc) in the z-wave binding, which i’m testing at my parents’ right now( ifeel the db of suupported devices might be becoming better than the z-way one) while at home i’m still stuck on OH2.2 (spare time to work on these things being the limitation here… but also “if it ain’t broke don’t fix it”).
Both the Z-Way binding and ZWave binding are openHAB 2.x bindings and not affected by the removal of the OH 1.x Compatibility Layer.
(There also is a OH 1.x Z-Wave binding, but I don’t think you are referring to that version of Chris’ ZWave binding)
Will the removal of the oh1 compatibility layer affect all bindings, which are marked with version 1.14 in paper ui (binding download section)?
So all of these binding will have to be updatet to a 2.x version or they will be not usable anymore?
Or are there also bindings, which are marked inside paper ui with version 1.14 and will work without the oh1 comp layer?
For example the Waterkotte EcoTouch Binding. It is marked as oh1 1.14 version. But i can configure it inside paper ui.
Yes. There should be no deliberate breaking changes in 2.5. There are breaking changes that occur as bugs get fixed and such, but something like this wouldn’t occur until OH 3.
Indeed, removal of the compat layer is at least a year away I think and it will remain in the 2.x baseline. So none of this discussion is imminent. There will be lots of time for users and developers to adjust.
The compromise is that you will be able to run those bindings, and just those bindings, on an older OH core and there will be federation set up between that older OH core and OH 3. OH 3 will have Items that duplicate those bound to the 1.x bindings on the old OH core, and everything else will be configured through OH 3.
Essentially, there will be an OH 1.x to MQTT bridge set up and in OH 3 there will be a way to automatically configure the Items on that bridge.
I think I posted a picture above. Maybe that was on a different thread.
The way it works though requires the compatibility layer. Even though you can configure it, the way 1.x bindings work and 2.x bindings work are so different from each other, without the compatibility layer there would need to be significant changes to the OH core to support 1.x bindings natively that no developer is willing to do.