Hello,
Tonight, I will look at creating an integration to read Gaz consumption data from the distributor’s website.
I think I will start from what has been done here: GitHub - ssenart/home-assistant-gazpar: GrDF Gazpar meter integration for Home Assistant · GitHub
There is another solution that no longer seems to work: GitHub - vingerha/gazpar_2_mqtt: Revamp of the abandoned gazpar2mqtt · GitHub
I’m all ears for any other suggestions.
My recommendation, the simplest thing is to create an empty repo and then type this into Claude:
In this repo, I want you to create an external integration « GRDF Gazpar » for reading gas consumption data.
Start from the official integration template: GitHub - GladysAssistant/integration-template-js: Gladys Assistant Integration template for a JS external integration · GitHub
Then let him surprise you 
I don’t think it’s a good idea to suggest a technical solution to him, generally he’s better than us at it and imposing a solution « restricts » his reasoning 
Have fun!
Hello,
The integration is coming to the store. It allows you to track via counter:
| Feature | Category | Unit |
|---|---|---|
| Daily consumption | energy sensor | kWh |
| Daily volume | volume sensor | m³ |
| Meter index | energy sensor | m³ |
| Average outdoor temperature | temperature sensor | °C |
Just one issue that Claude indicates is specific to my meter. The outdoor temperature is never populated. At worst, I remove this data; it seems to me that many of us have outdoor temperature sensors (more relevant in my opinion).
I’m all ears 
just an idea, but if the person doesn’t have an outdoor sensor, is it possible to get the temperature from the weather?
It’s not 100% accurate, but it can help if it’s needed.
By the way, for my personal information (I don’t have gas), what is it used for?
Is it to calculate the DJU?
From my understanding, temperature is just an indicator that helps to better understand gas usage when it is used for heating your home. In winter, this is obvious: as temperatures drop, gas consumption increases.
Then, in Gladys, as far as I know, it is not currently possible to create a graph with two types of representation (e.g., a histogram for gas consumption and a curve for temperature). @pierre-gilles, am I wrong? Otherwise, I can create a feature request if it doesn’t already exist
@PhilippeMA, don’t forget to add a cover to your app!
I made a special release for this, but it didn’t go through… I just noticed that the image size wasn’t correct (>800x534). I just redid the whole process, I hope it will be okay now
Edit 13:50: It’s all good now!
@PhilippeMA: Thanks for this integration that is very useful to me
I noticed a consumption error for some months: for example, May 2026 does not display the same consumption depending on the display period
And I also don’t have the meter reading or the temperature (but I don’t know if I have a sensor)
Hello @Chris75,
You can go to the integration settings and click on « Refresh data now »; normally you should see your index appear on the dashboard. This only happens after the integration is installed; and as GRDF only updates the information once a day, the integration only updates every 6 hours by default.
Regarding the average temperature, I have the same problem… I’ll check to see if it gets fixed, otherwise I’ll remove it. As mentioned earlier, this is informative data to explain gas consumption; I think we already have this data elsewhere on Gladys and certainly more relevant than the one provided by GRDF.
I’m also reproducing at home what you’re seeing on the graph. It seems to me that the data displayed for the first month displayed does not correspond to the entire month.
If you make the same graph with a daily granularity, you will see that the month of May starts on 14/05 so I think that when Gladys does a monthly aggregation, it only cumulates the data between 14/05 and 31/05 hence the gap you are seeing.
Can someone confirm? (@pierre-gilles)
Ouch, that’s ugly. How many days did you put in the configuration? (History to import (days))
If it’s a three-digit number, try setting it to 10; since you’ve already imported the data, the depth no longer matters.
I’ll look into fixing it. Thanks for your feedback
There’s no need to look because the configuration had indeed kept the initial number (1000 days) that I entered the first time: I set it to 10 and it’s fine now!
Perhaps we could add a warning to reduce this number once all the history has been loaded?
why can’t we use the « energy consumption » widget the same way we do with electricity?
This wasn’t planned during development.
As usual, the only thing to do is to open a feature request.
ok, but is this a feature that affects external integration or Gladys?
Hello @cicoub13,
I forwarded your comment to Claude. I’m not sure about the relevance of his response…
Here is his reply:
The ongoing correction:
The manifesto and the two documentation files. The new field wording:
Never sent to your browser once saved, and only transmitted to GRDF. Like any Gladys setting, it is stored as-is in your server’s database.
And the « Privacy » section of the EN/FR docs now details the consequence: anyone with access to the server or a backup can read the password, just like any other identifier entered in Gladys. I also specify that GRDF does not offer individuals an API key, token, or application password — the account password is the only entry point, making the information all the more useful to know.
What hasn’t changed, and why:
There’s nothing to improve on the integration side: the SDK sends us the value in plain text, and GRDF requires it in plain text for login. Encrypting on our end would only shift the problem — we’d have to store the key in the same container. The only real progress would come from the core (encryption at rest of variables) or from GRDF (a token-based authentication mode); neither is within our control.
He changed it to say that the password was not encrypted (that’s normal behavior). Thanks, at least the user isn’t misled
