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

RalphSester · October 23, 2019, 8:50pm

hi @hilbrand,
thank you,
i have prevented the error by declaring the value-variable as “private transient” so it will not exposed to the superclass….

now i have one step more……the innogy Bridge is now online and i can create Things and can switch them on and off

going to Sleep now…

hilbrand · October 24, 2019, 1:38pm

To get these changes into openHAB there will certainly be needed some cleanup in the newly added code before it will get merged. I don’t know if you (@RalphSester) want to pick this up or maybe @nik70000. If you pr @nik70000 don’t feel comfortable enough I can do this. But than create a pr to my branch on github with your changes. And then there need to be some more volunteers to test the changes as I don’t have innogy.

suntribe · October 24, 2019, 4:55pm

I’ve also set up the dev env, just didn’t had time to report that i did it… anyways, as locally i have 2.4 as my production setup, and there i had issues with this binding, once i installed this, it’s a 2.5. to be honest, the binding worked for me out of the box (except those private variables), but other than that, i didn’t notice any misbehave of the binding… i did see that now the controller has support for CPU and memory reporting, so i’ll try to implement that one… will report back my progress

also, i own SHC1 and 7 RST’s … so that’s what i can test, sort of…

ps.
CPU, memory and Disk usage is actually smth that is supported only by SHCA (version 2)…

Marijn_Oudijk · October 24, 2019, 8:01pm

I have innogy and am willing to test. I’m not a programmer though.
I’m currently running OH 2.5.0.M3 and I didn’t upgrade my Innogy

RalphSester · October 25, 2019, 1:03pm

@suntribe
The Channels CPU, Memory and Disk are only supported by the SHC 2.0 - not SHC 1.0
How did you fix the Problem with the private variables?
Ralph

nik70000 · October 25, 2019, 2:59pm

I have no development environment available yet, but I can volunteer to test if you can provide me with a compiled .jar.
I’ve also started to upload change proposals to your repository in order to support the new Bluetooth devices that were introduced with the SHC2 (but as I cannot test this right away this still might be buggy…). Hope this helps anyway

RalphSester · October 25, 2019, 8:43pm

@nik70000

Thank you for your willingness.
At the moment I try to understand the binding basically, which I succeed so slowly.

I’m currently fixing the following errors:

The values of the RST 1.0 / 1.1 (heating thermostat) are not transmitted correctly. I think I have solved this problem.
Pressing buttons on switches and remote controls will not transmit the counters correctly if you press the same button several times. I think I solved that problem, too.

From the integration of new devices such as Medion , I’m still light years from away …

Currently I’m fighting with the different OpenHAB versions. Thanks to the help of @Hilbrand, my Eclipse version will produce a version that will run under OpenHAB 2.5. This binding does not work under OpenHAB 2.4.

So i am developing an debugging in OH 2.5.

But I also want the binding to run under OpenHAB 2.4, so I have to re-enter all changes in the original binding of Ollie outside of Eclipse and then compile that binding with Maven …

This is awkward - but it works

Last but not least I have to deal with GitHub, because I have not used it so far, so I can provide my changes synonymous reasonable …

So - there is still a lot to do … I try to stay tuned.

Ralph

hilbrand · October 25, 2019, 8:46pm

What kind of error does it give when you deploy on 2.4?

RalphSester · October 25, 2019, 9:21pm

When i try to include the binding created with eclipse in OH 2.4 the following error occurs:

23:18:59.708 [WARN ] [org.apache.felix.fileinstall         ] - Error while starting bundle: file:/D:/OpenHABRoot/OpenHAB2/addons/org.openhab.binding.innogysmarthome-2.5.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.innogysmarthome [301]
  Unresolved requirement: Import-Package: com.google.gson; version="[2.8.0,3.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]

In OpenHAB 2.5 M4 it works correctly.

hilbrand · October 25, 2019, 9:37pm

Ok. That’s what I thought it would be. Add the gson jar file in a lib directory in the binding directory and compile the jar with maven. This should make it work for 2.4.

RalphSester · October 25, 2019, 9:59pm

ok…next error:

