Is OpenHAB being killed deliberately, or is it just dying by accident?

The combination of “No more support for OH1.x modules” and “Build Environment won’t resolve dependencies” is a pretty solid recipe for a dead project.

One of the advantages of OH is the large list of modules. If half of them go away because no one has written a 2.x version, it will be much less useful.

The people who are trying to pitch in and write 2.x versions are struggling because the build system is still unstable, and spits out complex errors that apparently no one knows how to fix.

An Open Source project that ignores many potential volunteers will not survive.

The build environment must be stabilized, and this frustrating dependency issue must be answered before the few of us still banging our heads against it give up and move on to a system that works.

I’ve been trying to work on a v2 version of the Insteon PLM binding since May, quietly waiting for the development environment to stabilize. The maintainers seem to feel it is stable, but there’s several people stuck with similar dependency problems and no clue how to address them.

I haven’t been able to spend time working on the actual Insteon part of that binding in days. I’ve been struggling with builds, and discovering that they only looked like they were working, or they were entirely broken.

Who can help get past this error? What do I need to do to progress?

5 Likes

Simple: Fix the problems.

Many OH1 bindings are dying due to neglect preventing OH2 from moving to the improvements gained by using a more recent Java version.
Have you reported your build issues on GitHub? Many development issues cannot be discussed in this forum due to the non profit forum owner.

No, development discussions are not restricted by the Foundation.
For better tracking and solving, issues should be opened at github and discussed there.

I remember @Kai or somebody else saying it had to do with the non-profit foundation could provide services but not produce products. The development details were restricted mainly to GitHub to avoid that issue from occurring.

This sort of response is the reason many of the OH1 developers have no desire to work on an OH2 binding. Myself included… :frowning_face:

4 Likes

I already said that long before I was a member of “maintainers”: openHAB is an open source project completely driven by volunteers. Some people (and it reads exactly like that in the OP) seem to expect that others (aka “maintainers”) are obligated to fix bugs, solve problems and provide support for users and other developers immediately when notified. That is not the case.

All maintainers are volunteers like you. I’m pretty sure that everone is doing their best to promote the project and to fix bugs and make steps forward. Ranting about the fact that some problems are not solved and blaming others for not solving those is in no way helping.

Nobody is ignored. That is simply not true. We are trying to work through the open PR as fast as possible and if you see how many contributions by new people are merged every week you can easily see that each line of code is considered valuable and highly appreciated.

Small PR like bug fixes are often more easy to review and therefore faster merged than large PR like bindings with several thousand lines of code. One round of review on a small binding (around 1500 lines additions) takes me at least two hours, depending on the quality of code. 3000 lines is more like six to seven hours. Since I (like most/all of the others) have a full time job for a living and family, this is quite some amount of time. Not a single problem with the build infrastructure has been solved, not a single line of code for fixing bugs in my own bindings or adding new features has been written in that time.

If you encounters a problem, try to fix it. If that is not possible (because you are not a developer or can’t find the correct way to do it): no problem, report it and if someone comes up with a solution immediately that is great. If not, a solution will not pop up from the void if you blame the maintainers for “deliberately destroying the project”.

This is my personal opinion, not the opinion of “maintainers” as a group.

11 Likes

Just for anybody who needs to understand the current situation these links may help

link to message board announcement by Kai that he was stepping down as Eclipse SmartHome project lead in January this year
https://www.eclipse.org/lists/smarthome-dev/msg00195.html

forum topic about recent reintegrating ESH

and also
no spitting, biting, name calling or throwing food
behave folks, lets have a civil discussion

2 Likes

As far as I’m aware, that is a mere proposal, not a decision at this point. And even if that does become a decision, I believe the solution is not to just completely drop those bindings but to provide a way to federate OH instances so you can continue to run a stripped down OH 2 (or OH 1) instance that supports these older bindings while you need them. But like I said, it’s just a proposal, not a done decision.

The number of OH 2 bindings far outnumbers 1.x bindings. I think “half” is a bit exaggerated. But there are a number of important bindings like Insteon that have wide use but do not yet have a 2.x version. So I’m not saying that the loss of support of these bindings is no big deal. It is a big deal and I appreciate your efforts and the efforts of everyone who is working on rebuilding 1.x version bindings.

I assume that you are following and hopefully contributing to the Issue(s) that address the error you are seeing? If there is no issue, have you filed one? From what I’ve seen by scanning through the issues a week or so ago the core developers working on the build system have been reasonably active and helpful in trying to get developers up and running and addressing the problems they encounter.

It was probably me. I had a missunderstanding based on something someone else said and hmerk corrected me. It’s not that development type discussions can’t be had here on the forum. It’s that in large part they are pointless as the audience for such discussion (i.e. the developers) aren’t reading the forum. You need to go to where the developer are if you want to be heard by them.

2 Likes

I enjoyed following the developer discussions here leading up to the M2 release.I expect the GitHub issues are likely spread around the various issues & PRs.

The OP needs to make their voice heard in the OH1 poll thread. All I know is this is much more stable & civil than the real major issues over on Home Assistant. I am glad I made the move even though I currently do not have the time I would wish to work in my own things…

1 Like

Bruce, I love following the development of this software, it is fascinating to watch. A few tips, watch for links in threads here in this forum to git issues. Often the developers leave them for further explanation of what they are stating in the thread. Check out OpenHAB github read thru the issues list and play along. Some of the developer do use this forum for discussions about development and finally

