Things and channels. Really. In OH1 you talked to the eventbus directly. That’s not “allowed” anymore. You now model in things and channels. That was a breaking change.
And that’s why OH1 bindings can not be ported. They have to be rewritten. Remodeled. Which most of the time for those rather ancient technologies covered by those bindings is wasted developer hours. The combat layer is just pushing messages between the two different eventbuses.
Perhaps I wasn’t clear in my post. v1 Bindings had to be changed to work in v2 Core (minor, but changes were needed). v1 Bindings again need to be changed (or potentially re-written) to work in the forth-coming v3 Core.
v1 concepts are a subset of v2 concepts, so one was able to fit “inside” the other, but something else triggered the need to make actual code-changes to each (v1) Binding.
Something is missing in the way that Bindings interact with the Core that’s causing this. The burden of this missing entity is born by Binding authors - they have to change their code, then change again, or potentially rewrite it.
I’ve seen this in another HA environment.
In that world, the changes to their operating core/engine were frequent enough, and the Core <-> Binding contract loose enough, that the authors eventually stopped maintaining their code… and many Bindings stopped working.
I think it pays to take some time to understand the root cause of the incompatabilities and see if those can be fundamentally addressed to avoid the same issue re-occurring (either in v3, v4 or beyond).
If folks are rewriting to get net-new functionality, that makes sense. If they’re rewriting to get the same functionality, something seems amiss.
The notion of federating the (OpenHAB) Busses might be a way to do that, if the Bus has a solid, versioned, contract.
Not sure this is the place to discuss specific OH1 bindings - but will this affect the CalDAV bindings? Quite an essential functionality, but also still OH1. Noteworthy, they are installed via PaperUI…
I did some counting in the openHAB1 repository. Because when talking about changing things it’s good to know what we’re talking about. As you can see it’s a rather large number and simply migrating them with OH is a massive amount of work.
Exactly. From a binding developer point of view there are no gains to move to OH2 unless new functionality is added to the binding. For example discovery. If it works, it works. I think it would be a big middle finger signal to all these addon developers to just drop support. But some stricter policies on support, having migration paths/support for both users and developers, and better separation in the core between OH1/OH2 would help moving things along.
Number of addons in the feature file (These have (probably) no OH2 version)
Number of addons in the legacy feature (These are addons that have an OH2 version):
Number of projects in the repository (excluding test) Some of them are not part of a feature file and can’t be installed
There seems to be a lot of “religion” about what openHAB is “allowed” or “should” do, and this religion focuses a lot on excommunicating the original strengths at the expense of existing users. It’s a huge discouragement to encounter this mindset and the indifference it represents to the existing user base. Introducing new binding interfaces to appease this ill considered viewpoint is unwise in my opinion. Leave the 1.x binding model alone, leave all that code in place, don’t waste precious developer resources re-inventing things that religious zealotry eliminated, and above all don’t introduce breaking changes or loss of functionality just because it doesn’t suit your aesthetic impulses. Or, in the alternative, watch this great project get quieter and quieter as users get the message that their concerns aren’t near the top of the priority list.
I will tell a story. I resisted OH2 for a long time, but not because of the work involved in transition. I knew that it was actually a good opportunity to improve my system, restructuring Items and rewriting rules in the light of experience, etc.
My blocker was that a couple of simple OH1 features didn’t get across to OH2. One of them still isn’t.
That’s the point of the story, really, but you may be curious, so off-topic …
Missing feature 1 - a passworded UI login. Yes I know there is reams of discussion about how insecure it was, how to implement a proper system alongside, or use myOpenhab (despite many OH users rejecting cloud solutions), etc.
But I wanted to keep an existing simple feature, not get another sub-system to maintain. It’s the psychology, not the tech.
Persistence services is an important topic: Clearly, we do not want to lose them, because we would be left without any persistence.
My plan was to actually change the persistence API back from ESH to openHAB namespace and then move ALL persistence add-ons from openhab1-addons to openhab2-addons as they will require very little adaption to then work without the compat layer.
Wrt actions: I’d hope for the same. Hopefully the NGRE will be productive for openHAB 3, hence we will need some adaptions for those actions anyhow. Ideally, the existing actions should be considered in the scope of the NGRE migration (fyi @5iver).
Also note that we are talking about a timeline of 1 year in the future - whatever 1.x binding is still in heavy use should be ported to 2.x by then.
The goal of this all is from my pov simplification of the code base in order to improve maintainability, reliability and overall complexity. The group of people that understand those inner workings and the compat layer specifically is very small and it should therefore be in the interest of ALL users to avoid such structural bottlenecks in the project’s code base.
the time for those rather ancient technologies covered by those bindings is wasted developer hours.
I have just build a brand new house that depends on +20 anel huts.
a binding that still is in 1.x
these anel huts controls half of my house.
I have no idea how many people also use it.
Yet I would not call it ancient technologies . anel itself releases new versions of hut and are used inside industries so felt table enough for having my house depend on it.
I have no idea why the original developer did not port it.
So the standard would be heavy use, not any use? And so some users will lose integration ability unless they themselves know how to write bindings and have no forward migration path? And the loss of functionality in 2.x bindings from 1.x bindings has been resolved? The usability of openHAB in addressing certain classes of problem is much better with the 1.x binding model, but this approach will either be eliminated altogether or re-invented in yet a new binding model? I just don’t see any path forward with abandoning the 1.x codebase that doesn’t simply create either loss of functionality or lots of pointless new work!
Like I said, this religion of ditching old code is a really strange use of resources, if the goal is to create ever greater numbers of happy users, as opposed to just shaking things up because coders love to code.
@watou Nobody is stopping you from using OH 1.9. Newer features are not possible with the former item-only based model, please accept that. You will miss all the good parts like Profiles, Discovery, Multi-item-one-channel linking etc, new rule engine etc.
@yves Are you willing to financially fund an Anel 2 binding?
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.