openhab / openhab-addons

Add-ons for openHAB
https://www.openhab.org/
Eclipse Public License 2.0
1.88k stars 3.59k forks source link

[innogysmarthome] Generaion 1 devices not working with binding due to api differences #6613

Closed F-Kg closed 4 years ago

F-Kg commented 4 years ago

Current Behavior

After I upgraded, 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).

Innogy_gen1

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

The log shows:

2019-12-16 17:20:02.726 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at line 1 column 2679 path $[6].state.updateAvailable
        at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:224) ~[?:?]
        at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:129) ~[?:?]
        at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:220) ~[?:?]
        at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:129) ~[?:?]
        at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:220) ~[?:?]
        at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.read(TypeAdapterRuntimeTypeWrapper.java:41) ~[?:?]
        at com.google.gson.internal.bind.ArrayTypeAdapter.read(ArrayTypeAdapter.java:72) ~[?:?]
        at com.google.gson.Gson.fromJson(Gson.java:888) ~[?:?]
        at com.google.gson.Gson.fromJson(Gson.java:853) ~[?:?]
        at com.google.gson.Gson.fromJson(Gson.java:802) ~[?:?]
        at com.google.gson.Gson.fromJson(Gson.java:774) ~[?:?]
        at org.openhab.binding.innogysmarthome.internal.client.InnogyClient.executeGet(InnogyClient.java:142) ~[?:?]
        at org.openhab.binding.innogysmarthome.internal.client.InnogyClient.executeGetList(InnogyClient.java:156) ~[?:?]
        at org.openhab.binding.innogysmarthome.internal.client.InnogyClient.getDeviceStates(InnogyClient.java:588) ~[?:?]
        at org.openhab.binding.innogysmarthome.internal.client.InnogyClient.getFullDevices(InnogyClient.java:422) ~[?:?]
        at org.openhab.binding.innogysmarthome.internal.manager.DeviceStructureManager.refreshDevices(DeviceStructureManager.java:85) ~[?:?]
        at org.openhab.binding.innogysmarthome.internal.handler.InnogyBridgeHandler.startClient(InnogyBridgeHandler.java:236) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_222]
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[?:1.8.0_222]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_222]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[?:1.8.0_222]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_222]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_222]
        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]

What I tried so far to fix:

clear cache, reinstall binding, get a new auth key, reboot raspi

If you want me to deliver any more information please let me know. I am a beginner and not sure what information is important.

ErwinKaloschke commented 4 years ago

Same to me

planbnet commented 4 years ago

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"}

I could fix this for myself by changing the type of the "updateAvailable" property in the State class from StringState to String, but this probably will fail with the new hardware revision I guess...

Novanic commented 4 years ago

I have the same problem (at updating normally from 2.4.0 to 2.5.0 without any beta, snapshot or milestone releases). Please let this get fixed soon because it seems to affect all Innogy users (with at least Bridge Gen 1, and the Innogy binding of 2.4.0 is also not working anymore, therefore it is now broken for nearly all users). :-(

Hilbrand commented 4 years ago

@planbnet

I could fix this for myself by changing

Did you actual change it? I'm asking because I don't know if this is the only difference. It crashes on the first and if all the other fields also have a mismatch than it will be a long time before this gets fixed because with each iteration the next value will fail.

So to fix this a complete example of data received from the device by the binding is needed.

planbnet commented 4 years ago

@Hilbrand This was really the only change I did and the Binding is running fine for a week now. Seems like only this one field (updateAvailable) is handled differently.

Hilbrand commented 4 years ago

I've created a new jar that should fix this issue: https://github.com/Hilbrand/openhab-addons/releases/tag/innogy

I completely removed reading the field updateAvailable as it doesn't seem to be used in the code.

Novanic commented 4 years ago

The fix is working for me. Thank you very much. :-)

I copied the new snapshot jar to the addons folder, uninstalled the (old) binding via Paper UI, removed the SmartHome controller binding, rebooted the server and searched via Paper UI for new innogy things. Now everything was recognized and initialized correctly again (the old things and items were working again automatically).

F-Kg commented 4 years ago

It works for me, too. Thanks a lot!

Will this fix get included in the release version of OH and if so, when? Am I supposed to close this issue?

ErwinKaloschke commented 4 years ago

Same for me. Thank you very much and I wish you a fine Christmas :-)

Hilbrand commented 4 years ago

@F-Kg Yes I plan to have it in the next release. I don't know when that is. No need to close the issue. I'll will create the pull request and if that is merged it should be auto closed.