Page 1 of 1

OpenURL HTTP postdata string behaviours with Tibber API

Posted: Tuesday 07 October 2025 10:08
by infoed
I'm using the OpenURL postdata string to send a GraphQL command to the Tibber API.
Tibber has a developer site https://developer.tibber.com/explorer where you can test if the postdata string is correct, that is, produces JSON result.

I come across that a GraphQL command in de tibber developer works but with the OpenURL returns no data.

This is the GraphQL command, this works in the developer site and returns JSON data:
{viewer{homes{consumption(resolution:DAILY,last: 31 ,after:"MjAyNS0wOS0wMQ" ){nodes{from cost unitPrice consumption}}}}}

This is the postData, which returns no data in Domoticz:
postData = '{"query": "{viewer{homes{consumption(resolution:DAILY,last: 31 ,after:"MjAyNS0wOS0wMQ" ){nodes{from cost unitPrice consumption}}}}}"}'

The OpenURL is:
dz.openURL({
url = endpointTibberAPI,
method = 'POST',
callback = scriptVar,
headers = {
['Content-Type'] = 'application/json',
['Authorization'] = 'Bearer ' .. accessTokenTibber
},
postData = <the above string with a valid GraphQL command>
})

The item.data section returns : RAW response data "item.data" was {"error":"syntax error"}
Again: when copy/past this GraphQL string in the tibber developer tool, I get NO error!

Note: when I remove the part with the quotes in the postData is works with OpenURL! That is, is returns JSON data.
E.g postData = '{"query": "{viewer{homes{consumption(resolution:DAILY,last: 31 ){nodes{from cost unitPrice consumption}}}}}"}'
(of course I have to remove the section (,after....) to have a clear GraphQL statement)

I suspect that DzVents does "something" with the postData string before is is executed, where the double quotes in the postData mess up the GraphQL string.
But I can't see this, when I set log-info to debug, domoticz shows the same string as I put in postData.

What can cause this? How can I debug the url which is sent by domoticz to this (any) API?

Re: OpenURL HTTP postdata string behaviours with Tibber API

Posted: Tuesday 07 October 2025 10:23
by waltervl
postData should be strings and for example in the format
node = "valuestring"
to get json
{"node":"valuestring"}

To debug you could use an application like wireshark to see what your system is sending over the network.

See also viewtopic.php?p=322121#p322121

Re: OpenURL HTTP postdata string behaviours with Tibber API

Posted: Tuesday 07 October 2025 11:13
by infoed
Thanks for the quick respons. Indeed, the postData is one string:
postData = '{"query": "{viewer{homes{consumption(resolution:DAILY,last: 31 ,after:"MjAyNS0wOS0wMQ" ){nodes{from cost unitPrice consumption}}}}}"}'

When I remove the quotes on the "after" keyword (like this after: MjAyNS0wOS0wMQ) it is not a valid GraphQL command for this API and the item.rawdata returns a "proper" errormessage:
RAW response data "item.data" was {"errors":[{"message":"String cannot represent a non string value: MjAyNS0wOS0wMQ","locations":[{"line":1,"column":61}],"extensions":{"code":"GRAPHQL_VALIDATION_FAILED"}}]}

With a proper GraphQL command (after:"MjAyNS0wOS0wMQ" ) returns RAW response data "item.data" was {"error":"syntax error"}

Note that this error seems to indicate not to be a GRAPHQL error, it looks like that the posted API string has a "syntax error".

I 'm going to try wireshark.

Re: OpenURL HTTP postdata string behaviours with Tibber API

Posted: Tuesday 07 October 2025 11:27
by waltervl
Dzvents is using this lua json library to convert the lua table postData into a json: https://github.com/domoticz/domoticz/bl ... e/JSON.lua

So in your dzvents script Postdata should define a lua table with the GRAPHQL data and not a json file.

Re: OpenURL HTTP postdata string behaviours with Tibber API

Posted: Tuesday 07 October 2025 11:42
by infoed
According to the tibber API doc, I have to wrap the query in a JSON object.
This is on their page https://developer.tibber.com/docs/guides/calling-api:


In order to issue this query to the server you will have to wrap the query in a JSON object:

