Energy tracking is coming soon to Gladys ⚡️

[pierre-gilles]

Hi @gaetanb76, for now I’m not handling this contract via automatic import.

Do you know if there’s any open data on the historical tariffs for this contract?

I have the impression that only the tarifs bleus (blue tariffs) are publicly accessible on https://www.data.gouv.fr/datasets/historique-des-tarifs-reglementes-de-vente-delectricite-pour-les-consommateurs-residentiels/

[Francis66]

Thank you @Terdious and Pierre-Gilles for this development. This is exactly what I’m looking for to monitor my consumption and production and to estimate the impact of electric charging on energy consumption.

[pierre-gilles]

Hello everyone,

This morning I worked on adding the automatic import of rates from the open-source database of electricity contracts that I created the other day (GitHub - GladysAssistant/energy-contracts: Gladys Assistant Energy Contracts as JSON).

In the integration, there is now an « Import » button:

This button asks you to select the relevant electric meter, then presents the available energy contracts.

This list comes from the crowdsourced JSON in the repo above.

The idea behind this JSON is that anyone can submit a PR to propose a new contract if their contract isn’t in the list.

I think that’s the power of open source: making everything editable by the community!

Then, when you click « Import rates », it creates all the current and historical prices corresponding to that contract:

In the case of EDF Tempo, for example, there are 30 rates per power level, so it’s much more convenient to be able to import them automatically

[pierre-gilles]

FYI, I started work on calculating 30-minute consumption from the meter readings

I ordered a Lixee TIC to have something to test with:

[bertrandda]

Very nice development, thank you both.

@pierre-gilles

Then, when you click on “Import tariffs”, it creates all the current and historical prices corresponding to that contract:

What happens when a tariff changes? Is Gladys synchronized with the repo (repository) or is it just an initial import and when EDF changes its tariffs, does everyone have to update their instance manually?

I’ve been wondering for a long time about changing contracts — could we imagine, in the long term, being able to temporarily see the cost we would have paid with another contract? For example, if I’m on off-peak/peak (HC/HP) I’d like to see how much it would have cost me over the last year if I had had a Tempo contract and check whether it’s worth switching. Of course the results shouldn’t be taken as perfectly reliable since usually if you switch to Tempo you make extra efforts to reduce your bill (by shifting usage, reducing consumption…), but it would give an idea.

[pierre-gilles]

@bertrandda

What happens when there is a tariff change? Is Gladys synchronized with the repo or is it just an initial import and when EDF changes its tariffs, does everyone have to change it on their instance manually?

For now it’s just an initial import but yes the idea is to have periodic synchronization!

@bertrandda

I’ve long wondered about switching contracts — could we eventually imagine being able to temporarily see the cost we would have paid with a different contract?

Yes, ultimately that’s the goal

[pierre-gilles]

@Terdious you’re going to be happy, for calculating consumption from an index I handle cases of « counter reset » (and therefore negative values), I just have a small question about the calculation!

Let’s take an example history:

• 1000
• 1005
• 10
• 15

What is the consumption for this history?

The « subtle » case here is that we didn’t manage to capture the reset exactly (which was most likely reset to 0, not to 10).

Two options in my opinion:

1. We assume the reset happens at 0, and therefore we calculate here (1005-1000) + (10) + (15-10) = 20
2. We only calculate what we observe, and therefore we don’t take into account that there is an invisible 0, and so we have: (1005-1000) + (15-10) = 10

I’m leaning toward option 1, but open to feedback

[StephaneB]

I didn’t follow the whole discussion in detail, so I apologize in advance if I’m off the mark…

Strictly speaking, when one device replaces another, I also think there are two points:

• an uncertainty about the final value of the meter reading before the reset: it may have risen to 1010 before being changed without having the opportunity to transmit that value.
• an uncertainty about the new initial value: if the value is low one could assume it started at 0, indeed. But it has already happened to me to replace a smart plug by another that had already ‹ lived › and whose consumption index therefore wasn’t zero… This new value could even be higher than the previous index.

So at worst it could look like this:

• …
• 1000
• 1005
• last value before replacement, but not transmitted: 1010
• replacement
• first value after replacement, but not transmitted: 2000
• 2005
• 2010
• …

Would it be possible to set up a mechanism to signal that we’re going to replace one device with another? And I would then be of the opinion that Gladys should only consider the meter readings it actually sees.

In my example above, the consumption taken into account by Gladys would therefore be ‹ up to 1005 › and then ‹ from 2005 ›, it’s up to the user to do their best, when possible, to trigger data reports just before and just after the replacement.

[Terdious]

@pierre-gilles

@Terdious you’re going to be happy, for the consumption calculation from an index, I handle the cases of “meter reset” (and therefore negative values), I just have a small question about the calculation!

Great!! That’s awesome ^^

@pierre-gilles

Two options in my opinion :

1. We assume the reset goes to 0, and so here we calculate (1005-1000) + (10) + (15-10) = 20
2. We only calculate what we observe, and therefore we don’t take into account that there is an invisible 0, and so we have: (1005-1000) + (15-10) = 10

