On top of that
A graph that allows stacking HP and HC indices. (I specify because today we can’t do that)
In graphs, the ability to select a live data point.
I like the mockup 
In a broader reflection, wouldn’t it be better to separate the counters from the integrations? That would allow everyone to select their data source.
Something like this (to be defined for the color codes)?
All the work I’m doing on the Enedis API is « generic » as usual, I use a category and a type that already exist in Gladys (ENERGY_SENSOR)
We should coordinate so that this work is applicable to the work you did on the Lixee TIC, and on the MQTT integration so that it’s open to any external data import.
What category/type are you already using on the Lixee TIC?
Exactly
All the indexes have this type, so we’re good
Ok, and we’re agreed on the Lixee TIC data side — if on the Gladys side I do a (roughly):
SELECT SUM(value)
FROM device_feature_state
WHERE device_feature_id = 'xx'
AND created_at >= '2022-12-01 00:00:00'
AND created_at <= '2022-12-01 23:59:59'
Do I get the day’s consumption in kWh?
No — you need the last reading of the day; if you sum them we’ll mess up the consumption figures.
Ok, so it’s not exactly the same data as Enedis!
We need to distinguish the two with a different type.
On the Enedis side, I have access to 2 APIs:
Consumption load curve: This sub-resource returns the values corresponding to measurement days of a customer’s consumption load curve for each day in the requested period. The returned values are average power consumption values over the meter’s measurement interval (default 30 minutes). Each value is timestamped. The load curve is obtained for full days from midnight to midnight of the following day in local time. A call can cover at most 7 consecutive days. A call can request data dating back at most 24 months and 15 days before the call date.
Daily consumption: This sub-resource returns the values corresponding to the daily consumption (in Wh) for each day in the requested period. Each value is dated. A call can request data dating back at most 36 months and 15 days before the call date.
On your side, basically you have a variable that is always the sum of the previous variable and the consumption that has occurred since then?
It’s the meter index; it always increments, yes that seems to be what you’re describing (there is no operation, it’s the meter that provides the value)
11H00 12456
11H08 12458
11H22 12459
etc..
Ok, in that case it’s really a completely different job to calculate consumption and price ^^
The work I’m doing on Enedis will not be applicable to Linxee TIC, we’ll need to do special work to be able to deduce hour-by-hour/daily consumption data from the meter index.
[quote="pierre-gilles, post:20, topic:747
hello,
quick question: is this Enedis integration like Lixee? Only valid if you have a Linky meter? Nothing for those not equipped with Linky?
Enedis needs to have the consumption data to make it available daily (there’s time info too I think), so yes, a communicating meter is required.
The difference with the Lixee TIC is that it’s not real-time.
Ah thanks for the note, I didn’t know! Any other specifics to be aware of?
Not like that, nope ^^’
But when I saw the mockup I told myself he probably doesn’t know ^^
There are contracts with the Tempo option, but I’m not sure that gets reported to Enedis.
I second Spenceur’s remark because it’s the same for me: two off-peak (HC) periods
I can’t wait to see how this integration turns out because I already have my Solaredge integration (solar panels) and I’d like to see more precisely what’s happening on the Enedis side
Are you self-consuming or a producer?
Not sure I’ll code production management in the first iteration of this feature, it’s a separate API on the Enedis side, it’s really extra work
For now, for the first iteration I’m focusing on consumption
Self-consumption 
That wasn’t a disguised feature request 
I’m just interested in data in the broad sense! Great work in any case
