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.
Addons
Number of addons in the feature file (These have (probably) no OH2 version)
addon
#
action
12
binding
65
persistence
16
other
4
Legacy
Number of addons in the legacy feature (These are addons that have an OH2 version):
addon
#
action
2
binding
26
Project
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.
Someone said, all persitence services are OH1, but they are not affected from the removing of the OH1 compatibility layer.
I still use db4o-persistence and there is no new OH2 binding for this, so i still use the old jar-file from OH1.8.3.
Would db4o still work if the compatibility layer would be removed in a future OH3 version?
(I know, there are many other databases out there, but db4o is just simple without the need of installing a separate database. There are only text-files, which store the data.)
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?
Or 2.x - it will still be around in 10 years and the best choice to use if you want a stable setup.
Nobody is helped if the compatibility layer is kept indefinitely, but accidentially breaks through some new feature and nobody ever fixes it again. Or are you willing to maintain this code, @watou?
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.
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.
