Using very old major releases of openHAB is obviously unworkable as the ecosystem of devices and technologies changes over time, and I’m surprised anyone would present that in good-faith as a workaround to the user-centric concerns I’m describing.
The assumption that no one will maintain X part of openHAB in the future is equally valid or invalid for any part of openHAB, but suggests a bias for or against specific aspects of the system to say X part won’t be maintained. Componentry on which other pieces are built should definitely be maintained into the future, and no doubt the pieces on which users depend should be and will be maintained. Historically it was only you, Kai, maintaining the compat1x layer, but picture a new form of project governance where others are invited in and share maintenance of these pieces: problem solved!
If the full measure of what openHAB means for users is what the current developers deem valuable or use themselves at any given moment, then that is no comfort to users who would hope to get at least several good years out of their investment setting it up and depending on it. I would urge you to rethink your priorities so that the top priority is the total number of happy users only increases over time.
I was making what appears is an incorrect assumption that once we reported it works that changes were made to make the compatibility layer no longer necessary. Apparently that isn’t the case.
That compatibility was apparently provided through this compatibility layer, the removal of which is under discussion.
That was my assumption as well but now I wonder if there is more to it. If it’s just the imports, then those are changing again anyway so we either need to change the compatibility layer or we need change all the bindings.Right?
Indeed. Just look at the fundamental differences between the 1.x and 2.x versions of the Exec bindings. They are almost completely different in concept and usage. MQTT 1.x and 2.x it’s the same story.
The change that drove a lot of the original need for the compatibility layer were caused by:
moving the core OH packages to the ESH package name space (i.e. the imports changed)
in OH 2, bindings are not allowed to communicate directly with the Event Bus but in OH 1 bindings all communicated with the event bus.
The reason the OH 1.x Compatibility Layer is up for discussion is because we are now merging ESH back into OH and all those packages are changing again.
I for one, as a member of the AC, would vote against the change if that were to happen. We do not yet have enough OH 2.x replacements for heavily used OH 1.x bindings. It’s IMHO premature.
But, at the same time, from the users perspective the fact that there are not 2.x versions of all bindings is a problem. The fact that we can’t do anything through the REST API to create and configure Items bound to 1.x bindings means that as long as these 1.x bindings exist we will always have two configuration paths, two ways to do things, and this continued dual parallel paths for configuring and using OH.
As a user and someone who speaks for the users in discussions like these, if you take a 1.x binding and make it a 2.x binding with exactly the same capabilities and features, as a binding developer you may not think you are adding anything but from the user perspective you really are. It would be a huge improvement in usability and consistency from the user’s perspective. It is absolutely not a waste of effort and I encourage all maintainers of 1.x version bindings to please consider building a 2.x version of that binding.
David and Scott already have a plan to convert the Actions to 2.x and apparently it isn’t too hard. See OH1 Actions -> OH2 Actions.
See my link above. I think that is well handled and I would hope this occurs regardless of what happens in this discussion.
This is the sticking point I think. In a year’s time what I’m hearing from the developers on this thread is they don’t want to be forced to rewrite their bindings for no clear improvement or new capability. I hope that my paragraph above will help some see that the mere fact that the same functionality is available in 2.x is an improvement all by itself. But that will not be enough.
If the Compatibility Layer is removed, we need to have a migration path. We need a developer who can migrate the remaining 1.x bindings to 2.x or we need something like David’s proposal to link a 1.9 and 2.x/3/x Event bus. Then those who are still stuck with 1.x version bindings because there is no alternative are not left behind. It’s not pretty and I’m not sure it is any better/simpler than maintaining the compatibility layer. But it could simplify the OH 2 core code while retaining support for legacy add-ons.
I think I agree. I don’t want to leave anyone out, even if one a few people use a given binding. However, a serious question that should be addresses is when do we consider a binding abandoned? What is the over all OH project’s responsibility for abandoned bindings?
I’m not at all saying that 1.x version bindings are abandoned, but I’m certain we have bindings (1.x and 2.x) that the maintainers have lost interest in and no one has stepped up to maintain. When a bug is discovered or a change necessary, what is the responsibility of the OH organization to keep up these abandoned add-ons? These are not rhetorical questions because that is really what we are talking about here. If we remove the Compatibility Layer we are declaring all 1.x bindings as abandoned and no longer supported. As I said above, I think that is premature at a minimum (even with the one year timeline). I’m on the fence as to whether it should ever be considered.
To a large extent yes I think it is. But if you have specific functionalities in mind I can confirm. However, the concepts between the two are very different, as you well know, so from a user’s perspective the two versions may work radically differently from a configuration and usage perspective.
I would hope I can convince some that it would not be pointless work. Hardly a week goes by where I don’t have to deal with new users who are confused by the two radically different setup and configuration models between 1.x and 2.x bindings, or those who don’t know whether it’s better to define their Items in .items files or in PaperUI, or those who install a 1.x binding and can’t figure out how to create Things, and so on. One or two such postings can be ignored. But one or two such postings almost every other day denotes a problem. It may feel like you are doing pointless work, but from the user’s perspective it is far from pointless.
It’s not so much changing the code base for the sake of it. There are not enough maintainers to the core of OH any more. This is an attempt to simplify the baseline to make better use of those few developers, and to avoid situations where there is only one expert on some subsystem (e.g. PaperUI) and that expert leaves the project leaving us with all this code we can’t maintain.
This too is an attempt to solve a real problem and not, IMHO, driven by philosophy or a desire to code for coding’s sake.
But what about a federated setup? I’m intrigued by the idea. It’s sub-optimal but feels like a workable compromise. OH 3 get’s it’s simplified code base, the legacy 1.x bindings are still usable now and into the future, and through the event bus federation we can have “one OH to rule them all.” It may slightly increase the maintenance workload if there are changes to the event bus contract, and as a user it will kind of suck to have to install and configure two OH instances. Everyone’s unhappy, sounds like a good compromise.
I think funding is the solution. As a developer you are really not motivated to work on a binding that you will never use yourself.
So to all users of old bindings: Provide the necessary motivation to the respective binding developer. I mean the work will be available as open source in the end, everyone will benefit. If old infrastructure (ie bindings) have negative impact on the project itself, they need to be left behind when the time has come.
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.
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.
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.
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.
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.
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.
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.)
@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.
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.