Are we doing this right? @Kai
Looks all fine - now you only have to find some developer, who’d be interested to do the work and earn the bounty. I don’t have any good recommendation on how to achieve this best…
I’ll try to put togheter something
Maybe we can find any of the other binding creators, to look at this? Then we can offer the bounty to them? IT should be easy peasy with all the information provided by the api-documetation available.
What is really good is that the binding can be developed with the demo api Key. Witout having to own a Tibber pulse.
@pauli_anttila really like your work on the rfxcom binding. Any idea wo would want to claim this bounty? Or help us Tibber users out? Noone of us have any binding building experience
I’ve also added an issue for this in the openHAB issue tracker so it’s easier to find:
Any news on this topic?
Hey there, i am a developer but very new to both openhab and tibber. so i could maybe lookinto creating something if somone already havent. but i need some explanation on how it should tie together.
also i am very green to the hole openhab stuff also. to even what the different type of addons are and stuff. if anyone create a slack channel to talk about it. i will join. i hate forums tbh
I have started to look into this as well, however, my programming skills are somewhat limited, although having become familiar with binding structure / Eclipse IDE.
So, for a start, I have a clean skeleton for the binding. Now planning to use HttpUtil to handle the GraphQL requests. Further need to look into how to implement Oauth bearer (token) for authorization. Also how to make use of websocket for subscription to live data.
For me, as a start, it would be desired to get communication and be able to read data in OH. Guess persist could be used for getting graphs etc.
As a follow-up: Still in an early phase on my behalf, trying to set up/configure a binding:
Thus seeking some input/advice:
What input/channels would be desired? Would queries set up at frequent polls be sufficient, or would the continuous/live measurement be the only successful achievment?
I guess ‘current price’ is the ultimate variable to get updates for at regular interval in OH in order to take actions for other implemented OH components, but will be happy to get some other ideas/desires.
Awesome that you started to look into this!
I don’t have a y device that reports my real-time consumption to the tibber app, so I’m interested in getting the energy price. However, if I would’ve had it I would’ve required as close to real time values as possible.
With the energy price i would draw two graphs, today’s and tomorrows energy prices per hour. As you say the current energy price (the current hour) is a must, but for the graphs I would need also today’s and tomorrows energy price ( maybe that’s what you mean by the current price). I don’t know what possibilities there are, but 24 values (one for each hour) in some format would be great.
Also I scrolled through the API documentation (not that I understand the details) and it looked like there was some value available for high/low energy price that would be nivlve to get
Glad to help out as much as it’s worth without the technical understanding
Then I believe I have an initial version ready to test:
Requires Tibber personal token as manual input as part of binding initialization (retrived by logging in to personal Tibber account): https://thewall.tibber.com/Account/Login?
Also, as part of initialization, user defines the desired refresh interval (minimum 1 minute) as to how often the binding is polling data/measurements.
Current Features of binding
Home ID retrieval
Current Price (hourly)
Will enable persistence in OpenHab, thus enabling graph options for historic price.
Report total cost and consumption from last/previous day.
Report total cost and consumption from last/previous hour.
I assume resolution for consumption, i.e. last/previous hour, is too infrequent, but is apparently the best we can achieve from polling method. In order to get more frequent updates (real time), websocket connection would be required, and a more complex binding structure would be required.
Also, extension of the binding would be required to get “future” price data.
Please feel free to test the binding and report back issues/improvements.
I was going to test this, but turns out I’ve forgotten how to use OH (I think) I added the .jar file to the addons folder as you can see below. But the binding doesn’t show up in the console (also screen shot below). What am I missing? I’ve tried to reboot OH, but no luck…
EDIT: I’m running OH 2.4 stable on a RPi3b (Raspbian), do I need to upgrade to 2.5 perhaps?
Your approach of adding the jar file to the addons folder seems right, so not sure why it does not start automatically (did start automatically and became active for me, as shown below).
Note: Please download the latest version from the link, I identified a bug which is corrected into a new jar file.
Have you tried (from console):
bundle:install -s file:/usr/share/openhab2/addons/org.openhab.binding.tibber-2.5.0-SNAPSHOT.jar where you change the path to your path of the addons folder?
After upgrading to the latest Milestone build of 2.5 it’s working. I also downloaded the latest build of the .jar. The binding is there now in PaperUI. Now for my next noob question. How do I get the Token from thewall.tibber.com? I suspect that I should use chrome dev tool and use the RequestVerificationToken, but it’s not working. Am I completely out in the blue?
Good to hear! I am still running OH 2.4 stable release, and the install worked as supposed to.
Go to https://thewall.tibber.com/Account/Login? in your regular web browser (no need using dev tools), log in to the page using your Tibber account credentials, and there the token key is available/visible as “copy to clipboard”.
Then just input the token as part of binding initialization.
Just an update:
Struggle with a bug, as the response from Tibber is sending
null response for hourly cost/consumption right around hour transition.
Thus, need to evaluate refresh time, and will also check alternative handling of response in the binding.
Also, the websocket solution for realtime measurements would be the preferred solution, but havent’t been able to dig into this approach yet.
I believe I have found a workaround for the
null response from Tibber around hour/day transition, thus I have replaced the jar file to be downloaded (from the link provided above).
Hi @kjoglums, where can I find the jar file?