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

RalphSester · November 16, 2019, 12:39pm

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

oliver_kuhl · November 17, 2019, 10:37pm

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

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

sayhelloto · November 19, 2019, 11:30am

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

hilbrand · November 19, 2019, 8:36pm

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.

lagom · November 20, 2019, 1:15pm

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

hilbrand · November 20, 2019, 1:51pm

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.

RalphSester · November 20, 2019, 3:31pm

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

lagom · November 20, 2019, 3:32pm

Wow - I’m impressed

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.

lagom · November 20, 2019, 3:34pm

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

sayhelloto · November 20, 2019, 3:38pm

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.

RalphSester · November 20, 2019, 3:51pm

i have sent you some detailled stuff……

lagom · November 20, 2019, 4:13pm

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

lagom · November 20, 2019, 4:57pm

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…

hilbrand · November 20, 2019, 8:54pm

You used the configuration on the thing. I added it on the channel. I think it should be something like this:

Thing ISR2 Shutter_Some “Shutter” @ “Room” [ id=“blablablubs” ] {
   Channel: rollershutter:RollerShutterActuator [invert=true] 
}

lagom · November 21, 2019, 8:22am

Ok, thanks - I will test it as soon as I have some time for it and come back with the results.

lagom · November 21, 2019, 2:54pm

Hello @hilbrand.

I had the chance to test it:

My things-file:

Thing ISR2 Shutter_Bathroom 	"Shutter" @ "Bathroom" 	[ id="blablablubsid" ] { channel: rollershutter:RollerShutterActuator [invert=true] }

The items-file:

Rollershutter ShutterBathroomPosition  "Bad [%.1f %%]"   (Shutter, ShutterPosition)  { channel="innogysmarthome:ISR2:zuhause:Shutter_Bathroom:rollershutter" }

The binding will not load any Things with a config entry like that.
Any idea?

Edit: also Rollershutter ShutterBathroomPosition "Bad [%.1f %%]" (Shutter, ShutterPosition) {channel="innogysmarthome:ISR2:zuhause:Shutter_Bathroom:rollershutter" [invert=true] } in the items-file didn’t change the value.

hilbrand · November 21, 2019, 3:33pm

I guess it doesn’t load the things file correct and therefor the item doesn’t get updated. I think my example might not be correct. I’m not very familiar with configuring channel parameters of existing channels. Here is an updated example:

Thing ISR2 Shutter_Some “Shutter” @ “Room” [ id=“blablablubs” ] {
    Channels:
        Type  rollershutter:RollerShutterActuator [invert=true] 
}

You could also try to create the thing in PaperUI. You should be able to configure the channel in PaperUI.

jlehre · November 23, 2019, 8:39am

As mentioned before the binding works fine for me (OH 2.5 and SHC 2.0). I only note from time to time that communication stops. This might be related to issues of the new SHC 2.0 or the innogy backend.
To workaround I set WebSocket Idle Timeout in Seconds to 300 seconds.
This was a hint from Hilbrand who already looked a the trace files I provided.

By the way: @Hilbrand: Thank you very much for your help.

Juergen

jlehre · November 29, 2019, 6:25am

This night my SHC 2.0 received a forced update to version 8.16-1.1.12.269. This caused the binding to close the connection “2019-11-29 03:30:50.278 [INFO ] [gysmarthome.internal.InnogyWebSocket] - Connection to innogy Webservice was closed normally.”

Unfortunately the connection was not reestablished automatically. After a restart of OH everything seems to be fine. Values are refreshed, commands can be sent.

Juergen

MartinT · December 1, 2019, 6:51am

Hi at all,

first of all I would like to thank all those who develop this binding especially @hilbrand without his own hardware. You’re doing a great job!

I can confirm the observation of Juergen that the binding from time to time loses the connection without reconnecting (version 2.5.0.201911042017):

3:15:36.344 [WARN ] [internal.handler.InnogyBridgeHandler] - Unknown exception
java.util.concurrent.TimeoutException: Idle
 timeout expired: 900000/900000 ms
        at org.eclipse.jetty.io.IdleTimeout.checkIdleTimeout(IdleTimeout.java:166) [75:org.eclipse.jetty.io:9.4.11.v20180605]
        at org.eclipse.jetty.io.IdleTimeout$1.run(IdleTimeout.java:50) [75:org.eclipse.jetty.io:9.4.11.v20180605]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]
