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

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

Can someone elaborate on the modification of the development environment? I was aware ESH had to be moved back into the OH core. I thought the problems with the development environment stemmed from the move. I was unaware a new system was introduced
I knew the build system had been revamped to make milestone builds easier but also thought this did not effect the development environment

The move of ESH back into the OH repository is separate to the change in the build environment.

Someone posted a video on the Github issue recently from one of the SmartHome days where there was a discussion about it - it’s interesting to watch.

The argument is that this was going to be better at managing dependencies, faster to run, and more modern. My experience, when it works at all, is that it’s a lot slower, and management of dependencies so far has been a major mess. Kai argues in the video to keep the original system (kudos to Kai) but I guess was unfortunately outvoted (somewhere!) and the system was changed. I would fully agree with Kai’s arguments, and in effect I would say that his concerns have come to fruition.

Thanks Chris for replying and I have watched that video and saw Kai arguing to keep the working system. I thought that video was about the build system. If I am correct, then what you are saying is that this change to the build system is effecting your development environment.
In your opinion, would a roll back to the old system even be possible and would it allow you to immediately go back to a working development environment?

It is - the build system and the development environment are “the same”. It comes down to the structure of the projects and the tools used. The main change being the move away from the “in-built” Eclipse PDE system which worked well with Eclipse, to the bnd centric system which relies on plugins in Eclipse…

I did suggest it a month or so back, and it received a less negative response than I’d expected, but practically speaking it’s a painful thing to do. The issue of course is the status quo is not something that works so far and this needs to change soon - so the question is still how long to wait before making painful decisions.

1 Like

OK, thanks for explaining this to me. I knew about the new build system, I thought I remembered it made the builds a lot more automated and easier to run. I was unaware this is what made your development environment so unuseabe. I’m following the discussion on the git thread

So, the subject of the thread comes back around
Are the problems one of our most experienced and valuable contributors is having being ignored deliberately or by accident?

Yes I had just started working on the emby binding right when all the word on m2 and ESH reintegration was happening so I held off work until that was done because i knew that any pull request for a new binding was going to be pointless anyways. So the only place that it does exist right now is in my repo.

After spending 3+ weeks to get a system up and running and having my current hardware fail to be recognized or integrated I have to move to a system that just works.

I really wanted to use OH but the issue of having multiple interfaces that do not talk to each other is an issue for me. I’m not really a programmer but do understand how to edit the code and what I am looking at when I do.

I have since setup an Home Assistant install on my Raspberry Pi and within 4 days have everything working with a nice interface to control it.

There seems to be a lot of frustration of people when I look at the forms for OH and a lot of issues deciding what direction the project should take. This is a concern that I see for me about continuing with OH at this time. If in the future things level out and there is a common direction then I might be tempted to use OH. But for now I am going to go to the Home Assistant path.

I am thinking about getting another Raspberry Pi and installed OH on it just to play with but not use as stable functioning system to control my home.

It’s really a-shame that the OH project is in such turmoil. I will continue to read the posts to see if this gets sorted out.

All comments are welcome and this is not meant to be negative but it’s just the way I am interpreting what is going on. Being interested in home automation for many years but just now having the time and resources to invest in it I feel that others wanting to get into home automation might be also be inclined to move on to some other platforms as I am doing.

Dennis

1 Like

This sounds more like you are trying to set up an OH installation and integrate hardware, rather than setting up a development environment for developing core functionality / bindings / addons which was discussed here.

If so it’s better to start a new topic with your problem and your are more likely to get some help.

Regards S

3 Likes

Hi and yes I realize this is a development thread. My comments were kinda directed to this as OH seems difficult to implement and I wanted the developers to understand that if someone like me wants to use OH then I would recommend better UI integration at least between the ones OH offers.

Thanks,

Dennis

FYI, if you feel yourself brave enough and exhausted already with automatic IDE setup you can try following this little tutorial of getting openHAB working from IntelliJ: Setting up development environment with IntelliJ any feedback on this is welcome.

Cheers,
Łukasz