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

One thing I’d like to also mention, when the discussion of removing the V1 compat layer originally came up back at the beginning of the year, Kai stated that he had written it back in the day and no one has volunteered to maintain it and he’d prefer to put his own efforts into doing things to move OpenHAB forward. I’m paraphrasing here, check the history lessons in my earlier posts but anyhow, he also wanted to encourage people to move to the new architecture but… if anyone felt like stepping up to maintain the V1 compatibility layer, I don’t think he’d try to stop them and it is open source anyhow so…

I’m not suggesting you do it Lou… I’m just saying

and dying???.. we just got a brand new iOS app by a brandy new developer. We just got a brandy new Alexa app… by a brand new developer. We have two very nice new UIs ready to go to replace the still born paper ui. We have Sebastian developing HabApp, Scott cranking on the JSR223/jython stuff…
the pipeline is up and running again Thanks Patrick! and milestones are rolling out

Click bait thread titles will get you the replies you were hoping for but it will not win any friends.
The development environment had to wait on the reintegration. The reintegration was not optional, it would have been the death knell for OpenHAB. People busted their rears to make it happen.
Don’t talk bad about our beloved OpenHAB :wink:
smiley added so we all know its all in good fun

2 Likes

Lou this thread you linked to is actually Markus fixing the IDE a few weeks ago

If this suggested to you that nobody knew what was going on, then you had the wrong impression and/or didn’t read the whole thread (hey we all have lives) the reintegration was primarily finished and getting a running IDE could have some time spent on it. Markus set it up over and over until it worked and that is how such things get fixed

While I don’t disagree with the general flavour of your post, I think we are still a “little” way from having something that is working (working meaning stable and reliable). I’ve spent weeks struggling with getting the IDE working bit it’s still extremely fragile at best. I’ve raised a number of issues a month or more ago and as far as I know none have been addressed and currently I’m still in a situation where I cannot really develop the bindings I maintain.

It’s not a good time of year in many ways - people have holidays so probably aren’t focused on resolving this, and that’s totally fair which is why I’ve not pushed this over the past few weeks. I do share some concern from @Laufeyjarson as a number of people I deal with are definitely put off by the instability that has been going on in OH for probably 6 months now.

I’m also far from convinced that there’s a good explanation or understanding of what is happening. As I mentioned above, I raised a number of issues within the referenced Github issue that have no explanation as yet. The stated advantages for changing the environment have certainly not yet come to fruition as the system is slower and less able to manage dependencies than the old system (these being two of the main reasons to change). I’m not saying these won’t be fixed, or that it’s maybe only me having the issue, but at this time it’s not happening, and the people that I saw arguing to make the change don’t seem to be supporting this which is a little disappointing.

9 Likes

This is also the thread several people were asked to post to with their own IDE issues. Resolutions were not forthcoming. Markus clearly knew what he was doing and was reporting progress.

Would new issues have been better choices?

No, Chris said that was the thread so…

@Laufeyarson
I admire your patience in responding again and again to the “great hints” and suggestions here in this forum, which should help you to solve the annoying problem with the dependencies.

It has probably not yet been understood that the stupid decision to create an untested new development environment for Eclipse, coupled with a poorly prepared IDE migration, surprised the developers like me and now discourages them.
All we ask for is a working and stable IDE (very quickly) and a serious opportunity to ask questions and describe problems for which we get competent answers helping to solve our problems. Unfortunately this is not the case at the moment.

For my part, I am similarly frustrated as you are - but less patient - and have given up taking care of these incomprehensible and above all undocumented error messages about unresolved dependencies. It’s said that improvements have already been made whatsoever - all stupid, nothing is fixed.

I think as long as we keep researching this f* solution with no prospect of a quick fix, this great openhab project will die.

1 Like

As a long time openHAB user I am currently looking for other home automation software solutions :joy:
Meanwhile it is almost not possible to support other users in this forum (on a user level, as I am not a programmer) because of all those changes going on here.

Rather than die roll it back? A lot of time wasted for sure. But better to have something that works. Maybe redo this in a more controlled fashion.

stupid decision … roll it back ?

So far as I understand it, something had to happen for essentially contractual/commercial reasons.
I’m sure it has all been much more painful than anyone imagined,

Why?

Really?

