[tibber] Breaking change in Tibber API websockets

[toini]

Hi!

I would like to thank you for contributing to the community of Tibber users! We've added you to the list of people we respect! https://developer.tibber.com/respect

In order to improve the API resilience we are making a breaking change for websocket communication. Please see details at developer site. Would you be able to adjust the implementation accordingly?

Also, it looks like you are not setting user-agent header value. A recommended format would be to include both the platform version and driver version for example like this: OpenHAB/1.2.3 tibber_driver_version/1.2.3'

We're trying to collect best practices here

Let us know if in need of any assistance!

Br, Toni Tibber

[lolodomo]

@kjoglum for information

[kjoglum]

Will make an effort to create an update.

But in short, having looked briefly at the breaking change for the Tibber API, it looks for me like the required changes would be:

• Query for the dynamic subscription URL rather than using fixed URL (provided home is realTimeConsumptionEnabled)
• Add user-agent (platform version/driver version) to Header
• Set subprotocol to graphql-transport-ws rather than graphql- subscriptions

[toini]

Thanks for such a quick response @kjoglum! You are right on the first two items but the third is a bit more complex than just adjusting the subprotocol header value.

The new protocol in use has slight differences to the previous. Connection init message structure changed a bit (type is subscribe, not start and token is passed as json value) and returning message type is next instead of data. You can see how things have changed in the Tibber .NET SDK

That should pretty much be it but now I'm recalling there was some issue with encoding the value for id. I think it is now required to be a string and an integer value would not go through.

[toini]

I should probably compile a list of required changes for implementing the new protocol. That would be

1. Subprotocol name graphql-transport-ws
2. Connection init message format structure and type (type is subscribe not start, token as json object not string)
3. Returning message type (next, not data)
4. Id must be string

[toini]

Easy way to see how the new protocol now works is to try it at developer.tibber.com with browser tools

[kjoglum]

@toini I have made changes to the Tibber binding according to discussion above, but I am unable to establish successful stream. I am querying the subscription URL, and get to the point where I get @OnWebSocketConnect and pass the connection_init message, with token as before (similar to the message shown in your image above). However, instead of receiving connection_ack, as for the current/working version of the binding, I now end up with @OnWebSocketClose with message Invalid message received.

You stated that the connection_init message has changed, but following your image above, the protocol seems to still follow:

• connection_init (passes along token only)
• receive connection_ack from tibber server
• send message for subscription (type subscribe, not start, otherwise desired parameters to stream)

For the last message in the bullet list I have changed from start to subscribe, otherwise same as before (id set as string, default "1"). Still, the problem seem to occur as part of the connection_init message.

EDIT Probably related to how the token is passed. Appears like the code isn’t adapted correctly wrt token pass as json value.

[toini]

Yeah a change there is that the token should be passed as a json value instead of a string.

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/issue-with-websocket-connection-to-tibber-api-after-new-year/143140/2