Skip to content

Conversation

@jenskdsgn
Copy link

The PR aims to quick fix the breaking changes introduced by the tibber API

https://developer.tibber.com/docs/overview#breaking-websocket-change

This API initially supported GraphQL websocket subscriptions using graphql-ws sub-protocol. However, that library is archived and no longer maintained. Thus, on March 31, 2022, support for graphql-transport-ws sub-protocol was added.

After brief research the it felt like exactly the opposite, that graphql-transport-ws would be the deprecated one.
The graphql library that was picked only supports graphql-ws, so I hope they accept my PR to add the other subprotocol as well. For the time being, I pointed my the reference to my repository with the fix in the graphql library. Once their PR is merged we can point it to the official one again. I guess this is better as to have a fully broken exporter.

This was the error message I encountered:

Starting subscription for homeId e9b4af2f-a55c-49ab-af78-da422855c551
Suspending thread waiting for task Gather
Subscription connection error (server rejected WebSocket connection: HTTP 404)
Voiding subscription for e9b4af2f-a55c-49ab-af78-da422855c551

I compared the websocket messages with Tibbers GraphQL playground and found the mismatching ws subprotocols.

Also they have changed the GraphQL Subscription URL. It would be better to get them dynamically from the GraphQL query API. My Python skills didn't allow to also do that quickly so I just updated the URL.

@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
No Duplication information No Duplication information

@Pelleplutt
Copy link
Owner

Pelleplutt commented Jan 14, 2023

Thank you for this @jenskdsgn. The changes for this are very attractive from the tibber-exporter's standpoint (just a header obviously), I will not merge this however until the changes in python-graphql-client has been accepted.
I should say also that I am about 90% done with rewriting this myself by switching to the gql client (which already has support for the graphql-transport-ws.

That is a much larger rework however and also includes some other changes. I have run into some asyncio problems that I have not had the time to work out properly. I pushed this WIP just now in new-api-202212 for the sake of collaboration. If I can sort out these problems I will likely move to this solution as the https://github.com/graphql-python/gql package seems more complete.

@jenskdsgn
Copy link
Author

Thanks for the update on this. If you need anyone to discuss high level ideas or if you want some general feedback ping me. As I said I am not a python expert but maybe there is other parts where I can help.
I update this PR once I hear anything from the other project.

Maybe we can get ahold of an engineer at tibber to explain why the breaking change of the websocket subprotocol was introduced.

If you are rewriting, this repo might also be nice for inspiration.

@jenskdsgn jenskdsgn closed this by deleting the head repository Jun 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants