Removal of the OH 1.x Compatibility Layer

The question is how much of a Bountysource is enough motivation? :wink:

1 Like

Why not make the underlying infrastructure support 1.x bindings better and more naturally, as an objective, instead of considering dumping them as a class of integrations (that no doubt took countless thousands of hours of development and maintenance work)? Examples given in this thread of the Expire, MQTT, Exec, HTTP, etc. bindings offer a vastly simpler and more direct way of solving a vast range of problems than the 2.x binding model.

The 2.x model removed the clean and simple continuity to Items, and mountains have to be moved to work around that loss. I see some newer bindings that seem to exist more because it was a programming challenge to create them, as opposed to actually making the product easier to use for the majority of use cases, which I find daft. At least some time ago, I felt like I was watching a reenactment of The Emperorā€™s New Clothes whenever we got close to discussing this subject.

If the people on the Architecture Committee could tone down the religious zeal to amputate parts of the product, but to instead make the whole product stronger and easier to use overall, I think it would be both well received and a fun challenge for the coders at the same time.

5 Likes

Please do me the favor and explain to me how auto discovery, natural language processing, machine-interpret-able configuration descriptions (for UIs and external services) work in OH1? If you canā€™t, please stop making noise in this forum, pardon, in this thread.

Iā€™m not speaking for the core developers but at the same time Iā€™m feeling like I do: A lot of thought went into the OH2 design conceptional wise. For a reason. Nobody is interested in going back to the OH1 days and no-one will spend and programming hours to keep that dying part alive for OH3.

Help migrating. Fund other developers to migrate.

2 Likes

Does that mean the Javascript transformation has been added to the 2.x mqtt binding for incoming and outgoing values?

This is really my biggest problem with this argument. It isnā€™t religious zeal. There are real problems in the OH 2 code. This is one proposal for how to solve those real problems. Dismissing these real problems as mere ā€œreligious zealā€ doesnā€™t really add to the discussion. It basically says ā€œI reject the notion that you even have a problem to solve.ā€ If it wasnā€™t a problem, the porposal wouldnā€™t have been raised in the first place.

But yes, I do believe making changes to the underlying infrastructure to better support 1.x bindings is certainly a topic for discussion.

  • What would that look like?
  • Would that help solve or exacerbate the maintenance problems felt by the devs?
  • Would that help or exacerbate the disconnect new users in particular need to figure out between use of OH 2.x bindings compared to 1.x bindings?

I donā€™t think that is necessary. Watouā€™s opinion is as valid as any of the rest of ours. And he has been a supporter of OH for longer than I have been and I consider him one of my OH mentors.

He raises some valid ideas about an alternative approach.

IMHO, removing the Compatibility Layer for OH 3 is a non-starter if it means the complete loss of support for all OH 1.x bindings. It would be far too disruptive and we would lose far too many users as a result. Not to mention the loss of developers.

So if we do remove the Compatibility Layer, how do we continue to support 1.x bindings? If no supporting the 1.x bindings is the answer then I will vote no on the proposal. I donā€™t know if that kills it or not (need to read the Governance again). As the voice of the users I canā€™t in good conscience vote for a proposal that will leave so many users behind.

Iā€™m not sure if David has checked in that change yet or not. But that was a design decision and not a fundamental limitation caused by a move from 1.x to 2.x. I interpreted watouā€™s statement to indicate that there are some things that OH 1.x bindings are allowed to do that cannot be reproduced in OH 2.x bindings.

5 Likes

The question I have is: what kind of problem? If itā€™s of the class of problem where the current released version of the product is failing to operate in its currently intended ways (as in, critical bugs), thatā€™s one kind of problem that would seem in need of being urgently addressed. But if itā€™s the class of problem where, ā€œIā€™m a developer, I want to develop some new features, but there is this ā€˜clutterā€™ in my way that if it were cut out of the product, I could more easily develop these new featuresā€, then you are saying developers need to easily write new code at the total expense of existing users. As a user aware of this kind of prioritisation, I would simply find some other product to invest my efforts into, and then eventually openHAB would have been the developers playground that slowly tortured its earnest users down to zero. This is the ā€œreligious zealā€ Iā€™m referring to, where an absolutist view of developersā€™ freedom of movement overrides all other considerations, into irrelevance.

