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.
I still use the InsteonPLM binding and it is an OH 1.x binding still. I know others still use it as well. If that binding were to disappear in OH3 I would be pretty likely to abandon OpenHAB altogether as that is the majority of my lighting system. I would love to help develop a new binding for Insteon but I haven’t had a ton of luck getting through the documentation for developing bindings. If add-on development documentation were to be more thorough I’d be more likely to help pitch in and keep things like this up to date as I’m a huge fan of OpenHAB and really would love to see it grow.,
Apart from the current situation (the doc is slightly out-dated), where are your problems? Maybe I can point you in the right direction.
I meant to reply to this earlier and got distracted.
I think mostly it’s just that I’m not an experienced Java programmer, so I’m learning that but that’s on me, not Openhab.
Other than that I did start attempting to develop a binding, got about a week into it, and the build started failing. Only for me to find out that the skeletons have been abandoned and the whole process is changing. So now I have to figure out what needs to be changed to make it compatible with the new build system.
For the most part the documentation isn’t all that bad, Most of it is just learning curve on my part but I’m hoping things stabilize so I can dig into it without having to keep going back to fix things that changed. If the developer documentation for the new process is good I’ll get back at it.
I really do believe in the OpenHAB project though and would like to be able to gain the experience needed to help contribute in whatever small way I can. I’m not sure if that’s of any help at all but I’ll give feedback in any way I can.