Hi @mutmut,
I started integrating the ecocounter but I’m not sure about the result
I took the liberty of creating a new topic to make it easier to follow 
If you have a first release, I can test it on my installation.
I have an écocompteur ref. 412000 with firmware v3.0.17
I’m publishing a first release this weekend.
You can always create a dev image beforehand if you’re not sure about the result
If you followed the example template, there’s a GitHub action that allows you to release a dev image that anyone can install and test
I’ll look into how to do it. That’s exactly the part I’m less familiar with. Do I need to publish to Build on GitHub?
The first version is out
Ecocompteur installed 
My feedback:
- I am on Tempo (and TIC in historical mode) and it doesn’t seem to exist in the dev, the integration gives me a basic subscription:
- the names of the 5 circuits are correctly retrieved, I will test by changing one of the names to see the update
- on the subscription side, I see that the integration retrieves the subscribed intensity, is it possible to retrieve the 60A-12kVA subscription?
- NTARF indicates
8→ what does this correspond to? - tariff option indicates 2 → what does this correspond to?
- the 30-minute consumption and cost are linked to what?
And my Ecocompteur info:
On Jeedom, I was following the development of Bernard Dandrea.
He had made available a complete list of the elements that can be retrieved: documentation/jeedom-EcoLegrand/doc/fr_FR/JSON_codes.txt at main · bernard-dandrea/documentation · GitHub
I don’t see NTARF in it.
And I haven’t looked at your code but do you retrieve the TIC info in historical and standard mode?
Thanks for your feedback.
I don’t know what you mean by TIC in history and standard. I’ve only had Gladys for a week.
Actually, I retrieve the data.json and inst.json. Maybe you can send me your data.json and inst.json
{
« option_tarifaire » : 1,
« tarif_courant » : 2,
« isousc » : 45,
"conso_base" : 0,
"conso_hc" : 012378962,
"conso_hp" : 011243054,
"conso_hc_b" : 0,
"conso_hp_b" : 0,
"conso_hc_w" : 0,
"conso_hp_w" : 0,
"conso_hc_r" : 0,
"conso_hp_r" : 0,
"type_imp_0" : 0,
"type_imp_1" : 1,
"type_imp_2" : 1,
"type_imp_3" : 1,
"type_imp_4" : 1,
"type_imp_5" : 1,
"label_entree1" : "General ",
"label_entree2" : "PAC ",
"label_entree3" : "ECS ",
"label_entree4" : "Prises de Courant",
"label_entree5" : "Prises de Courant",
"label_entree_imp0" : "Gaz",
"label_entree_imp1" : "Eau",
"label_entree_imp2" : "Eau",
"label_entree_imp3" : "Eau",
"label_entree_imp4" : "Eau",
"label_entree_imp5" : "Eau",
"entree_imp0_disabled" : 0,
"entree_imp1_disabled" : 0,
"entree_imp2_disabled" : 1,
"entree_imp3_disabled" : 1,
"entree_imp4_disabled" : 1,
"entree_imp5_disabled" : 1
}
{
"data1":766.000000,
"data2":94.000000,
"data3":0.000000,
"data4":0.000000,
"data5":0.000000,
"data6":0.000000,
"data6m3":0.000000,
"data7":0.000000,
"data7m3":0.000000,
"heure":21,
"minute":11,
"CIR1_Nrj":0.000000,
"CIR1_Vol":0.000000,
"CIR2_Nrj":0.000000,
"CIR2_Vol":0.000000,
"CIR3_Nrj":0.000000,
"CIR3_Vol":0.000000,
"CIR4_Nrj":0.000000,
"CIR4_Vol":0.000000,
"Date_Time":1789938687
}
Consumption and cost for 30 minutes are automatically created by Gladys
For NTARF and Option Tarifaire, one corresponds to the base contract, HC/HP Tempo, etc., and the other to HC or HP
For the rest, I’ll take a look.
Ok for the retrieval. Isn’t there one of the two that needs to be configured? I don’t remember, but I know I used FTP to modify things.
It’s the Linky communication mode: either it’s historical and we retrieve some information, or it’s standard and we retrieve other information including electricity production and specific contracts (HC on weekends and in the evening for example), and the variable names are not the same between the two modes.
After that, I don’t know if the ecocompteur manages this automatically.
I agree, but they are linked to which index? (in kWh)
From what I see, it must be linked to conso_xxx from data.json
Ok, so is it possible to have something readable instead of numbers?
data.json :
{
"option_tarifaire" : 2,
"tarif_courant" : 8,
"isousc" : 60,
"conso_base" : 0,
"conso_hc" : 0,
"conso_hp" : 0,
"conso_hc_b" : 015354084,
"conso_hp_b" : 007357072,
"conso_hc_w" : 001951145,
"conso_hp_w" : 000923760,
"conso_hc_r" : 000913850,
"conso_hp_r" : 000335072,
"type_imp_0" : 0,
"type_imp_1" : 1,
"type_imp_2" : 1,
"type_imp_3" : 1,
"type_imp_4" : 1,
"type_imp_5" : 1,
"label_entree1" : "Hot Water",
"label_entree2" : "Cooling",
"label_entree3" : "Heating",
"label_entree4" : "Charging Station ",
"label_entree5" : "Power Outlets",
"label_entree_imp0" : "Gas",
"label_entree_imp1" : "Water",
"label_entree_imp2" : "Water",
"label_entree_imp3" : "Water",
"label_entree_imp4" : "Water",
"label_entree_imp5" : "Water",
"entree_imp0_disabled" : 1,
"entree_imp1_disabled" : 1,
"entree_imp2_disabled" : 1,
"entree_imp3_disabled" : 1,
"entree_imp4_disabled" : 1,
"entree_imp5_disabled" : 1
}
inst.json :
{
"data1":0.000000,
"data2":5.000000,
"data3":11.000000,
"data4":0.000000,
"data5":298.000000,
"data6":0.000000,
"data6m3":0.000000,
"data7":0.000000,
"data7m3":0.000000,
"heure":21,
"minute":38,
"CIR1_Nrj":0.000000,
"CIR1_Vol":0.000000,
"CIR2_Nrj":0.000000,
"CIR2_Vol":0.000000,
"CIR3_Nrj":0.000000,
"CIR3_Vol":0.000000,
"CIR4_Nrj":0.000000,
"CIR4_Vol":0.000000,
"Date_Time":1789940296
}
For option_tarifaire this should be possible
option_tarifaire
0 = base
1 = HC/HP
2 = Tempo
For tarif_courant it’s more complicated
tarif_courant
0 =
1 = Off-Peak Hours
2 = Peak Hours
3 =
4 =
5 =
6 =
7 =
8 = Blue Peak Hours
9 = White Peak Hours
10 =
Currently it’s blue off-peak and I’m on 5.
So the logic would be:
6: white off-peak
7: red off-peak
10: red peak
What about 0, 3 and 4 
tarif_courant
0 = Base
1 = Off-Peak Hours
2 = Peak Hours
3 = Normal Hours (EJP)
4 = Mobile Peak Hours (EJP)
5 = Blue Off-Peak Hours
6 = White Off-Peak Hours
7 = Red Off-Peak Hours
8 = Blue Peak Hours
9 = White Peak Hours
10 = Red Peak Hours
@pierre-gilles What information does the Energy Tracking integration need to function correctly?
Given that with the LEGRAND 1st generation ecocounter, the following information can be exploited:
data.json
{
"option_tarifaire" : 2,
"tarif_courant" : 8,
"isousc" : 60,
"conso_base" : 0,
"conso_hc" : 0,
"conso_hp" : 0,
"conso_hc_b" : 015354084,
"conso_hp_b" : 007357072,
"conso_hc_w" : 001951145,
"conso_hp_w" : 000923760,
"conso_hc_r" : 000913850,
"conso_hp_r" : 000335072,
"type_imp_0" : 0,
"type_imp_1" : 1,
"type_imp_2" : 1,
"type_imp_3" : 1,
"type_imp_4" : 1,
"type_imp_5" : 1,
"label_entree1" : "Hot Water",
"label_entree2" : "Cooling",
"label_entree3" : "Heating",
"label_entree4" : "Charging Station ",
"label_entree5" : "Power Outlets",
"label_entree_imp0" : "Gas",
"label_entree_imp1" : "Water",
"label_entree_imp2" : "Water",
"label_entree_imp3" : "Water",
"label_entree_imp4" : "Water",
"label_entree_imp5" : "Water",
"entree_imp0_disabled" : 1,
"entree_imp1_disabled" : 1,
"entree_imp2_disabled" : 1,
"entree_imp3_disabled" : 1,
"entree_imp4_disabled" : 1,
"entree_imp5_disabled" : 1
}
inst.json
{
"data1":0.000000,
"data2":5.000000,
"data3":11.000000,
"data4":0.000000,
"data5":298.000000,
"data6":0.000000,
"data6m3":0.000000,
"data7":0.000000,
"data7m3":0.000000,
"heure":21,
"minute":38,
"CIR1_Nrj":0.000000,
"CIR1_Vol":0.000000,
"CIR2_Nrj":0.000000,
"CIR2_Vol":0.000000,
"CIR3_Nrj":0.000000,
"CIR3_Vol":0.000000,
"CIR4_Nrj":0.000000,
"CIR4_Vol":0.000000,
"Date_Time":1789940296
`}
I had forgotten about that famous EJP
To answer (I hope correctly), the integration is based on indexes to calculate a 30-minute consumption and a 30-minute cost, which means we will base it on all conso_xxx.
For now, it will not be possible to generate 30-minute consumption and cost for the 5 tores because these are instantaneous powers (W) and not consumed energies (kWh) (indexes for simplicity).
In the ecocompteur, the indexes of the 5 tores are retrievable but they become incorrect over time. The main problem is that these numbers are based on 6 digits (hardcoded in the code) and when they increment, they lose precision.
The jeedom plugin allowed for a reset every night at 23:59 to always have good precision of the day’s index.
But a reset means you have to store the previous value and add it to the new one, that’s the first challenge.
The second challenge is being able to retrieve these indexes and they are not accessible via data.json and inst.json, you have to create a new well-formatted json (see my links above), send it to the ecocompteur via ftp at the time of creation for example, and then you can retrieve the indexes.
From there I think the ecocompteur integration will handle the rest for the 30-minute consumption and costs.
I think we need to validate the plugin with the data.json and inst.json first.
Then we will need to look into « creating » the indexes of the 5 tores (that’s what I would like to monitor).
Small question, could you tell me if your Linky is in standard or historical mode? (you have to click on the Linky buttons to scroll and see the info).
Because I don’t know if this old Legrand thing knows how to handle standard mode, and if it does, it should be indicated in the documentation.
@mutmut version 1.2 online
Fixes Tempo detection, adds readable labels and precise index accuracy
- option_tarifaire : 2 recognized as Tempo (confirmed by a real user feedback with /data.json as evidence), in addition to the never-before-seen 4 kept as a precaution. Fixes the bad detection that made Tempo installations fall back to a simple Base index. - Tariff option and current tariff published in readable text (« HC/HP », « Tempo », « Heure Pleine Bleu »…) instead of raw code or the NTARF badge, which means nothing to anyone. - Conversion Wh → kWh without loss (division by 1000, 3 decimal places) instead of the old rounding to the nearest tenth, for a more accurate 30-minute consumption calculation on the Gladys side. - Doc fr/en: table of the 6 Tempo indexes and their automatic consumption/cost tracking, correction of the minimum refresh interval (1 s, not 10 s).
Thanks @Goldorakiller for this release, tempo is well present!
I updated yesterday and the indexes, consumption, and cost seem good:
The indexes are rounded to the unit compared to what I have in the ecocompteur:
If the consumption/cost calculations are done based on the values with decimals, then the rendering is good; otherwise, there may be a slight difference.
I just changed the name of one of my tores and it seems there is no check and update.
I restarted the integration and there is no change.
And I have some weird things with a lot of spaces in the technical parameters for each parameter:
Claude’s response:
Rounded index units
Don’t worry, it’s just the display. Since version 1.2.0, the integration publishes the index with 3 decimal places, and Gladys stores them as is. It’s the display function that rounds according to the size of the number: an integer beyond 1000 kWh (hence 15383 for 15382.79), one decimal between 10 and 1000 (hence 923.8 for 923.76). The calculation of 30-minute consumption and costs is done on the stored values, with the decimals. So it’s fine on that side.Renaming a meter
You’re right, and our documentation was wrong, sorry. In Gladys, once the device is created, the names of its features belong to you (like the device name or its room). A subsequent rename on the ecocompteur is not taken into account, even after restarting the integration or new discovery. The simplest solution: rename « Heating » to « Heat Pump » directly in Gladys. Deleting and recreating the device also works, but you would lose the history. The documentation is corrected for the next version.Large spaces in « Technical Settings »
These are not integration parameters. The ENERGY_INDEX_LAST_PROCESSED_… are the markers that Gladys creates itself for its energy calculation, one per index (hence the 7 in your case). The layout comes from the Gladys screen: if it bothers you, it’s worth reporting it on the Gladys repository.What’s coming in the next version
An energy index per meter: the ecocompteur only gives the instantaneous power of its meters, so the integration will rebuild the kWh consumption of each. Gladys will automatically add the 30-minute consumption and cost. You will therefore be able to track what your charging station or heat pump costs. It’s an estimate, calculated between two readings, which starts at 0 upon installation.
A « Live Power » dashboard widget, thanks to the new features of Gladys 5.1: the 5 live meters, their total and the current rate colored (blue, white or red in Tempo). By the way, the widget takes the name displayed on the ecocompteur, so it will follow your renaming.
You will need Gladys 5.1 minimum for this version. To take advantage of it: Integration Discovery tab, then « Update » (no need to delete the device, the history is preserved). I’ll let you know as soon as it’s published, and your feedback in Tempo will be precious to validate the index per meter!
Hi @Goldorakiller
Thanks for this last release which is really great!
Live Power Widget:
Graph with the calculated energy of each torus, We might need a bit more data to determine if the calculation is correct or needs improvement:
What’s interesting is that the Devices page of the integration gives the old names of the tori (which we find on my graphs) while the widget takes the renamed names in the ecocompteur. I specify that I created all this after renaming the tori in the ecocompteur.
Tempo Energy Tracking Comparison
And a few differences (0.7kWh) but which balance out over the 2 days:
From what I see, there was probably a mistake on the ecocompteur with the last hour of the previous day and the first two of the current day.
Anyway, I approve!
Thanks for your feedback!