Removal of the OH 1.x Compatibility Layer

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.

Yes.

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.

3 Likes

All,

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!

K

7 Likes

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.

6 Likes

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.

Greetings.

If you have separated the business logic and openHAB interface, which is always recommended anyway, there is not much to do actually. You need a Factory class and a few ThingHandler classes, depending on how much you want to follow the Thing approach. You could in theory just add one single Thing with all the configuration that your OH 1.x binding used and therefore one ThingHandler class.

The problem with other OH 1 bindings is that their code base is old and they do not use new library versions and best practice dependencies (like gson instead of jackson). If you have a relatively new codebase, you do not suffer those issues.

1 Like

Is there sample code and documentation on how to do the minimal conversion, that might help get some of the more complex bindings migrated such as insteonplm. It does appear to have the openHAB interface separated from the business logic (https://github.com/openhab/openhab1-addons/tree/master/bundles/binding/org.openhab.binding.insteonplm/src/main/java/org/openhab/binding/insteonplm).

1 Like

No there is no such thing. A blog post with a walk-through would be probably be the right format.

2 Likes

Thank you, @David_Graeff and @ranielsen .

When I have some time I will study the openHAB developer guide, and if as you say the migration is simple, I will try to rewrite the binding to be compatible with the 2.x model.

What I don’t know how long it will take me to do it. Lately I don’t have any free time.

Greetings.

1 Like

Hi
it would be cool to have such walk-through.

I would be very much interested in the migration of the LCN binding.

Tim

See Tutorial: Migrating OH 1 addon to OH 2: preparing (1/x)

It’s a work in progress but already very useful.

2 Likes