Please test the jar file provided by me. I’ve added the changed made by Ralph and it contain some additional changes in starting the handler for a thing, related to the changes made with OAuth2 implementation. This codebase is intended to be base for the updated pr. So it’s essential that code should work too. https://github.com/Hilbrand/openhab2-addons/releases/tag/innogy
Hi,
I have started to test your R2.5 binding. I have the following problem that the bridge (V2) disconnects often. See log details below:
2019-10-30 20:05:33.020 [hingStatusInfoChangedEvent] - 'innogysmarthome:bridge:7a5d7d99' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Disconnected
2019-10-30 20:06:04.064 [hingStatusInfoChangedEvent] - 'innogysmarthome:bridge:7a5d7d99' changed from OFFLINE (COMMUNICATION_ERROR): Disconnected to ONLINE
This was not the case with Ralphs 2.4 binding.
best regards René
Can you run with trace log level? You can send log information via direct message if you prefer. And what version did you test?
Hi,
I have returned to the R2.4 version. I try to test this with TRACE Log level in the next days. My OH2 version is openHAB 2.5.0 Build #1705.
best regards René
Started testing on 2.5M4. My brigde v1 is discovered immediatly, but the bridge v2 in the same network is not found and does not show up in the PaperUI inbox. Will send log separately
Hi,
following error message appears when the binding disconnects:
2019-11-02 16:06:31.675 [INFO ] [gysmarthome.internal.InnogyWebSocket] - Connection to innogy Webservice was closed abnormally (code: 1006). Reason: NullPointerException
best regards René
Hi @rene54321 That looks like a bug. I would guess some data is not correctly handled. I’ve updated the binding to better catch this kind of error. The new binding doesn’t fix the issue, but should better report were the problem comes from. Can you run with this new version (02/11/2019 21:00) and report the logging. Log with debug level. If you prefer you can send a detailed log via direct message to me.
Just a general update. The version to test has timestamp in binding (04/11/2019 21:00), should work with openHAB 2.4.) and can be found here: https://github.com/Hilbrand/openhab2-addons/releases/tag/innogy Please test this version and report any problems. So I can complete work on this binding and get it merged to be included in the next release of openHAB.
Hi,
thanks for the updated version. Seems to work now.
best regards René
I tried it yesterday with 2.4 and could not establish communication.
I am back to the one from Ralph org.openhab.binding.innogysmarthome-2.4.0-ralph-20191026-2.jar
I am running out of time today. I will provide trace files on Friday latest.
Can somone explain me what the story about the OAuth2 is?
Is this a new authorizatíon?
And currently the SHC 2.0 supports both (old and OAuth2)?
Juergen
OAuth2 is not a new authorization. But the binding now uses the library provided by openHAB instead of an other library. This both simplifies the code and reduces the overall size needed as the extra libraries are not needed anymore. It also makes easier to maintain OAuth2 authenticated products within openHAB.
This means that the way the connection is made to innogy doesn’t change only the implementation. Because the code has been modified this needs to be tested extra well to make sure it’s implemented correctly in the innogy binding.
Let me know if you find anything. You can send logging via direct message if you prefer that.
Hello guys,
I really appreciate the efforts you take to make the Livisi binding alive with API 1.1.
As the update for SHC Classic will be distributed soon, I decided to switch to the new beta binding provided by @hilbrand.
Question: I tried to connect by using to refresh token that I received for the old binding. After this failed, I tried to follow the procedure described by @oliver_kuhl with trace level and searching the logs - although it succeeded to connect to the bridge with the authcode, I didn’t find any refresh token in the logs.
But: I found a file StorageHandler.For.OAuthClientService.json under /var/lib/openhab2/jsondb that seems to store the refresh tokens.
Do we still need to fish the refresh token with the new binding or is this now stored via the new libraries?
The refreshtoken is stored via the new libraries. To initial connect only the authcode is needed. So it’s not needed to set in in a things file if a textual configuration is used. I removed the refresh token from the thing. If you have a thing created via PaperUI it probably still has this property, but if you would recreate the thing via PaperUI. I did not anticipate the option to configure the refreshtoken as it is all handled by the new library and I assume having an authcode should be sufficient.
So it should work if you set the one time authcode. and then you can remove the code (if you do a textual configuration. for things created with PaperUI with an auth code set, it will be removed after getting a refresh token.)
1 Like
Thank you for this quick reply - I use textural configuration and it seems to work fine.
The migration from the old binding to the new went quite easy.
If you need further information about the API you can contact me at any time - I have been the contact regarding the Livisi API for @oliver_kuhl and may provide some help/details if needed.
1 Like
- Enabled trace this morning
- saw that authorization did not work
- states that authcode is missing
- created new authcode
- communicates fine now
- wanted to let the community know
- saw the last messages here and found that the community solved my issue already
In summary great binding, great community 
Just to be very specific in case someone needs this reference:
I have the version with timestamp in binding (04/11/2019 21:00) running on Openhab 2.4
As far as I know innogy drops connection to openhab every 6 hours.
In the logs I can see that there seem to be exceptions occuring. This causes no communication between openhab and innogy for approx 15min. After that the binding fully recovers until it occurs again.
I have seen this only with the new binding for the SHC2.0. The old binding for SHC 1.0 did not show this behaviour.
I have 2 sample trace files and I know the timestamp of the exception.
As I better do not touch source code: Who would be willing to look at this?
I then make the traces available to that user.
Juergen
Can you send the exception/log files to me via direct message. I’ll have a look and fix it.
Important notice: I’ve created a pull request (PR #6389) of the updated binding. It’s my intention to get this binding in the upcoming openHAB 2.5.0 release. So it should be great to make sure that the binding works correctly. A number of you have already provided feedback. So if you haven’t tried it yet or did try but don’t have the latest version (15/11/2019) yet, you can download the jar of the binding here: https://github.com/Hilbrand/openhab2-addons/releases/tag/innogy It should work on openHAB 2.4 and 2.5
1 Like
Hey Hilbrand,
your binding is running in my OH 2.4 instance since yesterday without any problems. it seems to be like my last Version.
ralph