My opinion is to have the main objective to remove oddities and exceptions from the userā€™s understanding of what openHAB is and can do, so improved UI to support bindings connecting to items, configuring these in the UI, and basically those things that would have avoided the confusion in the first place. I think itā€™s achievable to make openHAB better without also making it worse.

Absolutely correct ā€“ the reason we saw such crazy hoop-jumping in so many 2.x bindings was because they made many things materially harder and more complicated. 1.x bindings allow very powerful and simply expressed solutions to real world problems that are not possible in the 2.x binding model*, and the body of 1.x binding code is so deep and wide that amputating it in any future version is nothing short of an act of self-harm.

*just to add the note that the 2.x model added certain kinds of power and ease of use not possible in the 1.x model, but both points can be true at the same time without being contradictory.

4 Likes

Yes some people will go. Others will come. We are direct competitors to HomeAssistant, PiDome, Domoticz, Node-Red. And if we donā€™t provide an appealing solutions for new users, this product will die with its old user base. If that makes you leave the project, thatā€™s how it is. But it doesnā€™t need to be, if you just accept that OH2 is the concept how OH works now and just try to integrate yourself to make it better.

Not true. You apparently never have written an OH2 binding. You have full access to all OSGI services. If you want to, even the eventbus, which would bring you back to the OH1 world of course.

The more standardized way and the ā€œcorsetā€ that binding developers to a certain degree have is to make bindings more machine interactive. All Things, Channels, all config options, all IO interactions, everything follows a contract. And that is the real power behind those concepts and that is what makes it possible to provide a REST interface, autodiscovery and configuration interfaces.

You present only two choices.

What about:

  • technical debt that needs to be addressed because it consumes too much time from a limited group of developers
  • a schizophrenic configuration that causes lots of confusion for new users and sometimes even experienced users

These can be problems too. Or do you categorize these problems as just ā€œcoders want to code.ā€ As someone who doesnā€™t code for OH, I can say that the second one is a huge problem for new users.
The former Iā€™m told is a problem but canā€™t confirm. But I trust that if the developers say itā€™s a problem that it is a problem.

Sorry, but ā€œa schizophrenic configurationā€ is the current state of OH2 reality. Some things can be done UI based, BUT not all and not all combinations. At the end it is a false suggestion to users and nothing else.

I second @watou , OH2 was a big change in architecture with a lot of future promises. The first official release was just 2 years ago and it still does NOT support some functionality that was available in OH1. It offered some other new functionality (like discovery, channels etc.) but there are still numerous regressions from a purely FUNCTIONAL, NOT ARCHITECTURAL point of view. So I - from a purely userā€™s perspective - waited now 2 years for those architectural promises to be transferred into real functionality. The current discussion however is about a next gen architectural change with even more cut down of real world functionality (without ever enhancing functionality for real world compared to OH1). So I consider the dangers of users and binding developers turning away as VERY REAL.
Architecture should support functionality, not the other way round.

4 Likes

You are right that there all kinds of problems, and I only described two. The solutions to problems, however, like improving UIs and documentation, promoting a ā€œred-haired stepchildā€ to the main table instead of pushing him off a cliff, are the kinds of solutions that keep and grow the user base, if thatā€™s important to you.

In a traditional software product environment, a successful product manager hears about problems from users, but is very skeptical about problems reported by developers or the set of solutions they present, and knows to limit the possible set of solutions to those that donā€™t decrease the user base or create a reputation of indifference to existing usersā€™ concerns. If the only available developers are ones who will jettison the historical user base, is that really a reason to proceed anyway?

(I developed these opinions from having previously been an active developer over a long period on openHAB, ESH, 1.x and 2.x codebases, and as a user using home automation in three houses.)

5 Likes

@yves Are you willing to financially fund an Anel 2 binding?
Depends on the price.

Iā€™m not against it, yet my current focus for time and money these days goes to support a few other communities; mosty to teach children programming. That does not mean donā€™t value the work that happens here.
And yes one of the things Iā€™m promoting to youngsters and students is find some open source project to help out and learn at the same time.

As a community I do think itā€™s a bad idea that only 1.x bindings are upgraded if someone wants to pay to upgrade it. I much rather pay Openhab as a community to support the website and other infrastructure. And if I do, I would pay for a 3.x version , instead of a 2.x version that is outdated before we even startā€¦

And if we donā€™t provide an appealing solutions for new users, this product will die with its old user base.

