Hello,
I have daily and monthly utility meters. Data is saved into influxdb as well.
I would expect the daily meter to accumulate the energy value and only save the value to the database once a day, and the monthly one to only save the value once a month.
However, the utility meter value is updated constantly, more than once a day, or once a month. This increases disk space usage in influxdb and home assistant for no reason.
Anyone can let me know if this is the proper behaviour and if there is any fix for it?
Thanks in advance
Here is my configuration:
As you can see below, the utility meter is saving lots of records to grafana. I am only interested in the value at the end of the day (for faily) and at the end of the month (for monthly):
It accumulates for the cycle period then resets to zero at the end of the period.
There’s a reason. Half way through a month I want to be able to see the value accumulated so far. I don’t want to have to wait until the end of the month for a value.
If you only want one value stored at the end of the cycle, use a template sensor or automation to record the utility meter just before the end of the cycle.
Thanks for the info,
I understand it can be useful for some users.
Someone on Github has suggested to dowsample data in influxDB in order to only keep the max value for each day.
I will look into that and post it here in case someone else is in my situation
Regards
I wanted to integrate exactly this behaviour.
Do you have the code ready for that? I am motivated to try, but i probably going to end up with very inelegant code…
I created a script with pyscript integration to do a daily cleanup of all intermediate values of my utility meters.
I am using postgres as a database and use following queries to achieve this. The queries each scan for the max value of the cycle and deletes the rest.
# Utility meter with cycle 5mins
DELETE FROM states where entity_id = 'sensor.energy_mains_usage_5mins_peak' and state_id not in (with a as (select *, ROW_NUMBER() OVER (PARTITION BY date_trunc('hour', created) + date_part('minute', created)::int / 5 * interval '5 min' ORDER BY state desc) as rn from states where entity_id = 'sensor.energy_mains_usage_5mins_peak') select state_id from a where rn = 1);
# Utility meter with cycle 1hour
DELETE FROM states where entity_id = 'sensor.energy_mains_usage_hourly_peak' and state_id not in (with a as (select *, ROW_NUMBER() OVER (PARTITION BY date_trunc('hour', created) ORDER BY state desc) as rn from states where entity_id = 'sensor.energy_mains_usage_hourly_peak') select state_id from a where rn = 1);
# Utility meter with cycle 1day
DELETE FROM states where entity_id = 'sensor.energy_mains_usage_daily_peak' and state_id not in (with a as (select *, ROW_NUMBER() OVER (PARTITION BY date_trunc('day', created) ORDER BY state desc) as rn from states where entity_id = 'sensor.energy_mains_usage_daily_peak') select state_id from a where rn = 1);
# Utility meter with cycle 1month
DELETE FROM states where entity_id = 'sensor.energy_mains_usage_monthly_peak' and state_id not in (with a as (select *, ROW_NUMBER() OVER (PARTITION BY date_trunc('month', created) ORDER BY state desc) as rn from states where entity_id = 'sensor.energy_mains_usage_monthly_peak') select state_id from a where rn = 1);
# Utility meter with cycle 1year
DELETE FROM states where entity_id = 'sensor.energy_mains_usage_yearly_peak' and state_id not in (with a as (select *, ROW_NUMBER() OVER (PARTITION BY date_trunc('year', created) ORDER BY state desc) as rn from states where entity_id = 'sensor.energy_mains_usage_yearly_peak') select state_id from a where rn = 1);
Thanks for sharing this Sven! I think utility_meter is great but I probably haven’t read enough about the behaviour before using it.
There’s a reason. Half way through a month I want to be able to see the value accumulated so far. I don’t want to have to wait until the end of the month for a value.
Doesn’t this give you duplicate records for:
cycle: hour
cycle: day
cycle: week
cycle: month
cycle: year
These entities reset at their given intervals but still popuplate the database:
RESULT: 10 days = around 120,000 records in the states table. EXPECTED: 240 (hours) + 10 (days) + 2 (weeks) = 252.
The reason I started using utility_meter is that it would reduce the crazy amount of db records
(with 12 records for the monthly usage, 52 for the weekly usage, etc.) Should have done a better job investigating
If you only want one value stored at the end of the cycle, use a template sensor or automation to record the utility meter just before the end of the cycle.
It looks like the only solution is to create a few hundred template sensors (not just for utility_meter) with the right behaviour and exclude all “real” sensors. Ouch…