Removal of the OH 1.x Compatibility Layer

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.

I have that exact usage in my Energy monitoring (BTMon), against Eclipse’s Mosquito MQTT Server, so the limit’s not there.

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.

  1. 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.

  2. Stop OH

  3. 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.

  4. Start OH

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.,

1 Like

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.



I started developping for openHAB somewhere in 2011 if I remember well. I have seen a lot of stuff happen over time, and contributed a lot (which I was not always credited for), and I stirred sentiment from time to time way before the existence of a Architecture Council. I have been from the scene for more than a year due to some personal problems in my life, but let me shed just a short comment on this lengthy thread

I am the author of 10+ bindings. I have migrated to OH 2.x before the existence of the Compatilbity Layer. I did not complain. I just put up my sleeves and coded a 2.x version of the bindings I needed, also bindings that were not mine. Just let supply and demand of contributed effort and requested bindings to their work. If a binding has not been ported from 1.x, and if a breaking change will be introduced by OH3, and that given binding is not ported afterwards, then this means there is no need for it. If needed, i am sûre the one in trouble will make sure effort will be put to migrate it. Just like I did so many years ago. What I hope that could bring is another person doing real contributions to OH instead staying at the “user” side.

So, for that matter, let’s drop that Compat Layer asap!



It’s not that I would not want to contribute, but I do not have the skills to do so.
So, maybe there are some users which only need a small kick :wink: to start to contribute, but that’s definitely not the average user.

Sure, but if one is able to hack together a bunch of .rules, then it is not more difficult to do some Java development, especially since we have such a good documented code, as well as normal documentation that describes the concepts and all.

Myself I am not a software engineer by profession, still, I also had to climb the learning curve (for example, never programmed in Java).

I favour any action that makes things go forward, if that means breaking something, well, then that has to be considered.


I’d have to disagree. I consider it a good deal more difficult to develop (or debug) binding code than write rules. I also believe the latest round of development has made it more and not less difficult.

yeah but hang on… that is because of the migration and ensuing chaos, not the language being more difficult to learn and we are getting much closer to (back to) a developer friendly environment by the day

1 Like

44 posts were split to a new topic: OH 1.x add-on assessment

Hello everyone.

As a developer, I understand the reasons why the elimination of the 1.x compatibility layer is proposed, and in the end I share them, but I have to say that this is particularly a big problem for me.

I think the approach should not be 1.x compatibility layer = yes, or 1.x compatibility layer = no. But how to keep bindings 1.x working for users who still need them, either via 1.x compatibility layer or another method, such as having another OH 1.9 instance linked by MQTT. Always looking for the simplest and least traumatic solution for everyone, developers and users.

In my case, I have spent several years writing in the free time the binding “Cardio2e”, based on openHAB 1.x. Last year I finished writing the documentation, and it was finally included in version 2.4. I fear, as a result of this thread, that it is possible that the binding that has taken so much effort to write is no longer functional in version 3.x; and that all my effort has been left in broken sack. And at the moment I do not have time to rewrite the code (quite complex, by the way) and adapt it to the new model of bindings 2.x. I know at least 30 users, including myself, that we would make use of this binding and that we will have to remain anchored in openHAB 2.x if finally a formula is not provided to integrate it.

It occurs to me that perhaps someone could write a migration guide to 2.x for developers of bindings 1.x, which minimizes the rewriting effort to the maximum, even having an archetype that facilitates the work of migration.