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

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 :slight_smile:

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

Thanks for your efforts @hilbrand, greatly appreciated!

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

Hey all, thanks for the effort taking the binding to the next level! :+1:

I did a quick test on my 2.4 setup and it works fine so far. Will keep an eye on it and report…

Hey Hilbrand,

just to let you know: the button-press behavior changed. Now every button press (not only the first) fires two button-pressed events as well as a button press that wasn’t pressed. In this case on the device (dimmer switch) I was controlling with “button1”. If I control another device with no buttons, no additional button pressed event fires.

2019-11-19 12:25:12.626 [vent.ChannelTriggeredEvent] - innogysmarthome:WSC2:SMARTHOME10:51a5bfb1b4f543a99646116134cadcd7:button1 triggered PRESSED

2019-11-19 12:25:12.648 [vent.ChannelTriggeredEvent] - innogysmarthome:WSC2:SMARTHOME10:51a5bfb1b4f543a99646116134cadcd7:button1 triggered PRESSED

2019-11-19 12:25:14.720 [vent.ChannelTriggeredEvent] - innogysmarthome:ISD2:SMARTHOME10:e45e5bc6848b4dc6b5bac1a575271fa8:button2 triggered PRESSED

This is when you press a button on the device, right? Can you log with trace level some time before and after the press and send the log to me via direct message. I’ll have a look and see if Ican find what is going on.

Hello @hilbrand.

I recognized that the binding uses invertValueIfConfigured for the values of the CHANNEL_ROLLERSHUTTER.

As my home is configured to use 100% as “closed” and 0% as “open” I would really need to use this setting - but I was not able to find the corresponding config for the binding or the Rollershutter-Thing.

Could you provide some information on how to use the invert on ISR2? I know that some other bindings support the invert for shutter devices.

Thanks and have a good one,

Jörn

I’ve updated the binding on the location mentioned above (20/11/2019 15:00). I’ve added a channel option invert to the rollershutter channel. If you configure it with true it will work with 100% closed 0% open. Btw ON/OFF is not a valid state for rollershutters so I’ve changed this to UP/DOWN.

1 Like

this behaviour comes from a change made by me.
before my Change the Event was only fired when different Buttons are pressed. i think there is a bug in the innogy-api because pressing buttons are not handled correct in the innogy-app too.

i have reported a bug at innogy but i have no Feedback from them.

perhaps somebody can do a Workaround…i was not able to…

Ralph

Wow - I’m impressed :wink:

I will update my binding tomorrow and test the channel option. I assume it needs to be applied like this:
Thing ISR2 Shutter_Some "Shutter" @ "Room" [ id="blablablubs", invert=true ]

Thank you.

Hi @RalphSester. Do you have detailed description of the bug? There might be a chance to clarify the behavior directly with the dev…

I did some investigating with Hilbrand. He was able to fix the button-press issue. With the updated binding everything works fine for me. Even long presses. Thank you again for that.

1 Like

i have sent you some detailled stuff……

Thanks - I will try to clarify the behavior and come back with results (if I have some)

Hi @hilbrand,

I did a smoke test with the “invert” option as mentioned before on one of my shutters.

I did not recognize any changes to the displayed level of the shutter - the Item is still on 100% although the shutter is fully opened.

Next step is to change to debug loglevel and give it another try…