Threat every major OH version as a different product. No migration paths at all
That sounds really bad.
As a user I would feel completly f*cked.
When I was replying in all the discussions in the last month or so, my main concern was: make sure you have an upgrade path for your end-users.
I can understand we don’t want to force 2.4 users to upgrade the moment when we bring out 3.0 yet I do think we should offer upgrade paths.
those cost developer hours as stated above
Supporting 3 or more versions costs even more development hours.
Once there is a good upgrade path for a binding in 2.x, people no longer use the older 1.x binding.
That is true. But the concepts changed so radically that no upgrade path can be provided without a lot of development hours (migrations). You also need to differentiate what core developers we have. Personally I’m a pure OH2 developer. And as far as I know (please correct me if I’m wrong) Kai is the only OH1 developer left. And he stated something along the line of that he is not willing to do that in the future anymore.
So the “product” OH1 has no developers left. The question is actually: Can we find other solutions. For insteon there is the mqtt bridge for example. Anel would work with the Http+UDP binding. And so on.
This is where I actually disagree to some extent. There is benefit in consistency is setup and use of bindings. Even if OH 1.x bindings were to become first class citizens again, they will always be different with all the advantages and all the disadvantages of that.
So if someone were to take the Insteon binding and rewrite it as a 2.x version biding with exactly the same capabilities, it would still be an improvement from a usability perspective, particularly usability for new users. It’s not make work.
There is already an issue open on this. I don’t know where it ended up after the great merge.
It’s definitely an approach I can support. My concern is that there is some path for support, not that it necessarily has to remain on OH 3.
Yes but the forum is our only communication medium. Threads like this are actively seeking feedback from the user base.
No matter the outcome of this topic, this is a much requested feature so I hope it happens anyway.
I think going to that extreme would be disruptive, particularly if those older versions cease receiving bug fixes and security updates. If the answer is “well, when we stopped development of OH2 it still had this ugly memory leak that never got fixed, but if you need to use a binding no longer supported on OH3, your only choice is to continue to run that” it isn’t very satisfactory for the users. It means we are telling them that we don’t provide long term support for OH. Every two to three years you will lose functionality if you stick with OH.
I really like this idea for lots of reasons. But does this actually make the job of the OH maintainers easier? It certainly provides a way for users to know and understand what a binding is capable of and why it can’t work on a newer OH core (i.e. OH 3.1.23 supports only API versions 2.5 and above).
Ultimately, I think we are faced with a no-win situation. Any choice leads to harm to the community.
Option
Consequence
Remove support for 1.x bindings entirely
Loss of users and binding maintainers
Run multiple instances of OH
If the older instance is not longer maintained eventually this will break
Keep the compatibility layer
With only one developer who can or will maintain it this will eventually break
Make OH 1.x bindings first class citizens
There is no volunteer to develop this so this path is essentially not an option unless and until someone volunteers
All viable paths lead to the OH 1.x bindings becoming unusable on the new instances of OH. When that happens there will be a loss of users, perhaps binding maintainers as well.
If we break the currently viable options down further we are faced with the following choices:
Do we choose when the 1.x bindings finally break or let it happen naturally?
Do we take on effort for longer term support to the older versions of OH for those who need to keep these 1.x bindings running or just leave them and hope it continues to work?
There are some things that we can do I think to mitigate the user’s long term ability to continue to run older OH instances using Docker or VMs and the like (one of the problems will be continuing to be able to obtain Java 1.8) but even that will be a challenge. I don’t think it will be reasonable to expect in five years that a user will easily be able to continue to run a Java program that depends on a long abandoned JRE. So even the “continue to run older versions of OH and federate” approach only serves to buy us a little bit of time.
I stated this already in another discussion, but as this is on the table here as well: Two instances of OH (one OH2, one OH3) on a single Raspberry Pi is probably not a good idea (only 1GB RAM). As this is a very popular platform, this should be considered…
Please don’t propose to run two Raspberries to resolve this: Double the rules programming and maintenance effort, double the energy costs.
But in the other thread there were also considerations if the OH1-core which runs inside OH2 isn’t loaded it might have not much impact. And that OH3 and and a newer powerful pi might be ready at the same time.
I think this should be mentioned, too. The thread mentioned is this one.
No no no. This is not how it would work. I want to make sure it is really clear how this would work. It’s important to understand this to properly understand what is proposed.
All your Rules, Persistence, Things, UIs, and everything else will live on the OH 3 instance. The ONLY thing that will live on the OH 2 instance are the OH 1.x bindings and the Items bound to them. Those Items will also be represented in the OH 3 instance somehow through the federation.
There is one place to develop Rules. There is one place to develop your UIs/sitemaps. The only thing that will exist in the OH 2 instance is the OH 1.x bindings, the compatibility layer and the federation of the event bus. That federation means that any updates/commands that come from OH 2 get reflected in the same Items in OH 3, and back.
The work/energy used by OH 2 is not duplicated. It is work that your current system has to do already anyway. There is just more RAM required because there will be some overhead in running two separate instances of OH. But it isn’t double the RAM either, because OH 3 will no longer be hosting almost a complete copy of OH 1.x inside it. We won’t know until OH 3 is built how well the two will live side be side on the same RPi. It may work great or it may not. It will largely depend on your specific configuration I suspect. But some users will have to prepare to have to run to RPis to retain support for OH 1.x bindings under OH 3 I suspect. Would you rather not have the ability to run OH 1.x bindings at all?
The work you have to do is only slightly increased as well. You will need to set up the federation and you will have to places to go to to configure bindings. But that is far from doubling your manual work.
With the MQTT 1.x binding, this sort of set is already possible. The MQTT 2 binding doesn’t have direct support for a setup like this, but it is possible to set it up this way. What is being proposed is to make this sort of federated OH configuration part of the core instead of part of the MQTT 1 binding or accomplished through the MQTT 2 binding and Rules.
@rlkoshak Thanks for the explanation. Maybe I was a bit unclear, but that concern you cited referred to the idea of employing two Raspberries for the two OH instances…
Doubling the maintenance - no. Maintenance overhead - yes. But ok, valid point, sort of.
But double energy cost? Come on! Throw your smarthomethings out of the windows very fast and don’t buy any of this stuff if you argue about 8 Euro energycost per year.
The picture is already very close to what I have in my mind. But to be honest: I had a real OH1 instance in mind, not OH2, for OH1 bindings. Mainly to not have all the adapters running and also no discovery and all the other OH2 goodies.
The easiest way is indeed with separate OH1 item files. The item file format for OH3 might change and then we would need to backport that to OH1.
I would actually prefer that approach. I just assumed that you wouldn’t want to make the necessary changes to the 1.x core to support the federation bus. It’s your proposal so I assumed you’d be leading the implementation effort.
Hm. Actually I planned to make it as easy as possible and just use MQTT. OH1.x already has the MQTT eventbus binding. For OH2/3 there is only an equivalent required.
OH1.x binding users would then be required to setup MQTT, but that’s better than not having those bindings, I guess.
Well, if the event bus federation was going to be MQTT anyway then that was always going to be the case, right?
The only reason I can think of for not using the eventbus configuration on the MQTT 1.x binding is you may not like the topic structure or something like that. Unless I’m mistaken, this federation could also be used to federate OH 3 instances too and the existing topic structure might not work as well as, for example Homie, in that use case.
But it is true, I see no reason it couldn’t work with just the MQTT 1.x binding and it’s event bus config as long as you are OK being constrained by how that currently works.
sounds like a valid solution and helps people to use older bindings until they are moved.
I do wonder if this is not harder to maintain then the current compatibility bus.
I find it strange to stick to 1.x openhab and not use 2.x that has evolved more.
(I doubt any work has been done on 1.x in the last 2 years)
Well, OH 1.x is still a solid platform. OH 2 came about because the architecture of OH 1 prevented some new desired features like automatic discovery. Rather than grafting it on to the existing architecture Kai et al opted to start anew. (IIRC from those blog posts years ago).
Since all 2.x bindings will automatically be compatible with OH 3 (I’ve read nothing to say otherwise) it makes sense to run the more light weight OH 1.x core instead of OH 2.x with the OH 1.x compat layer because OH 2.x comes with a whole bunch of stuff that wouldn’t be used if all you had were OH 1.x bindings. OH 1.x would be lighter weight over all in terms of RAM resources I suspect because of that.
OH 2.x has indeed evolved over the years, but only 2.x version bindings can take advantage of any of that evolution. It’s wasted on OH 1.x bindings which have not evolved in the same way.
The only reason I didn’t put OH 1 in the drawing above is because I figured David would be making the changes and David is allergic to OH 1 [said in jest]. I also assumed that since this mechanism would be used to federate OH 3.0 instances too, that modifications to how the MQTT 1 evenbus implementation would be desirable (e.g. Homie).
How many people understand it enough to do so? Is it more than 1?
I’m not throwing stones, here. But the compat layer seems a lot like the xtend component: few if any people at all have enough knowledge to even touch let alone fix them.
Will there still be a sitemap in OH3 ?
If yes a visual designer with drag &drop elements (which could be provided by the Bindings itself e.g. for a huge lamp there would be an drag & drop element which contains an on of switch, a slider for dimming and a option to change color.) for it would be an easy solution for all non tech savvy people.
If we think more about it there also could be a repository of user made elements which where created for a special use case or which just didn’t got covered by elements provided from the Binding
Sorry if there is already a discussion about it then I must have completely missed it…(there are quite a lot of threads open about OH3 right now and it seems everyone is talking about every issue in everyone of those threads.)
I hope what I just wrote makes sense somehow. It is really late here already…
That’s exactly my point why I think that we should get rid of both in the long run - to avoid having bus factor 1 with me being the only one dealing with those parts.