I think you are mixing up a couple of things aren’t you -:

  1. The moving of ESH back into OH core - this “had” to happen.
  2. The modification of the development environment - this did NOT have to happen and it is this that is currently causing the problems. This was meant to be an improvement in speed and usability - currently this is very far from reality and this should have been done when there was a major revision (ie OH3.0) so that the current release system could be maintained.
2 Likes

Referring to earlier posts, not my thoughts. Sorry for not being clear.

Okay, thankyou for clarification. I did think both facets were all part of the same thing.

1 Like

I hope we can get a running IDE soon. I personally am a hobbyist spare time developer developing the innogy SmartHome binding and unfortunately not an experienced Java developer with experience of complex development environments.
So for me, I just can’t get things up and running even after days of googling and fiddling around. I am simply helpless. As soon as the IDE is running stable again, I can’t wait to get the innogy binding ready for 2.5, which is important as innogy will switch the API soon and things won’t work anymore. So fingers crossed…

What are your problems with the IDE?

1 Like

I installed eclipse about 2 weeks ago. It starts, I can resolve the default app.bndrun configuration and startup paperui. As soon as I add the innogy binding, the resolving fails with the following error:

Resolution failed. Capabilities satisfying the following requirements could not be found:
[<<INITIAL>>]
  ⇒ osgi.identity: (osgi.identity=org.openhab.binding.innogysmarthome)
      ⇒ [org.openhab.binding.innogysmarthome version=2.5.0.201908302028]
          ⇒ osgi.wiring.package: (&(osgi.wiring.package=com.google.api.client.auth.oauth2)(&(version>=1.27.0)(!(version>=2.0.0))))
[net.minidev.accessors-smart version=1.2.0]
  ⇒ osgi.wiring.package: (&(osgi.wiring.package=org.objectweb.asm)(&(version>=5.0.0)(!(version>=6.0.0))))
[org.openhab.core.test version=2.5.0.201908280303]
  ⇒ osgi.wiring.package: (&(osgi.wiring.package=org.junit))
[org.apache.aries.jpa.container version=2.7.0]
  ⇒ osgi.service: (objectClass=javax.persistence.spi.PersistenceProvider)
[org.openhab.transform.bin2json version=2.5.0.201908282128]
  ⇒ osgi.wiring.package: (&(osgi.wiring.package=com.igormaznitsa.jbbp)(&(version>=1.4.0)(!(version>=2.0.0))))
[org.openhab.binding.harmonyhub version=2.5.0.201908282104]
  ⇒ osgi.wiring.package: (&(osgi.wiring.package=com.digitaldan.harmony)(&(version>=1.1.0)(!(version>=2.0.0))))
[org.openhab.binding.smartmeter version=2.5.0.201908282119]
  ⇒ osgi.wiring.package: (&(osgi.wiring.package=io.reactivex)(&(version>=2.2.0)(!(version>=3.0.0))))
[org.openhab.core.io.transport.serial.javacomm version=2.5.0.201908280324]
  ⇒ osgi.wiring.package: (&(osgi.wiring.package=javax.comm))
[org.openhab.transform.jinja version=2.5.0.201908282128]
  ⇒ osgi.wiring.package: (&(osgi.wiring.package=com.hubspot.jinjava)(&(version>=2.5.0)(!(version>=3.0.0))))

There were no dependency problems in the old environment. Sounds like com.google.api.client.auth.oauth2 now has issues. I don’t understand how it works now and could not find a solution. I tried several changes within the pom.xml without success.

Is the full code available somewhere?

The 2.4 updated binding is not on git yet, but doesn’t matter at first. If the current HEAD with innogy binding would simply work in the IDE, I can do the rework of the binding. @hilbrand offered help as well and plans to take a look at it next week.

So thank both of you very much to help me getting 2.5 binding development set up! :slight_smile:

Wow I didn’t know things had gotten this bad. I had been waiting to do work on both of my binding (Emby and Konnected) once 2.5 m2 came out as I thought that would mean that the dev env would have stabilized by then but I guess from what I am reading that is a big no as of right now?

You should try. Maybe your bindings work.

1 Like

No it’s not that bad. There is some work to improve working with additional dependencies. But the konnected binding has none so should work without much problems. I couldn’t find the emby binding other than in your repo and that seems also ok. You even don’t the gson provided dependency.

Well, respectfully, I disagree. I’ve spent another 6 hours today trying to get a development environment working, and I’m very nearly at the point I give up! This has been going on for months now.

Sorry for the frustration, but I’ve wasted numerous days trying to get a stable environment over the past few months!

2 Likes