at this moment Openhab is at the so called chasm.
We have innovators and we have early adopters.

We want to attract the early majority.
This has long been documented how to do that.
Read Geoffrey Moore excellent book on strategies on how to do ot.

one important thing is offer a full solution, that helps new users to make stuff work and make it work without much troubels.
Hence we need stable working versions for these people.

I think many people propose ideaā€™s that do support that.
What I read in your proposals here and in other discussions is you want to leave old users behind in favor of new ones.
wel one of the things that early majority people do, is they ask around, yes they trust mostly also early majority people, they only want to jump to the market leader.
that way they feel there will be a lot of support alsofrom other ā€œvendorā€/technologies etc.

With the current number of bindings Openhab does a great job.
And that gives a great impression to early majority people.
now these people also look around to hear what the innovators and early adopters say.
if they leave because they are badly treated (as in we donā€™t care about you and your bindings) the early majority wonā€™t trust Openhab and wontā€™ make the jump.

I heard no one say, we donā€™t want to move on. Everyone I read, said please move on. yet start by finish what you started. And letā€™s find a way to support the old 1.x bindings.

We have proposed solutions for the actions and the persistence. Thatā€™s great. One no two steps closer. letā€™s starts doing that. And then gradually look what is left.
and yes please lets find out what is used.

2 Likes

I donā€™t think that the binding interface will change much from OH2 -> OH3.
Itā€™s more the configuration part and the REST interface.

OH1 <ā€”> OH2/3 can be connected via MQTT. The eventbus hasnā€™t changed. That requires OH1 users to configure a few things multiple times, but at least the bindings keep working and keep reporting to the new runtime. I do not see many other solutions.

I guess to port one binding you need a day as an experienced developer. Because you are experienced you are also expensive unfortunately (== you loose a lot of money by not working for your clients but for bindings that you will never use). So Kais assumption that OH1 bindings will be migrated until end of the year is rather not happening, so we might want to concentrate on the first proposal.

Are you arguing with me or agreeing with me, because you are just reiterating what Iā€™ve been saying. The current state of configuring OH is not sustainable. Itā€™s a real problem.

And there is a separate thread discussing what the future UI will look like. But what will be the case is that the new UI will at least be feature complete. But any UI can only provide complete support for things that have a REST API.

There is no REST API for OH 1.x bindings. Perhaps there should be? There are lots of challenges to do that too but I donā€™t see why it canā€™t be discussed.

Which is why I canā€™t get behind removing the compat layer without something to continue to support some or all OH 1 bindings. But at the same time, I also see this ā€œtwo ways to configure thingsā€ as unsustainable. And since Iā€™m not a developer on OH, I canā€™t volunteer to build a REST API for the OH 1.x Items, not that I would even know what that would look like since there is no file writer for the .items file format and the JSONDB doesnā€™t appear to support OH 1.x concepts.

So who is going to write it?

I think the point there is that if someone doesnā€™t self volunteer to upgrade a binding, the users of that binding need to find or somehow or other create an incentive for a developer to volunteer to do the job. The users can shout and ask and complain but in a project like this we canā€™t force anyone to work on anything they donā€™t want to. Bounty Source is one avenue to try to get a developer to want to.

But it isnā€™t always as easy as that. I donā€™t think that an Anel Hut is even available in my country. Without access to the hardware I have no reason be believe I could successfully build a 2.x version of the binding. So not just any random member of the OH maintainers can pick up any random binding and rewrite it as a 2.x binding.

Why couldnā€™t the OH 2/3 system automatically create an Item to represent Items that generate events from the other OH? It seems feasible. Iā€™m just brains storming.

Could the OH 1 core be something that could be installed as a package on the same Karaf? I donā€™t know how well a single Karaf instance can host two separate apps like that. But that could provide reduction in complexity for both developers and users. And it wouldnā€™t need to be the whole OH 1 core, just enough to load bindings and pub/sub events to the OH 2/3. We are not looking to give users a full OH 1 instance. We are looking for a way to allow them to continue to use OH 1 bindings on the newer OH 2/3.

