The Road Ahead - Reintegrating ESH

See above: “We would like to keep openhab-core in a “framework-style” similar to ESH, so that it is possibly to package it in different ways and that it is not only usable by the openHAB distro.”

See above: “please be re-assure, that although I step down as a project lead of ESH, I stay fully committed to openHAB and its community!”


The withdrawal of all full-time developers by Deutsche Telekom, the lack of other companies willing to take responsibility for the core framwork as well as the disengagement of the Eclipse Foundation raises the question whether the openHAB community and the openHAB Foundation can increase their efforts to absorb the loss (at least partly).

I’m still convinced that we need more (not less) full-time development engagement into the project as there are very important tasks which aren’t usually be done by spare-time enthusiasts and that are, in some cases, even now a bottleneck already. Also, I’m aware that many users are willing to fund general core framework development if there would be an attractive and easy way to do it.

Maybe this is also the time to dicuss and rethink how we can, on a long-term basis and with a growing community, setup a core development and maintenance funding that is not necessarily dependent on any major commercial involvement. Maybe our community is big enough to bring something substantial on it’s way, but maybe it’s also still too small. Anyhow, probably it’s better to start these discussions too early than too late.

If I can help in any way with our upcoming organisational/governance challenges, let me know.


That’s why I proposed this:

A lot of communities are doing this nowadays. The entire web-page source code is open source as well btw.
Personally I’d love to work more on OH, but yeah, time and other duties.

The good thing is: The eclipse foundation made sure we are not violating 3rd party rights / patents.
And OSGi made sure that single parts can be swapped out with better variants at any time, so that code smelling is not that big of an issue.


good thing is that we have a TON of testers :smile:

@David_Graeff: Yes, but this is the second step before the first one. Board of directors was not tired to emphasize that the foundation can’t/won’t fund development activities. I think it can be a topic for this year’s general assembly how to proceed in the future. Currently, we’re in a dead end.

1 Like

I’ve written a small tutorial to help developers with updating their open pull request to use the new license:


Thanks for doing this. I was just about to look into it, and you likely saved me a good bit of time!

Another progress update: ALL ESH add-ons have now been merged into - so if you want to work on their code, feel free to again create PRs for those!

The snapshot distro is currently not yet fully working due to some small issues, but that should be solved very soon as well.

So the last big step for the code transfer is the move of the core framework code.


Thanks for the update.
Can we assume that snapshot builds will normally continue to work during this reintegration work, or should we stay away from the snapshot builds until further notice?

I wanted to update to get the latest ZWave Binding updated.

1 Like

As usual, snapshots keep breaking from time to time and everybody will do their best to fix it again. With the ESH integration changes, the likelihood for breaking the distro might be a bit higher than usual - the good news is that the major issues (missing icons, not able to install UIs) should be fixed with the latest build again.


Aaaaaaand the docker image got built again. I was slightly scared something has been terribly broken as the last build was from 23. January :smile:

so safe to use snapshot images again?

It’s never safe to use snapshots. I also see people on the forum recommend these snapshot builds to others without any warning whatsoever. Not everyone is familiar with the terminology of Snapshot and Milestone builds.
Of course every developer does his utmost not to break anything, but Snapshot builds are there to test if indeed nothing broke.
If you want to be safe, then stay on the official stable releases.

Actually that depends on your needs. There were a lot of bug fixes recently for all bindings maintained by me which include the network binding, the hue emulation service and the mqtt binding. The “stable” 2.4 release will cause more issues than the milestone 2.5 build.

I think the majority of people will update their entire openHAB baseline to either a Snapshot or a Milestone release instead of just cherry picking the updated bindings that solve the issue they are experiencing. By doing so they take in many more changes than necessary. Changes that are not as thoroughly tested as the stable releases.

I would welcome a quicker release cycle, but I also understand that that comes with more overhead for the maintainers. The current setup with Snapshot, Milestone, and Stable builds is already a big improvement in my opinion.


Now I am slightly confused.
Is the Milestone image ok , at least with the UI issues that were in the recent snapshots?

The milestone release was build before the big merge started.

Yeah, sometimes I think about what might be a good moment for a milestone release :smirk:.


3 months before the official release :slight_smile:

You have no idea how grateful I am that you did. It has been a life saver helping users, particularly those with MQTT 2.4 problems that were fixed almost immediately after MQTT 2.4 was released.