Removal of the OH 1.x Compatibility Layer

I haven’t thought about this aspect. I always assumed that the binding documentation clarifies what the binding is capable of. And if that is not working, it is a bug. But an average Joe might not differentiate enough.

For my bindings I usually ask the users to create a bug report on Github. I don’t expect them to know of the platform. But I also tell them that I will probably forget about it without a report.

Do I understand correctly :

you are saying that the bug reported in 1.x

Is working in 1.x (with the correct java)
and is not working in 2.x (with the same java version.)

From my perspective…I think it’s OK to not offer full backwards compatibility…but what makes users leave is not providing backwards capability

We need to be able to continue to operate the items and devices we own…with the new iterations of OH.

I will use the example of the OH1 EXPIRE binding…if you want to not support it in version OH3.0 - I’m ok with it (just typing this scares the Sh*T out of me) but provide me that same capability in the UI…why does it have to be a binding? Maybe it doesn’t have to be a black or white issue but some level of grey in between.

Let’s face it…it’s a hell of a lot easier for me to switch HA software that supports my tech than it is to pull out all of my devices that are no longer supported with a code/version change and replace them with ones that are.

I love my OH installation - and would prefer not to look for other solutions…but if my house no longer operates the way my family is used to…I will have no other option…staying on old code is not a viable option for me.


That sounds like a good idea. Though that thread is already lengthy and posters get annoyed when we ask them to read it.

Usually, when a user has a problem and they post it to this forum, we will attempt to solve their problem or if it is a bug, narrow down what part of OH the bug resides. Then we will ask them to go file an Issue, often proving a link on where to go.

I would prefer that the users follow this approach really because I don’t think that “normal users” as Michael put it, have the knowledge necessary all the time to know to go post an issue all on their own or know which repo it should be filed in.

But at the same time, when asked by someone here to go file an Issue, I do expect them to do so. As someone who is not experiencing the problem myself and maybe not even using that binding, I’m not the right person to file the issue. If additional information is required like debug logs and the like I won’t be able to provide it.

Because the only way the developers who will fix the bug know there is a bug is by there being an issue on GitHub.

As Jan said, it is unreasonable to expect the developers to read every posting trolling for potential issues.

Not all Issues are actual bugs but instead miss-configurations or miss-understandings. That’s what the forum is for. But to repeat myself, when the helpers determine that the issue is indeed a bug, we need the user to file the issue because the helpers are not in a position to help the developers figure out the source of the bug.

Honestly, if this is too much to ask of a user, then that user is a net drain on the project over all. Open Source development is a community effort. We ALL must pitch in and do our part to make the project succeed. As a user of the project, you can do your part by filing issues when you find a bug.

It’s not hard. We can help you with the process if you run into trouble or can’t figure something out.

If you can find ANY open source project that works differently I’d be very interested to see it. They may not have you go to GitHub but they will require you to file an issue

This. ^^

The forum is for asking for help. Sometimes on the forum we may determine that you have found a bug. If we do, we need you to do your part as a member of the community and file the issue. If that is too much then I’m sorry to say that you are a net drain on the community.

In this context issue == bug.

We will never recommend you file an issue over a problem. And as I’ve said several times in this one reply, we don’t expect users to just know when to file an issue. But when the helpers on the forum ask them to, we expect them to do it.

The documentation is almost never adequate. Honestly, the folks like me and vincent and dim and all the rest are the first line of triage. We end up being the ones that walk the users through some diagnostic steps that will help us to determine if the problem is configuration, indeterminate, or really a bug in a binding or the core. If it’s determined to be a bug, we will ask the user to file an issue.

That’s why we wrote that “Help us Help You” posting. We spend a huge amount of time playing 20 questions and reading through logs and such to try to diagnose problems. 80% of the time we find it’s a configuration problem. The rest we send to file issues where we assume the devs pick up the 20 questions and hopefully find a fix.

In this particular case, Jan asked vossivossi to file an issue. I went and looked and found the wrong already opened issue confusing matters. But the fact remains, the user knew to go file a bug because we asked him to. We don’t expect any more of users than that. We don’t expect them to know to go file an issue on their own. We do expect them to ask for help if something doesn’t work and file an issue if they are asked to.

So it would seem. The problem must not be in the JDK on Network Binding.

Expire is really not the focus of the conversation because it never should have been a binding in the first place. It should have always been part of the core. And I suspect that what Expire does will become a part of the core in OH 3. At least I’ll continue to squeak about it until it is. :wink:

We do have an approach to provide continued support for OH 1.x bindings. But realize that OH 1.x bindings ARE old code. If you need to keep using OH 1.x bindings, then staying on old code is your only viable option.


It’s my only viable option if I want to stay with OH. And this is what I fear how a lot of users may feel.

Take away the compatibility…don’t take away the features…I know this statement is simplistic but it’s the basis of most user’s fears. Is updating the binding the only way to keep these features in OH?

It may be…

my point is, with a few exceptions, if you are running 1.x binding, you are already running old code. Continuing to support the old code on an OH 1 or 2 instance and federating with OH 3 only reveals the situation we are already in. It doesn’t change it.