{
"query": "{ viewer { name }}"
}
Note that the query is defined as a string property on the object (since GraphQL resembles JSON people often get confused by this).

You can use any HTTP client or cURL to issue the HTTP POST request to the server:

curl \
-H "Authorization: Bearer 3A77EECF61BD445F47241A5A36202185C35AF3AF58609E19B53F3A8872AD7BE1-1" \
-H "Content-Type: application/json" \
-X POST \
-d '{ "query": "{viewer {homes {currentSubscription {priceInfo {current {total energy tax startsAt }}}}}}" }' https://api.tibber.com/v1-beta/gql
Note that the API token is passed along to the server.

Going to try the CURL test first ;-)

EDIT: tested with curl, gave the same error. Going to contact Tibber DEV ;-)

Re: OpenURL HTTP postdata string behaviours with Tibber API

Posted: Tuesday 07 October 2025 12:36
by waltervl
waltervl wrote: Tuesday 07 October 2025 11:27 Dzvents is using this lua json library to convert the lua table postData into a json: https://github.com/domoticz/domoticz/bl ... e/JSON.lua

So in your dzvents script Postdata should define a lua table with the GRAPHQL data and not a json file.
Thinking of this you could store your JSON string in a variable and then in the open url say something like

Code: Select all

postData = JSON:decode(yourJSONstring)
So it converts your JSON into a lua table and then the openurl command converts the converted lua table into a JSON again....

Re: OpenURL HTTP postdata string behaviours with Tibber API

Posted: Tuesday 07 October 2025 14:01
by gizmocuz
Or you can use the build-in Enever hardware and choose 'Tibber' here...
Which option you choose, do mind the polling interval. There is no need to poll more often then twice a day for electricity and 1 time for gas.
Store the result in a variable, and use this variable. When you notice the date is not correct anymore in the variable (for example), load a fresh copy.
(I load mine at 00:01 and 14:01 and gas at 06:01)

Re: OpenURL HTTP postdata string behaviours with Tibber API

Posted: Tuesday 07 October 2025 17:14
by infoed
Solved it the help of Tibber Dev en Gemini ;-)

To fix this, you need to escape the inner double quotes with a backslash (\). This tells the JSON parser to treat them as literal quote characters inside the string, rather than as the end of the string.

So, with CURL it will be ...after: \"MjAyNS0wOS0wMQ\"
BUT, this fails in the postdata string/dzVents, you have to put extra backslashes: after: \\"MjAyNS0wOS0wMQ\\"

@gizmocuz: No, in this case the enever build-in will not work: it lacks functionality to request consumption and production data in a specific period in the past. With GraphQL and dzVents you get a lot more, in fact the whole Tibber API ;-)
Enever just delivers a small part of that API.

Note: the date notation used with the after keyword must specify base64 encode date string.

Re: OpenURL HTTP postdata string behaviours with Tibber API

Posted: Tuesday 07 October 2025 17:25
by waltervl
infoed wrote: Tuesday 07 October 2025 17:14
@gizmocuz: No, in this case the enever build-in will not work: it lacks functionality to request consumption and production data in a specific period in the past. With GraphQL and dzVents you get a lot more, in fact the whole Tibber API ;-)
Enever just delivers a small part of that API.
That data is also in your Domoticz P1 smart meter device....

Re: OpenURL HTTP postdata string behaviours with Tibber API

Posted: Tuesday 07 October 2025 18:46
by infoed
No, it aint. Tibber API data is richer, P! does not have tibber prices

Re: OpenURL HTTP postdata string behaviours with Tibber API

Posted: Tuesday 07 October 2025 18:56
by waltervl
It does when you do cost calculation within Domoticz (with the tariffs from Tibber).
Are you NL based?

Re: OpenURL HTTP postdata string behaviours with Tibber API

Posted: Tuesday 07 October 2025 19:12
by infoed
This is out of scope of this issue. This one is solved. I know the conts of the domticz P1*costs calculations. Another issue.

Re: OpenURL HTTP postdata string behaviours with Tibber API

Posted: Tuesday 07 October 2025 19:41
by waltervl
I know, just wanted to help. Sometimes people tend to over engineer solutions.... KISS is best.