Innogy Binding - bridge timeout during initialization


beginner here. After I upgraded today, the innogy binding is not working anymore for me. I upgraded from latest milestone to 2.5.0-1 release build. I am using the older version of the bridge (Gen. 1).

Paper UI shows the birdge as initializing and after a timeout it changes its state to:

Status: OFFLINE - COMMUNICATION_ERROR java.util.concurrent.TimeoutException: Total timeout 10000 ms elapsed

What I tried so far: clear cache, reinstall binding, get a new auth key, reboot raspi

The logger is showing this warning:

2019-12-16 17:20:02.726 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at line 1 column 2679 path $[6].state.updateAvailable
        at$ ~[?:?]
        at$ ~[?:?]
        at$ ~[?:?]
        at$ ~[?:?]
        at$ ~[?:?]
        at ~[?:?]
        at ~[?:?]
        at ~[?:?]
        at ~[?:?]
        at ~[?:?]
        at ~[?:?]
        at org.openhab.binding.innogysmarthome.internal.client.InnogyClient.executeGet( ~[?:?]
        at org.openhab.binding.innogysmarthome.internal.client.InnogyClient.executeGetList( ~[?:?]
        at org.openhab.binding.innogysmarthome.internal.client.InnogyClient.getDeviceStates( ~[?:?]
        at org.openhab.binding.innogysmarthome.internal.client.InnogyClient.getFullDevices( ~[?:?]
        at org.openhab.binding.innogysmarthome.internal.manager.DeviceStructureManager.refreshDevices( ~[?:?]
        at org.openhab.binding.innogysmarthome.internal.handler.InnogyBridgeHandler.startClient( ~[?:?]
        at java.util.concurrent.Executors$ ~[?:1.8.0_222]
        at java.util.concurrent.FutureTask.runAndReset( ~[?:1.8.0_222]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301( ~[?:1.8.0_222]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ ~[?:1.8.0_222]
        at java.util.concurrent.ThreadPoolExecutor.runWorker( [?:1.8.0_222]
        at java.util.concurrent.ThreadPoolExecutor$ [?:1.8.0_222]
        at [?:1.8.0_222]

Any help is much appreciated

Any reason to not use the v2 binding?

I have exactly the same problem. We are talking about the v2 binding - we just have the older revison of the hardware (Innogy Bridge).

The problem seems to be that the service sends:

"updateAvailable": ""

but the JSON parser expects something like this:

"updateAvailable": {"value": "", "lastChanged": "2019-06-20T00:15:32.766Z"}

Perhaps you should file an issue on GitHub for the developers.


1 Like