Is there currently work on "openhab 3"?

[vooodooo1974 (Thomas Fischer)]

Hi,
just out of interest … is there active work on openhab 3? There is little here in the forum and especially in the blog in “no sign of life” to this topic.
Thanks

[Bruce_Osborne]

I understand there is a private GitHub project list gathering requirements. There is talk if dropping the v1 binding compatibility layer that currently prevents IH from using a newer Java version. Somebody is also working on a new UI to replace the PaperUI.

Development discussions tend to happen on GitHub because not all developers use this forum.

[rlkoshak (Rich Koshak)]

All discussions about OH 3 are taking place on GitHub. Personally, given the past threads, I encourage the developers to keep that discussion there and off of the forum. They all devolve into arguments and end up being 1000+ posts long without any resolution and with the same thing said over and over and over again. It’s simply not productive to have those conversations here on the forum.

Whether we like it or not, ultimately it is the developers who dictate the future direction of OH since they are the ones volunteering their time to actually build it. So I’d rather see the conversation kept where the maintainers will actually see it and where it is a bit more controlled and doesn’t run out of hand.

But there is indeed a lot of work being done towards OH 3, especially since the build and dev environment issues appear to be mostly sorted out.

[fex (Felix)]

@rlkoshak

But there is indeed a lot of work being done towards OH 3, especially since the build and dev environment issues appear to be mostly sorted out.

Just being curious:

• any idea when 2.5 might be released?
• will there be a version 2.6, 2.7, …?
• any idea about the 3.0 timetable? As far as I’m aware there is currently no alpha / beta / milestone yet - right?

[Bruce_Osborne]

@fex

any idea when 2.5 might be released?

Kai has said they are targeting the end of this year.

[rlkoshak (Rich Koshak)]

@fex

any idea when 2.5 might be released?

I too have heard the end of the year.

@fex

will there be a version 2.6, 2.7, …?

That probably depends on how quickly OH 3 comes along. When OH 2 came out, there was a long period of “Beta” which also saw the release of updates to OH 1.x, though at that time there was no concept of milestone builds. I don’t know that any decision has been made.

@fex

any idea about the 3.0 timetable? As far as I’m aware there is currently no alpha / beta / milestone yet - right?

They are working on the preliminaries and deciding what big changes to tackle first for an OH 3 release and which to save for later versions. There is start on the new UI that I know of and I know there is a lot of stuff going on with Scripted Automation. I suspect there will be quite some time before we start getting access to an alpha level version.

But keep in mind, the bindings will continue to be developed, fixed, and enhanced during this entire time which may drive the continuation of milestone and point releases even while OH 3 is under development.

[sipvoip (Nathan Stratton)]

Any idea if they plan to keep 1.x compatibility? I still use Insteon and several other bindings that are only 1.x.

[Bruce_Osborne]

The plan is to remove 1.x compatibility in order to permit a newer version of Java. There are possible plans to have3.x communicate with 2.x for v1 bindings support. There were a couple of survey threads trying to track usage of v1 bindings.
OH3 needs to get rid of the Java 8 restriction,

EDIT: poll, not survey.

Poll: Which OH1.x addons do you use?

The OH1.x compatibility layer could potentially be removed in OH3, but even if that does not happen, it would be a good thing to be actively getting these addons migrated to OH2.x. The intent of this poll is to get information into the hands of developers to help in making a decision on which migrations would be most beneficial to the community. I’ve not included persistence, since work is already underway (thank you, @Kai!) to have these migrated after OH2.5, in preparation for OH3. If you us…

[sipvoip (Nathan Stratton)]

Man that is depressing. I guess I am stuck on 2.x

[Bruce_Osborne]

This post should give you hope.

Removal of the OH 1.x Compatibility Layer

The main concept of openHAB is the eventbus. This is true for OH1 as well as OH2. As soon as any command/state ends up on the eventbus everything is fine. How about this proposal: We provide an OH 1.9 core runtime for all the left-behind OH1 addons that connects/syncs via MQTT (for example) with OH 3. I wanted to propose an OH-sync service anyway. I’m willing to write one for a new OH, the one for OH1 would need to write someone else though. That way OH1 bindings work indefinitely (until all …

[rlkoshak (Rich Koshak)]

@Bruce_Osborne

The plan is to remove 1.x compatibility in order to permit a newer version of Java.

I don’t think the compatibility layer is the only thing hold back moving to a later version of OH. And in fact the initial reason it was even brought up was that Kai didn’t want to maintain it any longer and no one has stepped up to take over that work.

I’ve said it elsewhere, if someone wants to volunteer to maintain and update the compatibility layer I’m sure it can be retained and maintained into the future.

Also, removal of the compatibility layer has been talked about. I don’t know that it has actually been decided that it will actually be removed. But it has been suggested that if it is removed, a method to federate an older stripped down OH instance to run those bindings with OH 3 would be created (similar to the zigbee2mqtt approach).

But again, I don’t think any decision on this has actually been made. But the lack of a volunteer to support it may make the decision for us.

@sipvoip

I still use Insteon and several other bindings that are only 1.x.

I believe a 2.x Insteon binding is in work. I’ve not followed the effort but it was one of the bindings that a lot of people became alarmed about when this topic first came up. There is also a lot of effort going on to build 2.x versions of many of those 1.x bindings. In the last few weeks the Network Ups Tools binding got a 2.x version replacement. Given that I don’t see a 3.0 being released before the middle of next year, we have lots of time to get many more replaced with solid 2.x versions as well.

[Bruce_Osborne]

I think this is still the current guidance on OH3.

Directions for openHAB 3

Having the Architecture Council established, let’s go into some initial discussion on the overall directions for our beloved project! A major step has been the re-integration of ESH into openHAB 2. From a technical perspective, this has only happened partially as although we have moved the code to our repos, the Java package names (and thus the API to develop against) is still under org.eclipse.smarthome namespace. Note that we are oblidged to get rid of this in the long term. We therefore have…

[rlkoshak (Rich Koshak)]

@Bruce_Osborne

I think this is still the current guidance on OH3.

That thread is even older than the David Thread you linked to above I think. None of those discussions can be treated as anything more than discussions at this point. I could find no issue or PR created that calls for or implements the removal of the compatibility layer. It is not listed in the OH 3 project board as an open task to be accomplished. When and if a decision is made, it will be discussed and made on github.

[Bruce_Osborne]

@rlkoshak

It is not listed in the OH 3 project board

OK as I previously stated, I believe that project board is private. The Milestone project board is the only public one I am aware of.

[rlkoshak (Rich Koshak)]

It is, but I have access to it and I can say that removal of the compatibility layer is not listed there, yet. So I think it is probably best not to hit the bee’s nest right now and say that it for sure is going away. Because at every mention of that, there is a big swarm of angry users who all buzz in to tell us how it’s a bad idea and how they will all quit and go to HA instead and the like. Let’s wait until the decision has actually been made so we only have to deal with the angry bees once (or not at all if someone decides to volunteer to maintain it).