I’m leaning towards option 1., but open to feedback

@StephaneB

an uncertainty about the new initial value: if the value is low we could assume it started at 0, indeed. But it has already happened to me to replace a smart plug with another that had already ‘lived’ and whose consumption reading was therefore not zero… This new value could even be higher than the previous reading.

At first I agreed with you on option 1, it’s always annoying not to count a data point.

But that’s exactly what experience shows, and @StephaneB puts it well, I think most use cases would involve replacing one meter with another, and in that case, it’s better not to count because the margin can be significant. Option 2 is safer, and too bad for the data we don’t have, it’s better than false data I think. Right?

@StephaneB

I didn’t follow the whole discussion in detail, so I apologize in advance if I’m ‘off the mark’…

No, you’re on the right track ^^

[pierre-gilles]

Thanks to both of you for your answers, indeed option 2 seems quite secure because we don’t fabricate consumption.

If we take into account that the index is sent every 60 seconds for example, we only lose 60 seconds of consumption, which is negligible compared to the error of counting « 0 → New index ».

I’m going with that!

[prohand]

I also have the lixee in v1
If you want to run tests I can do so without any problem

[StephaneB]

If I understand correctly what you’re going to do, it will automatically handle (and with a rather negligible error) the sequence of values 1000 => 1005 => 5 => 10 (by detecting that there was a device change). But how will that be detected if the new device already has a high index and Gladys sees the sequence 1000 => 1005 => 2005 => 2010?

[pierre-gilles]

@StephaneB

But how will it be detected if the new device already has a high index and Gladys sees the sequence 1000 => 1005 => 2005 => 2010?

It won’t be detected, and it can’t be detected!

[pierre-gilles]

Hello everyone!

I’ve made good progress on the energy monitoring, I’m now able to calculate 30-minute consumption values from the meter readings

@Terdious I’d like to run a test using the data you sent me — could you send me your energy tariffs, for example for June 2025? I’ll run a local test with the CSVs you sent me.

[Terdious]

Hello @pierre-gilles !!

Top news !!^^

Below is my August bill for the June-August period (I remind you it is not real because it is a catch-up of the difference spread over the year). I therefore note:

• HP : 0€22404 (05h

[pierre-gilles]

Thanks @Terdious !

I imported the CSV files you sent me by email into an MQTT device “Index”.

I imported:

• raw_energy-active-alimentation-generale-totale_2025-06.csv
• raw_energy-active-alimentation-generale-totale_2025-07.csv
• raw_energy-active-alimentation-generale-totale_2025-08.csv

I created 2 rates with the schedules you gave me :

I’m running the algorithm from the start, and I get this :

![Screenshot 2025-10-10 at 17.12.57|665x500, 50%](upload://4shmwsOKpW53xb4aPkuwW6qj13

[Terdious]

That seems pretty good to me. I started installing my new panels on July 10, continued on July 25 and finished in early August with the addition of a battery.

We went on vacation in August but there are people who look after the house during the summer while we’re away + the campsite that’s running + the pool.

My consumption isn’t lower in summer than in winter, but with the addition of the 10 kW of panels, it seems very good to me — it’s about what I had on Home Assistant (HA).

Well done.

Can’t we yet view the consumption/price for peak/off-peak (HP/HC)?

[pierre-gilles]

@Terdious

Can’t we yet view the consumption/the price for peak/off-peak (HP/HC)?

No, that part hasn’t been developed yet

[pierre-gilles]

Hi everyone!

I’d like to update you on this development that has kept me busy these past few weeks

What’s ready

• Enedis : The integration is now fully compatible with this development. The integration downloads consumption in 30-minute intervals from Enedis, and successfully calculates consumption in euros. It’s tested at my place on my production setup!
• Zigbee2mqtt : The integration now automatically creates the entities/features for 30-minute consumption and 30-minute cost, and automatically links each device to the meter configured in the integration « Energy monitoring » (« Suivi de l’énergie »).
• Consumption calculation from indexes : Now fully functional — every 30 minutes, Gladys calculates the consumption over the last 30 minutes for all « index » features and stores it. This consumption in kWh is then used to calculate consumption in euros.

On my system, it looks like this:

On the dashboard:

What’s super convenient is that I can display graphs per device:

A chance to see that a washing machine uses almost nothing

What’s left to do

1. The dashboard view currently cannot display multiple devices on the same chart, which is necessary for example to combine multiple indexes. In the case of the Lixee TIC for example, there are 6 indexes if you are on Tempo, and for now you have to make 6 charts — not very practical
2. The chart doesn’t yet handle the subscription price; for now it’s consumption only.
3. The overall UX can be improved to make it very easy to configure.
4. The « energy production » panel that we discussed with Terdious hasn’t been started at all.

Conclusion

Now the question is: When is it acceptable to release a first version?

In my opinion, points 1 and 3 are necessary for a first release, and after that it can go live — this integration is already really useful, I already use it at home!