Utility meter reports (daily/monthly/yearly)

InfluxDB (+ Grafana) is hack indeed but AFAIK the only way to do it right now. I don’t worry about different month lengths actually. As long as one month total is not less than couple of days of next month, the result is correct even with a slight shift. Correct x-axis legend is another issue.

For me it looks like the usage of attributes is the best way to keep long history inside HA, at least as long as Recorder treats all sensors the same way.

Some users already do similar things “manually” in configuration using Automation and Template sensors.

Utility Meter already keeps one historic point in last_period. It only needs a configuration parameter like keep_history to specify the amount of periods to keep and last_points or similar attribute for a list of measurements. Should be quite straightforward to implement in integration. And then someone with UI skills should make a Lovelace card for that.

But in general, I’d personally like to see similar functionality for every sensor: possibility to keep specified number of historic values instead of time based limit like it is in Recorder right now. So, maybe it should be a Recorder feature instead? :slight_smile:

1 Like

You can already do something like that. You can disable Recorder automatic periodic purge, and implement your own purge in SQL.

I can easily come up with a PR to support a configurable amount of last_periods if someone with UI skills can fill the blank of providing a proper UI.


Happy to help in anyway. This could be used for other things should as tracking a persons weight over time too.

I was thinking a little bit about graphs and isn’t it so that even existing graphs work out of box if there is enough data in database?

I haven’t checked it yet but I think that sensor that gets updated only once a day/week/month (via automation using last_period from utility for example) and not purged from database, should already show long term graphs.

Of course, then it is needed to run some external script or database procedure to do regular database cleanup instead of built-in purge.

Yes you are absolutely right. But it is a major hurdle to run the purges per entity yourself :frowning:

Interested to see the results of such work! Good job guys!

1 Like

Can you share the Grafana parameters, i’am struggeling with this a lot

You just select…

SELECT max("value") FROM "autogen"."W" WHERE ("entity_id" = 'power') AND $timeFilter GROUP BY time($__interval) fill(previous)

Hi @maxwroc in your first screenshot, how could you achieve the weekly usage with the mini graph card?

I only manage to achieve a daily usage. Only have the “Date” value available for the “group_by” property.

First of all you need to gave the utility meter defined in your config.

    source: sensor.energy_total
    cycle: daily

Then just follow the example from documentation of mini-grap-card.

Thxs for answering.

already have :

    source: sensor.qubino_goap_zmnhtdx_smart_meter_s4_s5_s6_energy_3
    cycle: weekly
      - peak
      - offpeak

does the tariffs atrribute make a différence?

The screenshot of mini-grap-card, I have posted, has daily usage not weekly.

I think it doesn’t make sense to display data for longer periods than 7 days (but TBH I haven’t even tried).

The problem here is that your mini-graph-card will need to fetch all the data for that period (every single value change) so it can be a lot of data. Mini-graph-card has some browser caching mechanism but if you login on the new browser / incognito-window / different device it will take some time to download everything from HA.

Downloading a lot of data is not the only problem. AFAIR (when I have done some changes in mini-graph-card) it caches the actual data - not the aggregates. This means on every page render it has to process all of the data. I guess it can kill/freeze your browser on slower devices.

The only reasonable option to show data for longer periods in HA is Grafana. It is processing and aggregating data server-side (in DB engine). But of course it has downsides as well (mentioned above).

In terms of the utility meter tariffs config - it doesn’t matter. On the end such configuration produces two separate sensors - each for every tariff. You can display them on separate cards or combine them in one as mini-graph-card is able to display multiple plots on single card.

Ok. Thxs for those explication.
I can see that it can freeze your browser. I understand the point.
I’d like to have a dashboard of my energy consumption for weeks and month.
I’ll try grafana with it’s own DB, you’re right.


I just came across the utility meter and reading the integration page I got a couple of questions. I have a E3DC photovoltaik solar power converter including a battery. From it I read current sensor data via a modbus integration. These read outs are provided in Watt [W]. One read out is the sensor.e3dc_power_consumption giving me the current power consuption in Watt [W]. Another one is sensor.e3dc_grid_power, which is also in Watt [W], but depending if power is moved into the grid (overproduction of the PV) or bought from the grid, the value may be positive, or negative.

How can I now track energy consumption [Wh] using a utility meter?
I would like to track one the energy consumption of the house and the energy consumption from grid (positive values only).

This thread is not for answering random questions about utility meter and related things. Please create a separate one for that kind of stuff.
Short answer for your question: it is not a good idea to compute Wh from W as this won’t be accurate for sure. Seek for help via new thread or find a more relevant one

Hello @dgomes, I found this conversation when was looking for utility meter report. After reading your message I started to think - why changes in the UI are necessary for the first iteration? Why the array is necessary? Looking back at my utility invoices and reporting ability of other IoT platforms, here is how I see the change request.

To me it looks like 2 small changes will greatly improve reporting ability of the Utility Meter component. Performance problems are also considered with this RFC.

First of all many thanks for this writeup! I feel little bit guilty that I have left this thread without traction and I’m very glad to see that kind of post here (proposal how to tackle the problem).

Let me just understand your suggestion. If I understand correctly you propose that utility-meter will expose sensor (e.g. sensor.pump_monthly_report) and recorder should be disabled for it. To store the data it should make a direct DB call. Is this what you are proposing?

If that is the case I see few potential issues:

  • Currently utility-meter is a regular sensor. It is just producing some values (it’s state) based on other sensor states. It doesn’t interacts with DB directly.
  • I’m not sure if direct access to DB is allowed
  • Recorder stores all it’s records in the tables which have a general purge settings so I guess we won’t be able to store such data in the regular tables
  • HA core team is doing table structure changes from time to time
  • So we will need to maitain special table in the DB, I assume we don’t want to have there any retention policy

Lets move our discussion under feature request - Anyone interested in a reports for Utility Meter? - #3 by palivoda

There are new features coming in the next version of HA :wink:

(check the commit logs related to statistics)

1 Like

Hey Diogo, are you talking about this: Initial draft of statistics (#49852) · home-assistant/[email protected] · GitHub

I don’t have a time now to check what exactly it is happening there but I will do it later. Thanks for the heads up!