You got it! It is indeed the Pulse that is not getting a network connection. I did not even think about that. I have changed the wireless password, completely forgetting that the Pulse needs the new key as well. Thanks, Stian!
1 Like
Hi. I’ve had some problems with the Tibber binding lately, after I upgrade to the latest release none og the items Are updating except the timestamp item. I’ve tried to delte the thing and remove all items, restarte openhab. But No luck, I’ve not logged anything yet and not tried to revert to an old snapshot, but any suggestions to the problem?
I’ve observed the same issue as part of a full “cleanup” (clean cache, tmp etc). After the first reboot (openhab reboot), I sometimes only get updates for timestamp. Although, when doing yet another reboot I get updates as normal.
As part of full “cleanup” I have also experienced a couple of occurrences where my “live measurements” are not updated. However, this would relate to the number of connections allowed, and is reported as an error in openhab as “too many concurrent connections…”. When this happens, I delete my token (tibber account), and create a new one which I also use as input in OH.
So, if you are seeing updates as normal from developer.tibber.com (API explorer), meaning the issue is OH related only, I would try to clean cache etc and do a couple of reboots. Not sure what would be causing this issue.
Hi @kjoglums
Been able to troubleshoot som more. I think I might have a problem because my supscription with Tibber is no longer active (bought Solar panels and had to change because of the economy).
Most of the none live items have null as value, that is ok since I dont have an subscription. But the live items are still accesable from the api explorer, but they are not updated in Openhab. Everything seems ok in the log, but as you can see from the picture things are not correct.
I should add that I’ve tried all of what you suggested in the previous reply.
2020-06-11 20:53:34.195 [DEBUG] [ibber.internal.handler.TibberHandler] - API response: {"data":{"viewer":{"home":{"currentSubscription":{"priceInfo":{"current":null}},"daily":{"nodes":[{"from":"2020-06-10T00:00:00+02:00","to":"2020-06-11T00:00:00+02:00","cost":null,"unitPrice":null,"consumption":null,"consumptionUnit":"kWh"}]},"hourly":{"nodes":[{"from":"2020-06-11T19:00:00+02:00","to":"2020-06-11T20:00:00+02:00","cost":null,"unitPrice":null,"consumption":null,"consumptionUnit":"kWh"}]}}}}}
2020-06-11 20:53:34.307 [DEBUG] [ibber.internal.handler.TibberHandler] - Pulse associated with HomeId: Live stream will be started
2020-06-11 20:53:34.309 [DEBUG] [ibber.internal.handler.TibberHandler] - Starting Websocket connection
2020-06-11 20:53:34.323 [DEBUG] [ibber.internal.handler.TibberHandler] - Connecting Websocket connection
2020-06-11 20:53:35.075 [DEBUG] [ibber.internal.handler.TibberHandler] - Sending websocket connect message
2020-06-11 20:53:35.203 [DEBUG] [ibber.internal.handler.TibberHandler] - Send message: {"type":"connection_init", "payload":"token=rYbi_Ex1qo6SHIgOVRbbneCzu64Nfktr2phKM6GTq1o"}
2020-06-11 20:53:35.282 [DEBUG] [ibber.internal.handler.TibberHandler] - Connected to Server
2020-06-11 20:53:35.283 [DEBUG] [ibber.internal.handler.TibberHandler] - Send message: {"id":"1","type":"start","payload":{"variables":{},"extensions":{},"operationName":null,"query":"subscription {\n liveMeasurement(homeId:\"dd82df62-fb88-4828-be0d-69a5035815f4\") {\n timestamp\n power\n lastMeterConsumption\n accumulatedConsumption\n accumulatedCost\n currency\n minPower\n averagePower\n maxPower\nvoltagePhase1\n voltagePhase2\n voltagePhase3\n currentPhase1\n currentPhase2\n currentPhase3\n powerProduction\n accumulatedProduction\n minPowerProduction\n maxPowerProduction\n }\n }\n"}}
2020-06-11 20:53:38.182 [INFO ] [marthome.model.script.TimeOfDay rule] - Calculating time of day...
2020-06-11 20:53:42.394 [INFO ] [marthome.model.script.TimeOfDay rule] - Calculated time of day is EVENING
According to your log, everything seems normal: Your Tibber Pulse is recognised for the given token/homeid, a websocket connection for realtime data is initiated, and the correct handshake/initialisation messages are sent to initiate the live stream. You also get connected to the server.
A couple of things:
-
If you deleted/recreated your Tibber thing: Did you use the same thing ID for the new Tibber thing created as the one deleted? As created items, at least text file configured items, include reference to thing ID, your items will not be updated unless the correct thing ID is in place. You then would need to either change your Tibber thing ID back to original, alternatively create/link new items with the correct thing ID.
-
Just for reference: The Tibber binding pull request is approved, and the binding is therefore included as part of official OH addons. The lates version can be downloaded:
Link
Anyone who can point out whats wrong?. new install OH 2.5.6
UNINITIALIZED - HANDLER_INITIALIZING_ERROR Index: 0, Size: 0
21:28:18.036 [WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(Unknown Source) ~[?:1.8.0_201]
at java.util.ArrayList.get(Unknown Source) ~[?:1.8.0_201]
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(Unknown Source) ~[?:1.8.0_201]
at java.util.concurrent.FutureTask.runAndReset(Unknown Source) ~[?:1.8.0_201]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown Source) ~[?:1.8.0_201]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) ~[?:1.8.0_201]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [?:1.8.0_201]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [?:1.8.0_201]
at java.lang.Thread.run(Unknown Source) [?:1.8.0_201]
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?
Yes and yes 
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
1 Like
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)
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.
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.
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.
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.
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
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.
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
Works great, thank you!