Proposal: Removal of compatibility layer in 3.x

[kaikreuzer]

Dear @openhab/architecture-council,

This topic has been brought up by me in https://community.openhab.org/t/directions-for-openhab-3/67372 and has already been discussed in depth in https://community.openhab.org/t/removal-of-the-oh-1-x-compatibility-layer/67553.

Meanwhile, quite some time has passed and our master branches have version 3.0.0 now, so it is time to take a final decision.

My proposal is to completely remove the compatibility layer from openhab-core.
My reasoning:

• It makes the code base leaner
• The code will be in conflict with the current openhab-core code when we now refactor the org.eclipse.smarthome namespace to org.openhab.core.
• All persistence add-ons will anyhow be migrated (see https://github.com/openhab/openhab2-addons/pull/5275), so for those there is no longer the need of the compat layer.
• openHAB 3 users do not need to understand the difference between 1.x and current add-ons anymore - this will cause less confusion, simplify the documentation as well as the support in the new UI.
• Many add-ons have already been migrated with the 2.5 release, many more are currently in progress. If we talk about a release of openHAB 3 not before end of the year, there shouldn't be much need for 1.x support anymore.
• For everyone who nonetheless requires 1.x add-ons, this can be achieved by linking an old runtime through MQTT (see https://github.com/openhab/openhab2-addons/pull/5275). To make this even more convenient, we could think of a special connector that reads the items of a remote instance and makes them available in openHAB 3 through MQTT - this could be a nice feature for distributed setups anyhow.

So wdyt? @openhab/architecture-council, please vote on this proposal through 👍 and 👎 and if you veto, please leave some comments on the why!

[wborn]

Does this also imply we will stop maintaining the openhab1-addons repo and archive it after the final 2.5.x release? There is a close relationship between the decision and maintaining that repo.

[Hilbrand]

To add to this: Here is the overview of all openHAB1 bindings and their migration status: openhab/openhab-addons#6179 I also started a tutorial series on how to migrate openHAB1 bindings on the forum.

[digitaldan]

Apologies if i am bringing up a topic that has been discussed 100 times before, but do we have an idea what 1.x addons are "popular" and have not moved to or plan to move to 2.x/3.x ? Is there a reason other than lack of interest they can not be moved ? If it's a manageable list, i would volunteer helping to move them to 3.x , maybe a few others would as well. Taking a poll on the forums might be helpful to find the top 5 or 10. (although i know this is a touchy subject there !) .

But i agree with all of @kaikreuzer points above, and we should move forward regardless.

Does this also imply we will stop maintaining the openhab1-addons repo and archive it after the final 2.5.x release?

If we found a maintainer who wants to volunteer to manage the 1.x repo i guess we could keep it open for those using mqtt or just staying on an old version. But, i think that would ultimately become a burden wrt continuing issues on the forums, github, documentation, etc.. So yes, i would be in favor of doing this.

[digitaldan]

@Hilbrand , you answered my question as i was typing :-) Thanks!

[kaikreuzer]

stop maintaining the openhab1-addons repo and archive it after the final 2.5.x release?

Probably. There isn't much activity anyhow anymore (especially no active maintainers present). If there's need, we could nonetheless release kar files of 1.1x versions of those add-ons completely independent of any openHAB 2/3 releases, so there's imho no strict causality.

[digitaldan]

According to @Hilbrand s excellent list, it seems like there are just a few that have the most votes with no 2.x replacement , fritzboxtr064, wol, caldav, pushover, TCP and then the CalDav group of bindings. (FYI the wol binding looks like an easy candidate to move, i will volunteer to take that :-) )

Given @Hilbrand s also excellent tutorial, i think there is enough effort made to try and support bindings that people care about and my vote is we should move forward with Kai's suggestion. 👍

[rkoshak]