Thank you Rich for clarifying that to Bruce because a lot of discussion about development goes on here and always has. There is no problems discussing development here on this forum. Just that, if you find an issue and it needs attention, you have to post an issue on git in case the developer isn’t watching the discussion on this forum.
Folks shouldn’t worry if their problem is not really a bug or they are not using the software correctly before creating an issue on git. The developer whose maintaining the software has the ability to immediately close issues which are not actual problems or can be merged into a outstanding issue
Everyone must use the system for it to work. If your issue is something kind of dumb, because you didn’t understand, maybe the developer will realize his documentation needs fixed.

And as always, thank you to everyone who does contribute in the way they can. You Bruce for pitching in here on the forum supporting, Rich as always, Jan for your great work, nice job with new snmp binding, Lou for your efforts getting insteon binding ported

And just for perspective, Chris, the developer of the terrific zwave and zigbee binding struggled for weeks getting a development environment set up so he could continue work on his binding. He is one of our most experienced binding developers. We had a hiccup. We are almost past it.

We all need to double down, pitch in, roll up you sleeves and get back at it. OpenHAB will never die so long as we all keep working at it.

Oh and edit to add:
Any of you developers need help with your documentation, I am 1st language english with a git account and willing to help, just message me!

4 Likes

Thanks for clarifying. I have no knowledge of German law for non-profits nut I believe @digitaldan said the foundation could not sell cloud access like HA does due to legal restrictions.
@rlkoshak has been here buch longer than I and I have learned to respect his helpfulness. insights, and expertise.
I may look at GitHub as I find time but work has me pretty slammed right now with the start of a college semester and dealing with last minute issues & requests.

1 Like

As have we all!!!
Thanks Rich

… now back to your regularly scheduled food fight

1 Like

That is true. The foundation is a certain type of non-profit and it would, if I understated correctly, need to reincorporate to sell products or services.

2 Likes

Correct, but this way apart from development discussions

2 Likes

As a développer, I follow this forum much closer than Github. But to tell the truth I do not take really care until an issue is filed in Github because many are solved by the gentle people taking care here. I am sure not being the only one developper silently reading the forum everyday.

7 Likes

I will say that one of the frustrating parts for me lately has been that I’ve (for the first time in a long time, really) been learning new things, and excited to be making progress on a chunk of code. Not only was I a hair’s breadth away from having Insteon messages accepted and updating state inside OpenHAB, but I can see several really intriguing potential improvements that might give some plausible automatic device detection and no longer require some of the extra manual steps that the Insteon 1.x binding did.

Then I’ve spent all my spare time for weeks spinning my wheels on a mysterious build problem. It’s been hugely frustrating, and that frustration led to this post.

I will also unashamedly admit to having framed the concern in a slightly exaggerated way with a deliberately provocative title to try and get people to read the message and reply. That part seems to have worked.

J-N-K: I’m very glad you chose to write a second post with more explanation in it, because your first was… unpleasant.

I do understand your point about everyone all being volunteers, and I do respect that. I don’t expect immediate response either - I’ve been struggling with this issue for a couple of weeks, and searching the forums shows similar errors happening somewhat regularly since at least May. None of those forum threads had an applicable answer, although some got solved. Others simply never got any response at all.

A few days ago, one of the other maintainers linked to the github thread and said, “… there are non-reproducible problems with dependency resolution through m2e - as you can see from the comments on openhab/openhab-distro#927, they occur out of nothing and nobody really knows how to get rid off them :-(.” This suggested to me that nobody knew what was going on, and no one knows how to fix it. That’s a really bad place to be, and it must be addressed.

This was not intended to be “help me now!!!1!!” but to try and get a response to my perception that this is a recurring issue with no known solution, that no one is getting responses for. And, from the unanswered threads on the forums, a serious problem that is going to prevent development of new bindings.

Andrew_Rowe: Thanks for linking in those very good threads with the history of how we got to be here. That’s very helpful!

rlkoshak: Thanks for pointing out some details I had missed. I had heard the suggestion of federating the two systems, but it was nothing like an accepted or developed proposal. Hearing there is a way to keep using the older bindings is positive and means a little less pressure to replace them all, but doesn’t make developing 2.x bindings any easier at the moment.

I’m also really surprised at the 1.x poll that there’s a dozen or less people using Insteon. Considering how well it works (really well!) and that it’s a stable and established product, I expected a lot more people to be using it. To be honest, this suggests to me that the forum doesn’t reach a huge number of users who are just happily using the system without problems, and that any decisions we make based on the forum users are likely to be skewed to “power users” and possibly early adopters. This is a common problem.

This is definitely true, and I haven’t been as good about it as I could. I have not found it easy to talk to the developers on github, and they are often working at a depth of understanding I can’t follow. Still, it’s where more of the right people are, but getting involved there seems to have a big learning curve that the forums lack.

My perception is colored by the forums, and that seems to suggest that there’s a lot of uncertainty and little resolution in several important issues.

Others have said some or parts of this, but not as a new thread with a scary title. I felt it needed to be read and discussed.

Perhaps, but it is leagues better than some of the alternatives I have tried.

I can not understand who you can blame if everybody is using Insteon binding while no one is willing to take care of porting its open sources code to V2. I’m using GCE equipments, using v1 of the binding since years. I knew I would have, at one time, to dive in it if I wanted to be sure it would work on V2, and I think maybe we are two interested users…but I dd it. Sorry for you I have no Insteon équipements.

2 Likes

Hi all!

Just wanted to share my two cents on the subject since I’m just doing something similar, that is porting Nikobus v1 binding to v2. I’m not a Java developer and last time I run Eclipse it was around two years ago when I implemented my first OH binding and all I can say is that following available OH documentation and a google search now and than did enable me to come to a finish line and haven’t experienced any issue what-so-ever. More to that, I can say the documentation improved significantly so kudus to all the people out there contributing and making it happen.

All I can say is thanks and keep up the good work.

4 Likes