Again, thanks for this Binding! @kjoglums
Is it possible to slow down the updates?
openhab/items/TibberAPI_TotalCost/statechanged ItemStateChangedEvent {"type":"Quantity","value":"52.838497","oldType":"Quantity","oldValue":"52.834574"}
The log and (OH3) Event Monitor are being hit rather hard.
Would it be possible to consider some options to limit updates to seconds or Hysteresis(?) (1.0\0.1\0.001 etc)
This would probably require a more extensive change to the binding, finding a way to only update channels every X reading, which again would require some user defined input due to individual needs. Feel free to provide proposal/pull request.
As previously mentioned, Tibber Pulse (Live Measurements) is per default sending updates through a continuous stream, i.e. websocket, meaning updates every 2 seconds. So, there is no active requests on the binding side (which easily could be set with desired update interval), and the binding is just reading/updating what is sent from Tibber.
I still get the following error on initializing the thing in Openhab 3:
15:04:45.396 [ERROR] [rnal.common.AbstractInvocationHandler] - An error occurred while calling method ‘ThingHandler.initialize()’ on ‘org.openhab.binding.tibber.internal.handler.TibberHandler@943cae5’: Index 0 out of bounds for length 0
java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) ~[?:?]
at jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) ~[?:?]
at jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248) ~[?:?]
at java.util.Objects.checkIndex(Objects.java:372) ~[?:?]
at java.util.ArrayList.get(ArrayList.java:459) ~[?:?]
at com.google.gson.JsonArray.get(JsonArray.java:194) ~[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 jdk.internal.reflect.GeneratedMethodAccessor42.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
15:04:45.404 [ERROR] [.core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing ‘tibber:tibberapi:8d90a44fd4’: Index 0 out of bounds for length 0
java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) ~[?:?]
at jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) ~[?:?]
at jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248) ~[?:?]
at java.util.Objects.checkIndex(Objects.java:372) ~[?:?]
at java.util.ArrayList.get(ArrayList.java:459) ~[?:?]
at com.google.gson.JsonArray.get(JsonArray.java:194) ~[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 jdk.internal.reflect.GeneratedMethodAccessor42.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
Any suggestions?
EDIT: Fixed it by loading the demo token and demo houseId, enabling the thing, then changing the thing params to my personal token/houseId.
I also believe the changes covered by the pull request, which is set up to handle subscription null values, are not available from the 3.0 stable branch, only for the 3.1 milestone branch.
Yes, upgrading to the 3.1.0M1 milestone branch also resolves the issue.
Hey i am also interesting in “future” prices to control some energy consuming devices during the day. First example i have is the pool filtration, which needs to run aprox. 8 hours a day and i would like to use the 8 cheapest hours of the day.
Is there any plan to integrate it?
Hi.
First of all, thank you so much for making this binding!
I’m having one issue with it though, it does not like at all that my internet connection drops out, causing a timeout and then it crashes:
021-02-27 10:07:20.533 [WARN ] [ibber.internal.handler.TibberHandler] - IO Exception: java.util.concurrent.TimeoutException: Total timeout 20000 ms elapsed
2021-02-27 10:08:02.025 [WARN ] [ibber.internal.handler.TibberHandler] - Websocket Client Stop Exception: null
The strange thing is, that a karaf console command: bundle:restart org.openhab.binding.tibber
does not get it going again. It restarts the binding, but it does not start updating the items.
The only solution I’ve found so far is to restart the openhab service. (or the raspberry itself)
I’m running openHAB 3.0.1, and just installed the Tibber binding from the bindings page.
Running on a openhabian install (raspbian 10)
I don’t know if this is the correct place to address this issue, but you can probably point me in the right direction.
I am absolutely also interested in this but I also understand that there would be a great deal of work involved in this. I humbly ask the same question - is there any plans for the future for this?
I must admit, currently, I haven’t considered further development due to the limited time available.
Also very uncertain what would be the best approach to implement such a feature, considering an array of 24 values potentially requiring 1 dedicated channel per value. Then also considering “noise” for users not interested.
Feel free to evaluate/develop code for a pull request.
The IOException received is a “standard” Tibber issue regarding values retrieved during hour transition.
Why the websocket drops is uncertain (besides lost internet connection). However, binding is set up to try to reestablish live measurments as part of refresh intervals, user defined).
Hi,
I absolutely understand, time is the thing we all have limited resources of. I wish I was a programmer and could help with this but my knowledge is unfortunately not at this level. But my thinking was to get one array in return, separated with commas or similar. But I don’t really know if this is even a feasible idea. But now I know where this binding is - thank you for the current functionality and also your fast answer!
All the best to you!
Appreciate your feedback. I’m not a programmer either, self-taught having looked through other bindings.
And you are correct, we could achieve one query/one response for future price. However, as you would see from Tibber API explorer, it could be challenging to parse response into one usable array, getting only price, thus my assumption the best approach would be to parse into dedicated channels (24 separate values).
I am sure you are right, this is above my head to fully understand though. Found someone else who did something similar (I am sure you have read it earlier but I post the link here anyway).
The end of this post talks about this:https://discourse.nodered.org/t/newbie-here-tibber-question/29199/24
Seems that they solved it by just changing the query a little bit they got the future prices (instead of current they used today and tomorrow). But I guess your issue is more that the response would be difficult to handle and I don’t even know what I am talking about here. Just a comment to the whole thing, maybe someone else who knows more than I do find it interesting.
Best regards
Samir
Thanks for creating this very useful binding for Tibber. Using mostly the current total price for savings-calculations on my solar panels production and this works well.
Having huge difficulties getting the current_level for price level information. Should be available but not able to see any values received for that item.
This is the case BOTH for OpenHAB2 and my experimental fresh installation of OpenHAB3. Any ideas whats wrong with my settings?
For OH 3, the Price level should be available for 3.1 milestone build (not for the stable release, as the approved pull request was included in the milestone build only).
Also, for OH 2, the price level was not included as part of an official pull request, hence, would only be available through the 2.5.8 version (jar file provided for manual install: Link)
Thanks for the reply. For OpenHAB2 is this to understand ONLY the 2.5.8 version? So not available in the 2.5.12 version?
Also, the latest for OpenHAB3 seems to be 3.0.1 - or am I missing something?
True, as it was implemented for test/verification (manual install) and was not filed for a pull request towards the official OH 2 repository. Thus being available only for the 2.5.8 manual install version.
Price level channel was included in a pull request for OH 3, as part of other corrections/enhancements, although all bundle PR’s merged after OH release were included in 3.1 milestone release only.
Anyone else having this error with Tibber binding?
It’s been working before i upgraded to OH3.M5. I’ve also tested with upgrading the gson from 2.8.5 to 2.8.7, but with same results.
Have ofcourse deleted the thing and links and created new ones, but this hasn’t made any difference though.
Just now rebuilt my docker container to use latest stable release, and still the same troubles. Any ideas?
Anyone?
Strange, I am running the binding without problems under latest stable release.
Could you enable debugging, to get log details for your actual query response, to check why you would get the parse error?
