Holy crap, it has been so long time since Ive looked into this. Haha is the bounty still up?
Apparently.
Regardless, the main intention was to generate a working Tibber binding for OpenHab.
Wow, Great!
I Will be testing this at the first available time 
Then you are entiteled for reciveing the bounty, will look into this later
Error while starting bundle: file:/C:/openhab-2.4.0/addons/org.openhab.binding.tibber.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.tibber [292]
Unresolved requirement: Import-Package: com.google.gson; version="[2.8.0,3.0.0)"
at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(From post above: Link, there is a link to the README file which explains what has to be done if error related to gson is occurring during initialization.
From openhab/karaf console, run:
bundle:install http://central.maven.org/maven2/com/google/code/gson/gson/2.8.5/gson-2.8.5.jar
Then you should be able to initialize the binding.
19:57:04.664 [INFO ] [tibber.internal.handler.TibberHandler] - Connecting to: wss://api.tibber.com/v1-beta/gql/subscriptions
19:57:05.026 [INFO ] [tibber.internal.handler.TibberHandler] - Connected to Server
19:57:05.175 [WARN ] [tibber.internal.handler.TibberHandler] - WebSocket Connection closed due to Connection error
19:57:05.238 [WARN ] [tibber.internal.handler.TibberHandler] - Closing a WebSocket due to Disconnected
19:57:13.256 [INFO ] [tibber.internal.handler.TibberHandler] - Connecting to: wss://api.tibber.com/v1-beta/gql/subscriptions
19:57:13.534 [INFO ] [tibber.internal.handler.TibberHandler] - Connected to Server
19:57:13.672 [WARN ] [tibber.internal.handler.TibberHandler] - WebSocket Connection closed due to Connection error
19:57:13.737 [WARN ] [tibber.internal.handler.TibberHandler] - Closing a WebSocket due to Disconnected
Hmm can there be a problem when the user has multiple homes in tibber?
Based on your log, you get connected, but as part of connection_init request to actually start data stream, Tibber API responds with error in its first response message. This would point in the direction of incorrect token used in the setup.
However, the binding might not be set up to handle multiple homes, so for sure, this could be an issue.
From https://developer.tibber.com/explorer, if you log in and “load personal token”, how many id´s are listed if you try to run the query below?
{
viewer {
homes {
id
}
}
}
Also, using “personal token”, choosing “Real time subscription” from dropdown menu, what is the result when running subscription (see my example below)?
Then I have prepared a new version of the binding to be able to handle multiple HomeIds / Pulse. Now the user has to define both Tibber token and Tibber HomeId as part of OpenHab setup. Desired HomeId to be used as input in OpenHab could be found from https://developer.tibber.com/explorer: Sign in with your account, load personal token, and run query as shown below:
{
viewer {
homes {
id
}
}
}
Copy and paste HomeId (without quotation marks) into OpenHab setup. Choose desired HomeId/Pulse addon combination.
For users with multiple HomeIds: It would be of great interest to test creating multiple Things in OpenHab, i.e. one Thing per HomeId.
1 Like
I can confirm this works perfectly 
Only issue i see is selecting home id, i kinda had to guess they show in order when quiering
https://developer.tibber.com/explorer
{
viewer {
homes {
id
}
}
}
The correct query to be run from https://developer.tibber.com/explorer to identify your HomeId and to see which id has the Pulse associated (realTimeConsumptionEnabled will report true) would be:
{
viewer {
homes {
id
features {
realTimeConsumptionEnabled
}
}
}
}
Will update documentation accordingly.
1 Like
New version of the Tibber binding:
https://github.com/kjoglum/openhab2-addons/releases/download/2.0.1/org.openhab.binding.tibber-2.5.0-SNAPSHOT.jar
Improvements:
- Documentation for pairing HomeId with Pulse (if having multiple HomeIds / Pulse)
- Verification of valid HomeId before setting Thing ONLINE, and attempting to start live stream if user has defined Pulse as addon
- Corrections to code to ensure data is retrieved for chosen HomeId only
- Option for user to add multiple Tibber things, i.e. one Thing per HomeId
- Updated Readme file explaining how to retrieve token and HomeId (also described in posts above), and example of demo.items to link items to Thing(s)
Note:
If you already are running a version of the Tibber binding, the following approach would be recommended for updating to new version:
- Delete existing Tibber thing in PaperUI
- Delete existing jar from addons folder
- Reboot OpenHab
- Install new jar file into addons folder (from link above)
- Install new Tibber Thing(s) in PaperUI
- Create/link items to Tibber Thing(s)
3 Likes
Outstanding work 
1 Like
Great work @kjoglums!
I just tried the binding, and I could only get parts of it to work. My setup is a single account with 2 homes, thereof one with a Pulse.
I got some data in the PaperUI - probably regarding 1 of the homes. No data on the Pulse; from the log “WebSocket Connection closed due to Connection error”
I suggest a slight redesign of the Thing setup as I guess the current setup does not support multiple homes:
- Tibber Account as the bridge thing
- Subscription (or Home) as the thing reflecting the subscription
- Pulse as a separate thing - connected to a Subscription (or Home) thing
What do you think?
Cheers, Arne
Appreciate the feedback. Will evaluate your proposed changes. See the benefit of using bridge / autodiscovery of HomeIDs. At the same time, autodiscovery could cause some issues for some users. For a test case above, for a user having 4 HomeIDs, 1 regular account, 1 with Pulse, 2 HomeIDs were inactive/reporting null values.
The current setup/configuration is intended to give the user most flexibility, i.e. to manually choose which HomeID to track. And it is possible to add more Tibber Things manually in PaperUI, i.e. one Thing per HomeID. In PaperUI the user defines which HomeID to track for each Thing, and defines Pulse as addon from dropdown menu if connected (the code will also verify before actually attempting to live stream).
If you have Pulse connected, and go to https://developer.tibber.com/explorer (sign in / load personal token) and run query below you will see which HomeID to input in PaperUI to get live measurements from Pulse. If you are providing correct HomeId / Pulse combination in PaperUI I do not understand why you do not get websocket connection / live data.
{
viewer {
homes {
id
features {
realTimeConsumptionEnabled
}
}
}
}
Still haven’t been able to test, hoping to get some time for testing the coming Week.
I Would also like to suggest that the Production items are added (gjetting solar panel installed in January).
And voltage and current items Would also be appreciated 
No problem to add additional channels to the livestream, so will have a look and update 
Reason for not including voltage/current initially is because Tibber writes that Kaifa and Aidon meters only reports value every 10 seconds, otherwise null. When testing using https://developer.tibber.com/explorer, this is actually the case for me. However, no problem to include channels and only perform channel updates if/when actual values are received.