the good news is that the major issues (missing icons, not able to install UIs) should be fixed with the latest build again.
Maybe time for another milestone release?
2 Likes
And association fixes in zwave.
Sorry for hijacking⊠when was that fix? 
Have quite big issues with associations and esp. differently behaving lifeline Association After every Single Restart of openhab or the Zwave bundle.
between 2.4 and 2.5M1, @chris mentioned it in the zwave binding thread
@kai, I see org.openhab.core.automation. Is it too soon to submit a PR, or should I wait? I have scripted actions working for Jython and Groovy, and a couple fixes.
The merge is completed. You can issue PRs again, I guess. The build process is just not documented yet. It has changed from maven/eclipse-tycho to maven/bnd and it will feel a little (or completely) different in your Java IDE.
2 Likes
I want to applaud all of the outstanding effort that you guys have been putting into reintegrating ESH! Itâs hard to keep up with all of the PRs⊠and thatâs just openhab-core! Thank you! 
15 Likes
Most kudos have to go to @maggu2810 who is doing the major work on openhab-core right now - while I am struggling to get the openhab-addons build to work again 
⊠Iâm far behind my plan, but hope to have a breakthrough soon, so that we can continue with nice new snapshot builds asap!
21 Likes
It took long, but hereâs another important progress update:
We finally have again a snapshot distro build (#1518), which does not contain any ESH bundles anymore, but purely bundles that are built in from the openhab-core repository. If you come across any regressions (and yes, there are some, so donât expect this ready for production), please file bug reports on Github (and donât use this topic for bug reports)!
15 Likes
Hereâs another progress update - we have a governance document!
There are two major parts in it:
- Rules about code maintenance: I hope these will help to allow people to drive evolution of the different openHAB components in a very self-organising and independent way, while having some common patterns and structures across all the repos.
- Introduction of an Architecture Council: For the past 9 years, I have been acting as an BDFL for openHAB. As announced above, I donât want the project to rely on me as a person, but it should eventually be driven by the community. With the Architecture Council, we now have a group of people serving this purpose. These comprise for the start:
- @digitaldan and myself as the officially voted representatives of the openHAB Foundation.
- @ysc as our âUI guruâ, since he is the creator of the most popular openHAB UIs HABPanel and HABot as well as our website.
- @rlkoshak who is the unbeaten champion in answering questions in our forum and who dubs himself rightly as the âopenHAB userâs voiceâ.
- @wborn as a jack-of-all-trades, who understands deep details in the core, fixes Karaf issues in the distro, provides docker images, etcâŠ
With this in place, we should now be good to go for laying the path for openHAB 3 - exiting times!
24 Likes
Just to clarify the settings as this has caused some confusion:
General discussions about ideas etc. should continue to be done in either https://community.openhab.org/c/development (or sub-categories like core/misc/etc.) or - even much better - directly as Github issues in the according issue tracker.
The new Architecture Council category is reserved for AC members and is meant to be mostly for voting on very high-level strategic decisions (such as the one about reducing the number of UIs - how a new UI will look like, which technology to use, what its exact features are is then all up the the maintainers, not the AC). This special category is the equivalent to the Github maintainer team pages, which I only created within the forum, so that it is also visible to non-contributors and because there is no according team in Github.
Wrt to the maintainer team pages: Yes, they are unfortunately only visible to members of the openHAB Github organisation (to which we add every contributor) - this is a limitation of Github, which isnât nice, but something we can imho live with.
1 Like
I am quite a freshman to OH, and the several GUI options are still confusing to me.
Thus, I followed the work of @David_Graeff here Next generation design: A Paper UI replacement proposal - #160 by Kai very carefully and it seems to be promising to have one GUI for all tasks. Now from this discussion I also see @yscâs proposal https://habot-demo.azurewebsites.net/ which seems to be able to do a similar job.
Will this mean that OH3 again starts with two GUIs ( one by @ysc, one by @David_Graeff) that are favorable for different tasks? Or is there a chance that they join their forces towards OH3?
I also read about UI concepts here https://community.openhab.org/t/web-uis-for-openhab-3/67382 and again several viewers for different tasks are on the table. Just a remark: I am an innogy smart home user. In the past, they also had two separate apps for setup and control which never led to elegant solutions. Since two years, these use a new OS and a new, single UI where everything is under one hood. A one-stop-shop without misunderstandings, and it very much convinced me.
Sorry if this is a dumb remark, but it was my first thought when I read these news⊠I hope this isnât the wrong place for such a feedback.
The reason or should I say purpose for the ACâs existence is to decide how to go forward and then start from there on. I begun my design study before the AC has formed and before I knew that ESH will be reintegrated.
There will be only one UI for one purpose, no worries. But I kind of disagree at the moment with Kais believe that a single UI will suffice for management and controlling. I have stated my arguments in the developer section and Iâm waiting for some discussion to happen. Iâm sure there will be a reasonable outcome.
Cheers
1 Like
I have gone through both approaches in my innogy smart home system, and I very much preferred the unified approach. Maybe there should be a way to hide/unhide the management functionality, but it should be one single UI. Maybe with a proper user management and passwords.
Maybe even HABpanel could be replaced by marking favorite controls and arranging them within the same UI?
Clearly, this is only my opinion as a user without deeper architectural understanding
But take it as the impression of someone just starting to understand and work with OH
In any case, thanks for letting us dream 
2 Likes
I understand that this is a long needed step for the project to grow.
One the other hand i believe that it could be a problem if only five people decide what will be done and what will be left behind.
Did you or the AC thought about another instance of more members to vote on things that are then discussed in the AC?
It could be a problem when the AC decides things in a direction that doesnât fit the opinion of current maintainers and could lead to maintainers leaving the project.
As said many times before, no one is getting paid to work on the project and could leave everytime.
Kind regards
Michael
Interesting point.
What if ACâs strategy conflicts with the one of committers?
1 Like
There will be conflicts over time and bad emotions can be avoided if people keep some sort of reasonability. In many cases a long standing discussion turns into emotional battle where ones who care mostly are major proponent and major opponent. Rest of people is detached from discussion unless things gets too loud.
As long as we and Architecture Council rely on technology we can pick âhardâ arguments and not âsoftâ deliberations. If issue is in technology and future changes affects someone plans/interest/contribution an SPI or extension possibility should be left.
By this approach each and everyone can drive specific part of system in own direction. A community can rely on one implementation of extension while conflicted party or parties can stay with their own implementation.
I know this is pretty naive description and will not work with fundamental changes. However most of these changes come from a believe that they are necessary to sort out important issues or ones which are impossible to be solved with current code base. I believe that as long as we keep this in mind we will be able to find a common language.
Cheers,
Ćukasz
I think it depends on the nature of the conflict and the impact of the changes. If a single developer creates a PR that:
- ripples across massive parts of the code base
- makes significant breaking changes to the APIs
- significantly changes the way OH works
- limits, impacts, or contradicts decisions that have already been made
then if the topic comes to the AC they will likely decide against the change. But really, this should never come to the AC in the first place. The maintainers who review the PRs would be the ones that end up deciding. The purpose of the AC is as an enabler and a tie breaker (if I under stand Kaiâs vision correctly). The AC is not going to tell the maintainers how to build the code. The AC is not going to review every PR and accept or reject. But when there is a problem or a disagreement that maintainers cannot resolve themselves, or a discussion on the forum about directions that OH can go that need someone to decide because the participants canât come to a consensus on their own, the AC can be called in to break the impasse.
Now the AC is able to nominate a proposal for consideration and when this happens there will be an open thread created where the whole community can participate. The AC threads are reserved for the AC to deliberate and vote based on the open threads.
If there is a consensus in an open thread, I doubt the AC will vote against it. If there isnât a consensus, then the AC will be the deciders.
5 Likes
@rlkoshak is a master in explaining, so I wonât add anything. Maybe only that the AC will take care of exactly those decisions that I always decide on my own in the past. 99% of decisions with regards to features/development/etc. will continue to be discussed among the maintainers and I am trying to push it even more to this direction - so the really important point of the governance docs is the section about the maintainers and I really hope that all of them will use this freedom to build skilled teams that drive the different components of openHAB forward!
2 Likes
And now back to the original topic, I have another progress update (and likely the last one):
- Over the past days, the major regressions in the distro were fixed and the latest build #1522 seems to be in pretty good shape now! I have deployed it to my production environment today and apart from some very minor things it runs smoothly - I would hence claim that we are back to normal again and that the reintegration of ESH has been completed successfully
. - We have also updated the IDE setup (including its documentation). If you need the IDE for developing add-ons, not much has changed about how it looks and feels, but it is now using the openhab-core artifacts in the target platform and no ESH pieces are left. As a replacement for the ESH IDE, the installer now also offers a âopenHAB Core Developmentâ option - note that you should use a separate IDE installation for this as it uses a different build system (bnd instead of Tycho) and has a few more specialties (like e.g. requiring Xtext code generation). Only those of you that want to work on the core framework itself will require this additional IDE.
As usual: If you come across any bugs or issues, please report them in the according Github issue tracker - thanks!
12 Likes