23:56:51.008 [ERROR] [.internal.handler.InnogyBridgeHandler] - Error initializing innogy SmartHome client.
java.io.IOException: No innogy accesstoken. Is this thing authorized?
	at org.openhab.binding.innogysmarthome.internal.client.InnogyClient.request(InnogyClient.java:293) ~[303:org.openhab.binding.innogysmarthome:2.5.0.201910252155]
	at org.openhab.binding.innogysmarthome.internal.client.InnogyClient.executeGet(InnogyClient.java:252) ~[303:org.openhab.binding.innogysmarthome:2.5.0.201910252155]
	at org.openhab.binding.innogysmarthome.internal.client.InnogyClient.getStatus(InnogyClient.java:172) ~[303:org.openhab.binding.innogysmarthome:2.5.0.201910252155]
	at org.openhab.binding.innogysmarthome.internal.client.InnogyClient.initialize(InnogyClient.java:142) ~[303:org.openhab.binding.innogysmarthome:2.5.0.201910252155]
	at org.openhab.binding.innogysmarthome.internal.handler.InnogyBridgeHandler$Initializer.run(InnogyBridgeHandler.java:125) [303:org.openhab.binding.innogysmarthome:2.5.0.201910252155]
	at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) [?:?]
	at java.util.concurrent.FutureTask.run(Unknown Source) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [?:?]
	at java.lang.Thread.run(Unknown Source) [?:?]

Could it be the Auth2?

RalphSester · October 26, 2019, 9:22am

Hi @hilbrand,

i must remove the gson-jar-file from the binding again, because when it exists in a lib-directory then the IDE dont’t work because there are Errors with binding resolvement…it will search a ‘sun.misc’ library….

ralph

nik70000 · October 26, 2019, 3:51pm

Ok, thank you for your efforts. Once you have a more or less working version for OH2.5 which supports the API 1.1 of innogy please let me know, I can then try to add the Medion device support.

hilbrand · October 26, 2019, 4:06pm

Something goes wrong with authentication. Either incorrect configuration or it simply doesn’t work. Does this work with the 2.5 version? Because I would think it than would also work with 2.4.

A way to work with the sun.misc is to add it to the -runblacklist in the app.bndrun file. Open that file as source (left down corner when file opened in eclipse) and add similar to other entries. Or just only put in the jar file when compiling for 2.4

suntribe · October 26, 2019, 8:07pm

Actually, i removed them, just like @hilbrand suggested, as i didn’t find them in the original @oliver_kuhl’s code

Btw, what exactly isn’t working with RST’s? I have them, and for me, they are working as expected… Do you have SHC1 or SHC2? I have SHC1 so maybe if you have SHC2, maybe there’s smth broken on it?

RalphSester · October 27, 2019, 7:30am

Yes, there is only a Problem with SHC 2.0.
In my internal Version, i have fixed it. i think, in a few days i am able to share it.

Ralph

hilbrand · October 28, 2019, 11:51am

I’ve created a jar file to test. It contains the API 1.1 changes and some refactoring related to the OAuth2 implementation. It includes some changes made by @nik70000, but no changes from @RalphSester yet. The jar file can be downloaded from: https://github.com/Hilbrand/openhab2-addons/releases/tag/innogy The jar is intended to work with openHAB 2.4 and later. If you find problem please enable debug level and report back here.

RalphSester · October 28, 2019, 12:43pm

Hi Guys,

in the last days, i was working on the binding too.

I have also created a Version for openHAB 2.4.
It contains the changes made by @hilbrand too.

The JAR-File can be downloaded here.

This version contain following fixes:

Support for RST 1.0/1.1 with SHC 2.0 (values are correct submitted to OpenHAB)
Fix for some Errors around pressing buttons (push-trigger-event)
This is not fully fixed because there is an error in the innogy-api - i think.

Have fun!

Ralph

sayhelloto · October 29, 2019, 10:13am

Great work, thank you.

You’re probably aware of this but I want to report it anyway: The first button press on a device fires two push-trigger events. Button presses on the same button after the first press fires correctly only one push-trigger event until you press another button on that device.

RalphSester · October 29, 2019, 10:29am

Thank you for your info. I know about this issue.
The problem is a bug of the innogy-api.
Before my changes several pressing the same button had triggered no Event.
several pressing different buttons had triggered one Event.
with my changes the behaviour is like you described.

at this time, i think its not possible to make the bevaviour correct until innogy doesn’t fix their api-problem.

ralph