This is strange: The binding handles subscription queries and live measurements (websocket) independently, so your issue should not be related to subscription cancellation.
I totally agree that your issue would indicate some changes to the code. There has been made one change related to the live measurements along the way, however, this was related to the Live Current part. Initially, Tibber had these 3 channels reported as currentPhaseX (X=1-3), but this has been changed to currentLX (X=1-3). This is updated in the binding version I referred to in my previous post, but would not explain why you only get the Live Timestamp measurement (most of the channels have remained unchanged).
The core code for performing queries/establishing connection for live measurements have remained the same throughout all updates. Your logs also confirm that you achieve connection, i.e. “Connected to Server” would confirm that a websocket connection is successfully established. Also, as you at least get the Live Timestamp, you are getting data, but some of the measurements are apparently not recognised.
How are your items defined? Via Paper UI or via text files? If textual based, could you try deleting your items and create once again to reinitialise items/channels?
Also, as part of switching between versions, it could be recommended to do a thorough cache/tmp clean to ensure old stuff is completely removed:
Hi! I’m facing the same problem as in post #81 but with OpenHab 2.5.7 running SNAPSHOT-2.5.8 version of Tibber binding.
I tried running the 2.5.7 version of the binding, but then Tibber API is not even showing up as supported thing.
Is there any way to get more debug info as to why is this so? I do not have an active Tibber electricity delivery yet. I wonder if it’s the consumption data that could be empty and causing this?
12:30:40.846 [DEBUG] [tibber.internal.handler.TibberHandler] - API response: {"data":{"viewer":{"home":{"currentSubscription":{"priceInfo":{"current":{"total":0.5929,"startsAt":"2020-08-14T12:00:00+02:00"}}},"daily":{"nodes":[]},"hourly":{"nodes":[]}}}}}
12:30:40.849 [DEBUG] [tibber.internal.handler.TibberHandler] - API response: {"data":{"viewer":{"home":{"currentSubscription":{"priceInfo":{"current":{"total":0.5929,"startsAt":"2020-08-14T12:00:00+02:00"}}},"daily":{"nodes":[]},"hourly":{"nodes":[]}}}}}
12:30:40.882 [WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:657) ~[?:1.8.0_252]
at java.util.ArrayList.get(ArrayList.java:433) ~[?:1.8.0_252]
at com.google.gson.JsonArray.get(JsonArray.java:194) ~[?:?]
at org.openhab.binding.tibber.internal.handler.TibberHandler.getURLInput(TibberHandler.java:175) ~[?:?]
at org.openhab.binding.tibber.internal.handler.TibberHandler.updateRequest(TibberHandler.java:244) ~[?:?]
at org.openhab.binding.tibber.internal.handler.TibberHandler.lambda$0(TibberHandler.java:235) [?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_252]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]
12:30:40.850 [WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:657) ~[?:1.8.0_252]
at java.util.ArrayList.get(ArrayList.java:433) ~[?:1.8.0_252]
at com.google.gson.JsonArray.get(JsonArray.java:194) ~[?:?]
at org.openhab.binding.tibber.internal.handler.TibberHandler.getURLInput(TibberHandler.java:175) ~[?:?]
at org.openhab.binding.tibber.internal.handler.TibberHandler.updateRequest(TibberHandler.java:244) ~[?:?]
at org.openhab.binding.tibber.internal.handler.TibberHandler.lambda$0(TibberHandler.java:235) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_252]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]
Well, it does seem that without consumption data this gives an error. Since the API gives response and provides price data without a delivery would it be possible to fix this?
Yes, apparently, without a Tibber subscription the “daily” and “hourly” data is reported as empty arrays ("[]"), which again is causing the binding to throw an IndexOutOfBoundsException as the binding is set up to fetch a specific element expected from the array.
This works like a charm. I get NaN on the current consumption values which is expect I guess.
Thank you for the super quick fix!
One more question. Is it possible to have the low/medium/high indication together with the current price? I’m thinking about controlling some of the not-so-important appliances (e.g. mobile charger, comfort heating in the bathroom) based on this value. One plugs in the mobile in the evening and it charges when the price is low during the night but turn it off towards the morning. It’s just a wish though, there is probably another way to achieve this, haven’t really investigated yet.
@kjoglums
I’m currently having a hard time getting the binding to subscribe to real-time data. It updates once and that’s it. Tried everything now, deleting things, items linking, TMP and cache. Restarted several times, but same results. I tried binding 2.7 and 2.8… currently on oh2.4…any idea? Thanks Chris
Strange. Do you get any log response? Could you try enabling debugging (log:set debug)? Would assume everything work as it should when running Tibber API explorer?
I’ve set my log to DEBUG, and get some log response. I can confirm that everything works when running the Tibber API explorer. I’ve sent you a PM with my log results.
after installing this thing and configured api and homeId i have the following error in the log:
2020-10-06 19:22:22.256 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'tibber:tibberapi:20189b38': com.google.gson.JsonNull cannot be cast to com.google.gson.JsonObject
java.lang.ClassCastException: com.google.gson.JsonNull cannot be cast to com.google.gson.JsonObject
at com.google.gson.JsonObject.getAsJsonObject(JsonObject.java:205) ~[bundleFile:?]
at org.openhab.binding.tibber.internal.handler.TibberHandler.getURLInput(TibberHandler.java:175) ~[?:?]
at org.openhab.binding.tibber.internal.handler.TibberHandler.getTibberParameters(TibberHandler.java:118) ~[?:?]
at org.openhab.binding.tibber.internal.handler.TibberHandler.initialize(TibberHandler.java:91) ~[?:?]
at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_265]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_265]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_265]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_265]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_265]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_265]
i’am running on OH 2.5.9 and openjdk version “1.8.0_265”
i have no pulse and for now no active contract (it starts in a few weeks). so some values in the response are null. Maybe thats the Problem? (I think this should also be covered by the code)
Yes, that is likely the problem. But if not having neither subscription, nor Pulse, I would assume most of the values would be null, and the binding would be “useless”. Again, a debug log would be needed to see the response in your specific case.
Anyway, the post I linked to in my previous post has a link to manual download / installation, and this binding version does a check for null values. Basically, if there is no data to fetch your thing will be set to OFFLINE.
Any news regarding this?
I am also having problems with live meassurments in OH 2.5.9, but on Tibber API explorer the meassurment is live, see images below.
new to OpenHab, but I just installed the Tibber-Binding. Noticed that the log was spammed with [vent.ItemStateChangedEvent] - TibberAPI_PowerConsumptionProduction changed from ... ...
I added a filter to the logs:
The TibberAPI_PowerConsumptionProduction should be actual updates/changes of your item.
For the Total timeout 20000 ms elapsed, this often happens immediately after hour changes, as Tibber requires some time to calculate the new values. Uncertain how this could be avoided.