I’ve said it before and I’ll say it again. Only one person has maintained the compatible layer all these 5 years and he is done. We can force him to work on something he doesn’t want to. No one is stepping up to maintain it.

What would you have the project do? At least we have a way that the OH 1 bindings can still work and interoperate.

Will we lose users? Yes. but it’s not like we have a choice.

I hate to see any user go, but at the end of the day, but if OH no longer sure your needs with the support the devs are willing to give then perhaps OH isn’t going to work for you.

The devs do what they can. If it’s not good enough then so be it. We will continue on doing the best we can and should you decide to come back we will welcome your return.

I think I might be one of the “quiet bystanders” here as was @KidSquid, I am now getting to the point to chime in. A decision to eliminate OH 1 binding compatibility for OH 3 will force people to stay back if they rely on OH 1 bindings to run their hardware (e.g. Insteon). In my case, if I move to OH 3, 90% of my home will stay in the dark (literally) when it comes to automation. Anybody in that situation will stay back, and eventually, over time will migrate to other alternatives. I would imagine that the loss of that user base (a lot of seasoned users over the years) will hurt the overall project because they loose their voice.
The net effect of staying back will also eliminate the chance of getting an adaptation of the old bindings to the new OH 3 concept, since new users will not sign on when they see that their technology is not supported, and old users only hear “…well, the binding is not supported by the original developer any more…”.


There is an mqtt bridging software existing.


I totally agree. If we would expect the developers (I do hope plural is still valid) to read all posts in here, shen should they do the needed work on the code?
My personal reasoning for answering on this forum is to give the developers a break! I hope their “de-motivation” can be kept at a minimum that way.


This “staying on old cold is not viable” - I don’t know. As said, you are on old code already. It sounds like “you have to refresh this binding, because I say so”. I know it mustn’t be meant like that but I see a little danger discussions heat up with those demands.
No want really wants to leave users behind, I think.
On the one hand core maintainers can spend their time to provide a compat-layer for bindings where the maintainers don’t want to “upgrade” them to a newer binding-version or they can evolve the core.
I think it’s not easy but may be for really heavy used bindings (yes, hard to measure that) there should be a way to refresh them to not loose the userbase and make all of them unhappy. But to maintain a compat-layer which only 1 or 2 persons can maintain at all for some bindings which are just abandoned and a handfull of users out there using them is not the way to go, from my limited perspective.

1 Like

How about something in the middle, is there a way the bindings could be updated with minimal effort? Maybe some sort of helper libs can be created to do the heavy lifting and the bindings are updated to use them. For example, I only use OH for Insteon, and Google Home, and the rewrite of the binding would be a significant undertaking. It would take months of effort to come up with a stable binding since the Insteon protocol is proprietary and very little documentation exists publicly. If I’m forced to run two instances and use something like mqtt, I’ll go elsewhere.

1 Like

For better or worse there is, rewrite it as a 2.x binding.

But what I’m learning from this thread as the binding developers refuse to do that. They may have good reasons why, but at the same time, none of them have volunteered to help maintain the price of OH that allows them to continue to run on OH2+.

If there were it would have alreafy been done. The problem is the two are fundamentally different in a number of ways that makes the effort fairly significant. The configuration and how the bindings interact with Items are completely different requiring in some cases a significantly different way to use it. Compare Exec 1 to Exec 2 for an example.

If the compatibility layer is so important and so many users and developers are threatening to leave instead of compromise, then why was the response not “Let me help maintain the compatibility layer” instead of “you must keep doing this work you don’t want to do or I’ll leave”?

Is a simple as that. The compatibility layer is going away because no one wants to maintain it. If it’s so important to you, then step up and volunteer to help maintain it. It might stick around if you do.

You all have the power to save the compatibility layer if it is truly that important to you. If not, the developers have offered a compromise that lets OH 1.x bindigs to continue to function. If the compromise isn’t good enough, then this was going to happen sooner or later anyway.

PaperUI is being replaced because there is no one left who knows how to maintain it. The compatibility layer is going away because there was only one developer ever willing to maintain it and he doesn’t want to any more. We can’t keep limping along with large parts of the core that no one is willing to maintain. It doesn’t matter how much of an impact it had on you as a user. To the developers I say step up and take on maintaining the compatibility layer or frankly you are being hypocrites. You demand others to do work they don’t want to do so you don’t have to do work you don’t want to do.

I try to be the voice of reason here but I’m really getting frustraited at the this response. Instead of “how can I help prevent this” the responce is just a bunch of threats.


I think we can close this thread now anyway. Kai made it clear that he is not maintaining OH1 compat anymore and it will be removed from the next iteration of OH.

The OH1 core distribution gets a small download link somewhere at the bottom of the download page and will stay in the repositories and can be used for OH1 bindings. Via the mqtt eventbus binding a connection can be made between a new OH and OH1.

OH1 should not be connected to the internet as no updates will be developed. OH1 bindings will receive updates though, whenever the OH1 binding maintainers update their bindings.

All problems solved.

If someone was prepared to look into migrating a 1.x binding to 2.x is there any documentation existing that describes the major differences and where to start?

1 Like

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.