Tibber Binding

kjoglums · July 13, 2020, 10:31am

Strange, haven’t seen this issue before.

Everything with your user/home work as it should when testing queries under developer.tibber.com (API explorer)?

Have you tried rebooting OH once more?

Ontrackx · July 13, 2020, 5:40pm

Yes and yes

kjoglums · July 14, 2020, 9:40pm

Could you download and test with the following version?

Tibber 2.5.7-SNAPSHOT.jar

Ontrackx · July 17, 2020, 8:46pm

Hello, sorry for late reply (i am offshore at the moment)
Removed tibber jar from addons
Shutdown openhab from console
Deleted cache in OH folder
Reinstalled jar file
Everything is working great now

Danonym1 · July 29, 2020, 6:19pm

A late reply this, but its been some busy months.
I finally got to do some more testing on this.
I installed a fresh 2.5.7 openhab installation with only the latest Tibber binding, and still didn’t get any data other than timestamps.
Then I found an old snapshot of the binding (2.5.0.201912082242).

Deleted the Tibber Thing from the 2.5.7 version;
Uninstalled the 2.5.7 Tibber Addon;
Restarted openhab;
Installed the 2.5.0 Tibber snapshot
Added the Thibber Thing.
And Voila, it works again!

@kjoglums could you please take a look at the code, and see if there could be anything related to an inactive Tibber subscription that could cause the issue I am seeing? It seems to me that the problem for me occured when I cancelled my Tibber subscription and that the earlier version of the binding handles thing differently i accordance to this (PS: I could be totally wrong :-p)

kjoglums · July 29, 2020, 7:53pm

Could you test the binding from Post 84? This is the 2.5.7 binding version which I am successfully using for my openHAB 2.5.7 setup. I am looking through the code to see if there are any differences between my local version and the official version.

Your issues related to subscription/null values are hard to avoid. However, your items/channels associated with a non-working subscription should not be a huge problem, as the items/channels will be initialised as null, and will then not be updated until a different value should be read.

Danonym1 · July 29, 2020, 8:15pm

I can give it a try, but I doubt it will work. All attempts from atlest version 2.5.4 and up have been unsuccesfull.The one I’got it to work with now was from december 2019 as far as I can see.

The items related to suibscription/null is no problem here. I understand why tehy are null and I have no need for them. But the live items are the ones that are not updating at all with the latest version of the binding. Don’t you agree that some changes must have been done somewhere in the binding since I get the items updatet on an older snapshot but not the newest ones.

kjoglums · July 29, 2020, 9:53pm

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:

ssh into OpenHab service
Stop OpenHab service: sudo systemctl stop openhab2.service
Remove existing jar file from openhab2-addons folder
Remove tmp files: sudo rm -rf /var/lib/openhab2/tmp/*
Remove cache files: sudo rm -rf /var/lib/openhab2/cache/*
Remove backup files: sudo rm -rf /var/lib/openhab2/jsondb/backup/*
Remove cache: sudo openhab-cli clean-cache
Place jar file from my previous post into openhab2-addons folder
Restart OpenHab service: sudo reboot
Reboot OH once more if you still only get timestamp measurements.

I will also continue to look for potential issues wrt code.

taz83 · August 14, 2020, 10:38am

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]

taz83 · August 14, 2020, 10:51am

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?

github.com

openhab/openhab-addons/blob/1bf6976e6a463bdcf99313fda1a5d9d1fb476f8b/bundles/org.openhab.binding.tibber/src/main/java/org/openhab/binding/tibber/internal/handler/TibberHandler.java#L174


        String timestamp = myObject.get("startsAt").toString().substring(1, 20);
        updateState(CURRENT_STARTSAT, new DateTimeType(timestamp));

    } catch (JsonSyntaxException e) {
        updateStatus(ThingStatus.OFFLINE, ThingStatusDetail.COMMUNICATION_ERROR,
                "Error communicating with Tibber API: " + e.getMessage());
    }
}
if (jsonResponse.contains("daily")) {
    try {
        JsonObject myObject = (JsonObject) object.getAsJsonObject("data").getAsJsonObject("viewer")
                .getAsJsonObject("home").getAsJsonObject("daily").getAsJsonArray("nodes").get(0);

        String timestampDailyFrom = myObject.get("from").toString().substring(1, 20);
        updateState(DAILY_FROM, new DateTimeType(timestampDailyFrom));

        String timestampDailyTo = myObject.get("to").toString().substring(1, 20);
        updateState(DAILY_TO, new DateTimeType(timestampDailyTo));

        updateChannel(DAILY_COST, myObject.get("cost").toString());
        updateChannel(DAILY_CONSUMPTION, myObject.get("consumption").toString());

kjoglums · August 14, 2020, 1:36pm

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.

I have tried to rule out these occurrences, so could you test with a new version of the binding?
org.openhab.binding.tibber-2.5.8-SNAPSHOT.jar

taz83 · August 14, 2020, 7:22pm

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 · August 19, 2020, 11:04am

I have now tried to implement “Price Level” as a String channel in the binding (normal, cheap, expensive etc is returned as a String value).

Please feel free to test new version of the binding:
org.openhab.binding.tibber-2.5.8-SNAPSHOT.jar

taz83 · August 22, 2020, 7:49pm

Works great, thank you!

sjef86 · September 5, 2020, 8:07am

@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

kjoglums · September 5, 2020, 8:44am

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?

sjef86 · September 6, 2020, 7:01am

Hi Stian,

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.

Best regards
Christian

CyberLine · October 6, 2020, 5:35pm

Hey there,

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”

kjoglums · October 6, 2020, 8:39pm

Could you enable debug logging and do a OH reboot to get a more detailed log as part of thing initialisation?

Expect it could be related to having Tibber Pulse only, no Tibber subscription? If so, you could try replacing your Tibber installation with a manual installation of the binding:
https://community.openhab.org/t/tibber-binding/67019/94?u=kjoglums

CyberLine · October 7, 2020, 5:58am

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)