2019-11-30 03:15:36.347 [INFO ] [gysmarthome.internal.InnogyWebSocket] - Connection to innogy Webservice was closed abnormally (code: 1001). Reason: Idle Timeout

2019-11-30 03:16:06.399 [hingStatusInfoChangedEvent] - 'innogysmarthome:bridge:8423c0c3' changed from OFFLINE: Idle timeout expired: 900000/900000 ms to OFFLINE (COMMUNICATION_ERROR): java.util.concurrent.ExecutionException: java.io.EOF
Exception: HttpConnectionOverHTTP@28958fe6(l:/192.168.7.6:45010 <-> r:api.services-smarthome.de/193.25.80.79:443,closed=false)=>HttpChannelOverHTTP@15ea5ab9(exchange=HttpExchange@16b6fe24 req=TERMINATED/null@null res=PENDING/null@null)[
send=HttpSenderOverHTTP@2c28e050(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator@2846b08c{s=START}],recv=HttpReceiverOverHTTP@6f3e08af(rsp=IDLE,failure=null)[HttpParser{s=CLOSED,0 of -1}]]<-DecryptedEndPoint@4ed88cb2{api.services-s
marthome.de/193.25.80.79:443<->/192.168.7.6:45010,OPEN,fill=-,flush=-,to=930307/0}->HttpConnectionOverHTTP@28958fe6(l:/192.168.7.6:45010 <-> r:api.services-smarthome.de/193.25.80.79:443,closed=false)=>HttpChannelOverHTTP@15ea5ab9(exchan
ge=HttpExchange@16b6fe24 req=TERMINATED/null@null res=PENDING/null@null)[send=HttpSenderOverHTTP@2c28e050(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator@2846b08c{s=START}],recv=HttpReceiverOverHTTP@6f3e08af(rsp=IDLE,failure=null)[
HttpParser{s=CLOSED,0 of -1}]]->SocketChannelEndPoint@2599cf59{api.services-smarthome.de/193.25.80.79:443<->/192.168.7.6:45010,ISHUT,fill=-,flush=-,to=49/0}{io=0/0,kio=0,kro=1}->SslConnection@38c6d9b6{NEED_WRAP,eio=-1/-1,di=-1}=>HttpCon
nectionOverHTTP@28958fe6(l:/192.168.7.6:45010 <-> r:api.services-smarthome.de/193.25.80.79:443,closed=false)=>HttpChannelOverHTTP@15ea5ab9(exchange=HttpExchange@16b6fe24 req=TERMINATED/null@null res=PENDING/null@null)[send=HttpSenderOve
rHTTP@2c28e050(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator@2846b08c{s=START}],recv=HttpReceiverOverHTTP@6f3e08af(rsp=IDLE,failure=null)[HttpParser{s=CLOSED,0 of -1}]]

This was most probably not caused by an internet reconnect. Often it’s working

java.util.concurrent.TimeoutException: Idle timeout expired: 900000/900000 ms
        at org.eclipse.jetty.io.IdleTimeout.checkIdleTimeout(IdleTimeout.java:166) [75:org.eclipse.jetty.io:9.4.11.v20180605]
        at org.eclipse.jetty.io.IdleTimeout$1.run(IdleTimeout.java:50) [75:org.eclipse.jetty.io:9.4.11.v20180605]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]
2019-12-01 05:10:52.899 [INFO ] [gysmarthome.internal.InnogyWebSocket] - Connection to innogy Webservice was closed abnormally (code: 1001). Reason: Idle Timeout
2019-12-01 05:11:24.488 [INFO ] [gysmarthome.internal.InnogyWebSocket] - Connected to innogy Webservice.

With the newest version from 29/11/2019 I get following exception:

org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.innogysmarthome [239]
  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.startAllBundles(DirectoryWatcher.java:1221) [10:org.apache.felix.fileinstall:3.6.4]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [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]

Thanks again!

Martin