Removal of the OH 1.x Compatibility Layer

Interesting, can you clarify this statement?

OH3 or OH2.5?

I’m sorry I should have written “from the next big iteration”. But if you have followed this thread you should have known that detail :slight_smile:

I have followed this thread and I have assumed this, but assuming is never the best idea.

So instead of assuming i asked for clarification of that detail. :wink:

Thanks for your elaboration, I tried to say what you have written but through the flower - let me look that up - have tried to say it in a roundabout way (seems to be the english equivalent).
I just wanted to say it may be to consider to find ressources to rewrite a binding if it is really heavily used. But I think this will be discussed at enough threads and if “loosing” a binding will impact many users heavily there might come up a solution, but than there might also be enough users who support making a new binding happen in whatever ways they might contribute. But that’s totally out of my scope. I waited quite some time for a 2.x binding and it has happened (KNX), so I will not have a problem with removal of 1.x.

Once a v2 Add-on is available, each end-user will have to convert over to use it. I’m not sure everyone understands these won’t be drop-in options into their existing deployments.

The v2 version may provide the same functionality but, as others have pointed out, it often provides it in a very different manner. (v2 Things/Channels/Items vs v1 raw Items)

From a config standpoint, each end-user will need to map “how it’s done” (from-to) and make the relevant changes to their OH config to use any replacement Add-on. This conversion is likely manual for the end-user to work out… after reading new/old docs (etc)

To give a sense of the costs each end-user will pay to convert, I’ve been doing this for various v1 Add-ons in my Production system.

Here are the sample end-user costs I’ve had to manually lookup, understand, prune, and convert for a few Bindings that I’ve done recently:

  • Astro Binding - 3 Items, total time 90 minutes
  • Mqttitude Binding - Eliminated, for config simplicity, 5 minutes
  • myq Binding - Eliminated, for config simplicity, 5 minutes
  • Weather Binding - 10 Items, total time 90 minutes (transition from Weather/WUI to OpenWeather)

Remaining to convert, should counterparts be required. These are scarier since there are many more Items and Rules, and there are likely semantic differences that’ll impact the rules more:

  • MiOS Binding / Action - 600+ Items, 40 Rules, Misc Sitemap stuff
  • Prowl Action, 10+ Rules
  • Nest Binding -150 Items, 5 Rules, Misc Sitemap stuff
  • MQTT Binding - 230 Items
  • Expire - Already discussed

On a positive note, it’s been quite carthartic nuking the lesser used parts of my (file-based) OH 2.4 config :wink:

Given the many instances of that having occurred I assumed this was understood but like job said above, best not to assume. You are right, migrating configs fits take some work on the user’s side. And sometimes the new and old binding cannot run at the same time because of a shared resource like a USB device. One need look no further than the KNX 2 and MQTT 2 postings for examples. This is a good thing to bring up.

I would suggest taking the opportunity to apply Design Pattern: Separation of Behaviors to centralize your Prowl alerting so in the future there will only be one rule to charge should, for example, you decide some other service meets your needs better.

As a data point, I think I spent under an hour for Nest just recently. I just had to create the things and update the Item binding config with the link to the proper channel. No charges to my rules or sitemap were required, though I expected some changes due to UoM, it turned out what I had worked fine.

Maybe not all problems, but I think it is a decent compromise given the circumstances.

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.

2 Likes

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.

2 Likes

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