For everyone who nonetheless requires 1.x add-ons, this can be achieved by linking an old runtime through MQTT (see openhab/openhab2-addons#5275).

Did you mean to link to a different issue or PR? That's the same PR as the migration of the persistence add-ons. Is there work to rebuild the MQTT Event Bus capability in the binding? I agree, it would be easier for the users if this federation mechanism didn't require MQTT and the OH instances just knew how to talk to each other.

votes with no 2.x replacement , fritzboxtr064, wol, caldav, pushover, TCP and then the CalDav group of bindings.

Actually, the one binding that caused the most vocal complaints when this was first brought up is Insteon and as far as I can tell the effort to build a 2.x replacement has stalled. I think we would do well to try to shepherd that effort if we can.

I vote that we should move forward with removal of the compatibility layer, but I do so with the hope that we will make the effort to federate an old OH instance with OH 3 to run those legacy bindings as easy as is possible. 👍

It would be really cool if we had a really stripped down OH 1 or OH 2 instance that has just enough to run the binding and the federation mechanism. No rules, persistence, UIs, etc. Minimal resources to run and minimal resources to maintain for how ever long we decide to let it limp along.

[ghys]

While I admit I had initial personal reservations about the removal of the compatibility layer, my main concern is really about the optics of having to remove maybe a significant chunk of the (long) list of devices and services that openHAB supports. Even if a new binding exists, surely some users will be annoyed to be forced to rework their working setups. Things which could be set up easily in one line of configuration would perhaps require a different way of thinking and end up more convoluted, some examples from my production system:

Switch Kodi_Power "Home Cinema (Kodi)" {xbmc=">[#kodi|System.Suspend]", wol="192.168.1.255#90:FB:A6:xx:yy:zz", nh="192.168.1.x:80"}
Switch MusicCast_Salon "Salon (ampli) [%s]" {http="<[http://192.168.1.xyz/YamahaExtendedControl/v1/main/getStatus:20000:JS(musiccast_power.js)] >[ON:GET:http://192.168.1.xyz/YamahaExtendedControl/v1/main/setPower?power=on] >[OFF:GET:http://192.168.1.xyz/YamahaExtendedControl/v1/main/setPower?power=standby]"}
Number MusicCast_Salon_Volume "Volume Salon [%d]" <soundvolume> {http="<[http://192.168.1.xyz/YamahaExtendedControl/v1/main/getStatus:20000:JSONPATH($.volume)] >[*:GET:http://192.168.1.xyz/YamahaExtendedControl/v1/main/setVolume?volume=%2$s]"}

However!
All in all, aside from this "marketing" perspective, I believe the rationale here is fair and after the initial frustrations, the abandonment of this part of openHAB's legacy will have a positive effect on the project's future. With a comprehensive MQTT based 2.x to 3.x communication for those who need it, and hoping we'll see lots of bindings migrated next year thanks to @Hilbrand's tutorial - I'll see what I can do about the couple of bindings which I still use, mainly epsonprojector - the negative impact might just be not that significant.

And with some additional efforts (like sitemaps, persistence & transformation configuration), without the 1.x bindings forcing users to define some items in .items files when they could prefer everything to be centrally managed in the JSONDB, it might open up the possibility of a true "purely UI" setup & administration user experience, which I will try to make as pleasant and exciting as possible in the new UI 🙂.

I therefore support this move 👍

We should nonetheless keep in mind, among other things, that 1) this will require significant efforts in the documentation to remove or rewrite everything that'll become deprecated, 2) old posts on the forum will still offer examples and solutions which won't work anymore and some users will be oblivious of this fact.

[rkoshak]

I think that regardless of whether the compatibility layer stays or goes, the docs will need a significant rewrite given all the other changes, (Rules, new UI, etc.). I'm hoping that we will get to see some early releases of things as they change so we can get started on that before the last moment. :-)

[kaikreuzer]

Did you mean to link to a different issue or PR?

Yes, sorry. This was the link I wanted to post: https://community.openhab.org/t/mqtt-2-5-event-bus/76938

It would be really cool if we had a really stripped down OH 1 or OH 2 instance that has just enough to run the binding and the federation mechanism.

Yes, that would make sense - and if we'd use the openHAB 1 runtime, it could be indeed be very lean.

the docs will need a significant rewrite given all the other changes, (Rules, new UI, etc.)

Definitely so. Alone removing all occurences of openHAB "2" and Paper UI will be huge. (@ghys Off-topic, but just to mention: I believe we should keep 2.5.x docs as the main docs on the website until we officially release 3.0 - otherwise lots of users will be very confused).

[kaikreuzer]

@wborn If I count correctly, only your vote is missing.

[rkoshak]

This was the link I wanted to post

😊 I thought maybe someone had a PR that made my little effort obsolete.

I'll make it a priority to create a Rule Template out of it for sure to make installation easier. It's a Python library right now and it works great so far. I've some further ideas that would make it better at this type of federation. (e.g. automatic creation of Items, auto discovering the remote OH instances, etc).

[wborn]

Yes I also agree we should remove the compatibility layer. 👍

It has served its purpose very well for everyone to smoothen the transition from OH1 to OH2 for the last 3 years.
First everyone used few OH2 add-ons and many OH1 add-ons. Now the situation has completely reversed and the most commonly used add-ons are available as native OH2 add-ons.

We have also seen that the compatibility layer makes it harder for adding new features such as units of measurement (QuantityType). So it makes a lot of sense now to remove the layer for the greater good.

I do feel the pain of those heavily impacted by this as it may block their upgrade path or complicate their setup with multiple instances. For running multiple instances on the same machine using the openHAB Docker container may be of great help.

As it will still take a while before there is a stable OH3, I have good faith many more add-ons will be migrated in the mean time. I do urge contributors doing this to also create an issue for this. That way they can team-up or work on migrating other add-ons.

Sometimes OH1 add-ons can also be implemented in other or better ways. E.g. the WOL action could also be added as action to the existing network binding (#3799).