It doesnā€™t reduce the scope of the compat layer as this is basically doing that same job. However, it lets us extract it from the core which may make both the core and the compat layer simpler over all. New users who donā€™t need a 1.x binding will never have to have it running on their system. Old timers are experienced enough that needing to install one more Misc add-on and move over their existing configs is not too much of a burden. And for the new users who do need a 1.x binding, I guess we still have the forum to help walk them through it. Iā€™m sure Iā€™ll write a tutorial for the main docs if itā€™s needed. But at least by making this thing separately installed we are making it clear that it isnā€™t standard which might make it easier to mentally deal with the fact that configuration is so different. And by making it install-able through the UI and not forcing users to run a separate service we are keeping support for the OH 1.x bindings a part of the core OH application instead of a work around.

I donā€™t know the code. Iā€™m just throwing out ideas that might make this approach a little more usable.

I completely agree. If that were going to happen, it would have already happened by now. Another year isnā€™t going to change that. Thatā€™s why Iā€™m not for removing the compat layer at this time.

I donā€™t think that is the only proposal on the table. Itā€™s one I like but, while it hasnā€™t been said in so many words, another proposal would be to make modifications to the APIs and core that would allow OH 1.x bindings to be first class citizens in the OH ecosystem. I suppose this would mean creating REST endpoints and updates to JSONDB to support saving binding configs, changes to the UIs, etc.

I want to make sure this idea gets a full hearing too. I personally like the first option better (if my brainstorming ideas are feasible) and suspect it would be less work now and in the long run and provides the best user experience to the old timers who still depend on these bindings since their current configs will continue to work. It also keeps up a little bit of pressure to migrate some of those old 1.x bindings to 2.x/3.x but without dropping the users of these bindings on their butts.

2 Likes

I think the point there is that if someone doesnā€™t self volunteer to upgrade a binding, the users of that binding need to find or somehow or other create an incentive for a developer to volunteer to do the job. The users can shout and ask and complain but in a project like this we canā€™t force anyone to work on anything they donā€™t want to. Bounty Source is one avenue to try to get a developer to want to.

yes I know itā€™s more complicated.
I agree that shouting never encourages someone.

But it isnā€™t always as easy as that. I donā€™t think that an Anel Hut is even available in my country.

Itā€™s not either in my country. I imported it.
And I did pay for the translation of the manual. (That I gave back to Anel to use)

Without access to the hardware I have no reason be believe I could successfully build a 2.x version of the binding. So not just any random member of the OH maintainers can pick up any random binding and rewrite it as a 2.x binding.

hence I was trying to find out who else has the hardware and has programming skills.
and yes paying a programmer for the hardware seems logical if she does not have it.

Was the creation of the compat1x layer at all related to splitting off openHAB core to create Eclipse SmartHome? If so, will the new project of re-homing ESH back into OH re-open the possibility to more naturally support 1.x bindings in UIs and configuration? I recall that having ESH split off from OH caused a large collection of headaches and constraints, and perhaps as they are undone openHAB can re-coalesce into a cleaner, more unified product with the two binding models both as first-class citizens?

1 Like

Isnā€™t the compat1x layer installed and active by default ?

That was the case back in 2.3.

As far as I can tell, CalDAV will not work without the compat layer:

23:43:38.848 [ERROR] [org.openhab.binding.caldav-personal  ] - FrameworkEvent ERROR - org.openhab.binding.caldav-personal org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.caldav-personal [222]

Thanks a lot for clarifying this.

Maybe itā€™s only my personal requirement, but I consider this binding to be quite generic and essentialā€¦

2 Likes

Thatā€™s a question I cannot answer.

I canā€™t answer this definitively but I have the impression from what people who know more than me on this thread is that the layer does more than just translate package names. If so, those other parts (e.g. the ways the bindings can access the event bus?) may still need to be addressed.

Regardless, more natural support for OH 1.x binding is still going to require significant modifications to the 1.x bindings I suspect as there will need to be a way to configure and bind Items to them through the REST API instead of/in addition to .items files.

All things are possible in software, but is going down this path something that someone is willing to volunteer to do? This last question applies to any approach discussed here. Unless someone is willing to step up and actually do it the idea is dead in the water.

I donā€™t like to speak for others as Iā€™m often wrong, but Iā€™m pretty positive David would not volunteer to code it in this way. Kai seems willing to leave OH 1.x behind so I doubt he would volunteer to do it. There are three or four other core maintainers, will they step up? I know there is some bad history that might prevent it, but would you?

I wish I did know more about the specifics so I could answer.

The question is certainly worth answering. What would prevent OH 1.x bindings being supported like 2.x bindings?