It’s very promising, but I have to be patient before displaying my info on the dashboard: the calculation of consumption and costs for my history is at 3% after 30 minutes, so it will take me about fifteen hours! With a Zlinky and around twenty connected plugs, I suppose that’s normal
However, I wanted to share two aspects of my user experience when setting up this integration, in case it helps:
The docs say you can « see the hierarchy of your electrical network » and that you should « verify that each device is correctly associated with its parent ». I think I roughly understand what that’s about, but I’m not so sure, and I think there could be an explanation at this step of the docs that explains why there is a hierarchy, what it will bring, and what typical hierarchies look like. The example given with the Nous plug is a bit ‹ light › for that.
For example, at my place I have an Enedis integration, a Zlinky meter, a measurement plug of consumption that actually tracks the production of energy from my solar panels, and about twenty smart plugs that measure consumption, some of which are ‹ stacked ›. For example, I have a consumption plug ‹ multimedia › at the input of a power strip, and several other consumption plugs per device on that power strip (the monitor, the amp, …). And I’m not sure what hierarchy I should set up
Okay I admit I might be pushing this a bit…
Also, when I updated the Zlinky in the Zigbee integration, then went into the Energy integration, the 6 EASFxx indexes (I’m on Tempo) didn’t have clear names (HC Bleu, HP Bleu, HC Blanc, …). Could this be because I first migrated to 4.66, then to 4.66.2 (because I think I saw that you had improved some things on that, Pierre-Gilles, but maybe the two successive updates didn’t make that available to me…). I don’t know if it’s possible to make the naming clear automatically?
Keep us posted as soon as it’s calculated, I’m curious about the result
The idea is to establish a hierarchy based on what is plugged into what.
If a plug is plugged into another, then the “parent” plug should be placed above in the hierarchy, and the “child” plug below.
In the long run, this will allow reconstructing the actual consumption correctly without double-counting, especially when multiple devices are “stacked”.
For now, this capability is not yet used but it will be useful later
So there are two things
Until now, I didn’t really understand the EASFxx thing (you must be in standard mode). I’m in historical mode, and my Lixee TIC returns BBRHPJB, etc. If you can give me the meaning of each EASFxx, I can integrate them properly into Gladys!
However, these clearer new names will only be used for new devices paired in Gladys. I can’t allow myself to overwrite existing feature names: if a user has renamed their data as they wish, it would be a bit harsh to replace everything for them…
We could now also add a small helper in the Zigbee2MQTT interface to display explanations specific to this device, which, let’s be honest, is a bit complex for everyone (myself included ).
From what I’ve seen in Gladys, all the standard TIC indexes/names already exist in an MQTT device named « Téléinformation » (including the EASFxx) but not in historical TIC (which could be an improvement, I think).
The EASF can change depending on the energy provider you have:
EDF Tempo then we use EASF01 to EASF06 for HCJB, HPJR, etc.
TotalEnergies’ super off-peak hours: HP, HC and HSC, so we use EASF01, 02 and 03 only
EDF base: EASF01
EDF HP/HC: EASF01 and EASF02
etc.
I think it’s difficult to have specific names for the standard TIC knowing that if you change operator, EASF01 will move from the old subscription to the new one (but what about the meter reading …).
While looking this morning to try to get all of this up and running, I saw that there is an MQTT ‹ Energy production › feature. Is this handled in the energy section we’re talking about here?
If so, is it possible to create the two ‹ 30 minutes › there automatically in the same way as the other indexes?
I’m watching this development from a bit of a distance to begin with, because I own solar panels whose API I use to retrieve my consumption / production.
But the cost calculation side with peak / off-peak hours is really super interesting!!
The consumption calculation did indeed take 15 hours, and now I’m waiting for the cost calculation 18% done in about 6 hours…
OK for that, it’s clear and I understand the logic to avoid double-counting with consumption measurement outlets.
But can you confirm what I should do for the ‹ components › Enedis, Zlinky, and the solar panels’ production measurement: should the three be at the same level 0, and then all my consumption measurement outlets be under Enedis? By default, Gladys did that: everything (Zlinky, solar panels, and each consumption measurement outlet) is a child of Enedis.
For me, I have this:
EASF01 = Off-peak Blue (external ID = zigbee2mqtt:Compteur Zlinky:teleinformation:easf01:current_tier1_summ_delivered)
EASF02 = Peak Blue (zigbee2mqtt:Compteur Zlinky:teleinformation:easf02:current_tier2_summ_delivered)
EASF03 = Off-peak White (zigbee2mqtt:Compteur Zlinky:teleinformation:easf03:current_tier3_summ_delivered)
EASF04 = Peak White (zigbee2mqtt:Compteur Zlinky:teleinformation:easf04:current_tier4_summ_delivered)
EASF05 = Off-peak Red (zigbee2mqtt:Compteur Zlinky:teleinformation:easf05:current_tier5_summ_delivered)
EASF06 = Peak Red (zigbee2mqtt:Compteur Zlinky:teleinformation:easf06:current_tier6_summ_delivered)
I admit I have no opinion, it’s up to you to decide what you want to do The advantage of the Lixee is that you plug it in and it works right away; the API requires a bit of work, up to you
No, make everything a child of Enedis, otherwise you’ll have to create a contract per device at the root (the contract is attached to a device)
Thanks, but then @mutmut said earlier that these same features are not necessarily from Tempo, so I don’t know if we can do much unfortunately
Thanks for this great feature. I think I did things in the wrong order (after reading the docs ), and ran into a strange bug.
I have the Zlinky and 4 Nous Zigbee plugs, and I first created the hierarchy, created the contract, and started the calculations, before “updating” the devices in the Zigbee-to-MQTT integration (for the new features). After doing that update, the Zigbee devices completely disappeared from the hierarchy… But the most problematic thing is that when the background task for the cost calculations (re)starts, the CPU goes to 100% and the GUI becomes unreachable, forcing me to restart the container. I had to disable the energy monitoring service.
Is there any way to clean up my mess and reset all the settings of the new integration to start over more cleanly?
Detection of circular dependencies to prevent deadlocks
Switch from « currency » to « kWh » and dynamic units for currency (euro and dollar)
DuckDB updated to v1.4.3
MQTT
Fixed a bug where numeric values were not parsed as « number » when using a custom topic, which displayed an unrounded raw value in the interface.
Fixed a bug: if a scene listens on the same topic as an MQTT device with a custom topic, deleting the scene no longer cancels the topic subscription for the MQTT device.
Following the messages that @mutmut sent me in private, and @Terdious’s very positive tests on modifying DuckDB’s memory limit, I have just published release v3.66.4.
This version reduces DuckDB’s maximum RAM usage limit, which goes from 80% to 30%, to leave more headroom for the system and Gladys.
This offer is not supported, and worse, we won’t be able to handle it with a simple contract defined in JSON on GitHub. We’ll have to code special logic because of the whole weekend and public holiday thing
Weekends are simple, but public holidays are hell And don’t tell me you live in a region with specific public holidays, that would be the icing on the cake
The advantage of the Lixee is that you plug it in and it works right away; the API requires a bit of work, up to you 
), and ran into a strange bug.
And don’t tell me you live in a region with specific public holidays, that would be the icing on the cake 
