the one who works makes mistakes… you guys are great. just keep up the great work. hopefully i might join you as well but as i said earlier in this thread, i’m a dev, but never worked with java…
Thanks! Will check it out when I am back.
Would both of you assist me in refactoring to the OpenHAB internal http-Client? I would provide test-jars and you report if it works?
Sure, you can count on my assistance…
Sure, as soon as I am back.
Hey @J-N-K ,
maybe you can help me. I am working on the new binding version with API 1.1 support, which is a bigger rewrite.
I tried to do a fresh setup of Eclipse with based on the current docs and added the innogy SmartHome binding from the addons repository to eclipse as described. I opened app.bndrun, added org.openhab.binding.innogysmarthome to the “Run Requirements” and hit “Resolve”. That throws 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.201906041917]
⇒ 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.transform.jinja version=2.5.0.201906041608]
⇒ osgi.wiring.package: (&(osgi.wiring.package=com.hubspot.jinjava))
[org.apache.aries.jpa.container version=2.7.0]
⇒ osgi.service: (objectClass=javax.persistence.spi.PersistenceProvider)
[org.openhab.transform.bin2json version=2.5.0.201906041607]
⇒ osgi.wiring.package: (&(osgi.wiring.package=com.igormaznitsa.jbbp))
[org.openhab.binding.harmonyhub version=2.5.0.201906041549]
⇒ osgi.wiring.package: (&(osgi.wiring.package=com.digitaldan.harmony)(&(version>=1.1.0)(!(version>=2.0.0))))
[org.openhab.core.test version=2.5.0.201906040302]
⇒ osgi.wiring.package: (&(osgi.wiring.package=org.junit))
[org.openhab.binding.smartmeter version=2.5.0.201906041601]
⇒ osgi.wiring.package: (&(osgi.wiring.package=io.reactivex)(&(version>=2.2.0)(!(version>=3.0.0))))
Seems like com.google.api.client.auth.oauth2 is missing. Can you help?
Thx Ollie
There is one non-OSGi-bundle in the dependencies which means it cannot be resolved automatically (not the oauth but the gson bundle). Not sure if that is related.
But if you do a bigger rewrite you should consider to remove the google http client and use our own implementation which supports oauth2, too.
Oh no thanks! That would make it even bigger and I am always struggling to find the time to get the new version ready…
However, this is just the current checked-out “vanilla” version of innogy as in the OH repo. With none of my updates. Any idea on how to work with bnd and those non-OSGi dependencies?
No. I don‘t use the demo-app. When the osgiify-repo is finished it will probably work out-of-the-Box.
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?
@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!
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.
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…
@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
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…
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”.
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…
Are there any news?
I focused on working on a running 2.4.0 binding based on the new innogy API, see my post:
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…
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