Innogy on Openhab 2.5 build #1577 throwing exceptions

[J-N-K (Jan N. Klug)]

No. I don‘t use the demo-app. When the osgiify-repo is finished it will probably work out-of-the-Box.

[oliver_kuhl (Ollie)]

Is there a timeline? I hoped to get a first beta out this weekend. But without a working dev env, things get complicated…

Or is there another way on how to continue, maybe without eclipse?

[oliver_kuhl (Ollie)]

@J-N-K, maybe you can push me into the right direction on how I can continue developing the binding.

So here is the situation:
If I just download the latest 2.5.0-snapshot of the distro and compile it in terminal with maven, unzip it and start OH, I can then install the innogy binding via PaperUI from the remote repository and it works fine.
But when I download the latest 2.5.0-snapshot of the addons, compile it again using maven successfully and then place the innogy binding in the addons folder, I get the following unresolved requirement error again:
11:13:34.287 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/Users/oliverkuhl/Downloads/openhab-2.5/addons/org.openhab.binding.innogysmarthome-2.5.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.innogysmarthome [227]
Unresolved requirement: Import-Package: com.google.api.client.auth.oauth2; version="[1.27.0,2.0.0)"

at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]

I don’t understand that because it seems like the 2.5.0-snapshot somehow works, but not when I compile it.

However, that keeps me from getting the API 1.1 version out, that now becomes a bit urgent as innogy will stop the 1.0 API soon…

Any idea on what could be wrong here?

Thanks in advance!

[J-N-K (Jan N. Klug)]

I would add innogysmarthome to the addons.cfg, that is much more reliable in my experience than installing via PaperUI. The don’t copy the newly compiled jar to the addons-directory but to some other directory (e.g. /home/user/.

Get the bundle number of the innogy binding (bundle:list -s | grep -i innogy), the bundle number is in the first column. Thenn update that bundle with bundle:update <number> file:/home/user/<filename>.

This way all dependencies stay installed, which seems to be the problem here.

[oliver_kuhl (Ollie)]

@J-N-K

update that bundle with bundle:update <number> file:/home/user/<filename> .

Thanks! That at least works. I hope I can somehow get the new version to run on 2.5.0 snapshot. Hopefully we soon get a stable development environment again. In my experience as hobbyist developer from the last years of innogy binding development there was a lot trouble with Eclipse and it sometimes took me a week until I had everything working again. This MUST become easier…

[weakfl]

@oliver_kuhl When is the v1.0 API set to be deprecated?

With the current state of the 2.5.0 snapshots the timing couldn’t be worse

[J-N-K (Jan N. Klug)]

What is “the current state of the snapshots”?

[weakfl]

@J-N-K

What is “the current state of the snapshots”?

Looking at the discussion here, I’d say “not ready for a production system”?

It didn’t mean to criticize the dev team or anything, I know there’s a lot going on with the new build system and everything…

[oliver_kuhl (Ollie)]

@weakfl

When is the v1.0 API set to be deprecated?

I don’t know the exact date. But they reached out to me asking about the status and that they plan to shut down 1.0 “in the foreseeable future”.

@weakfl

With the current state of the 2.5.0 snapshots the timing couldn’t be worse

I agree. Especially that the dev environment at least for the innogy binding does not work as expected.

I thought about developing for 2.4.0 again, but there is no Eclipse dev environment anymore as it is based on bnd now. So even there I can just do everything manually with mvn…

[re-vo-lution (Rene Vogel)]

Are there any news?

[oliver_kuhl (Ollie)]

I focused on working on a running 2.4.0 binding based on the new innogy API, see my post:

[innogy] Update to new API 1.1 and new devices tested

Hi, as innogy will soon turn off their API 1.0, I built a new version for API 1.1, which is now in a beta state and ready to test. I would really love to see people with a lot of different devices support by simply testing, if all devices still work. Prerequisites This binding is a 2.4.0 binding and not compatible with current 2.5.0 snapshots. Other brands than innogy like StartSmarthome have been removed. They all now run under the innogy brand. They should automatically switch, but if not,…

I will take a look into 2.5.0 approximately beginning a week or so. I hope things have improved and I get a working dev environment setup…

[pjhaucke (Paul-Joachim Haucke)]

Hi Ollie,

I tried the new binding several times with innogy smarthome controller version 2 and openHAB version 2.4 and got still the error “Offline-Communication_Error”. I generated a valid code several times and after entering in the expected field there is the message “Invalid authentication code. Please generate a new on”. And after a while “Read timed out”.

Best greetings an thank you for your work.

PJH