WTH isn’t there an easy way to make a last-30-days energy use sensor

Month of "What the heck?!"
#1

I want to be able to 1) draw pie charts of my energy use 2) see the evolution of my energy consumption. I am tracking a whole bunch of other things like this —- precipitation, coffee consumption etc, and energy per device.

For this something like energy used in period of time — ie a difference between a state of a sensor today vs eg 30 days ago from long term history — is necessary.

This can be done through the UI using an sql sensor, but it’s beyond most users. Utility meters are useless for this since they drop out of history after 10 days so you can’t even compare energy use this month vs last. And they are not really very representative of the typical use until after a week or two from the meter reset.

LTS is there to be used and the energy dashboard makes use of it very nicely. A new type of helper would be wonderful!

#2

Long term statistics might fit for that but it is still in development AFAIK and there is not much info / examples yet. Anyone correct me if I’m wrong.

#3

Yeah that’s my solution: I am using SQL to grab a sensor value from LTS, but many people don’t know SQL to do it.

#4

You can make a recorder entry to keep logs longer before the automatic purge process, that might at least be an start in helping. Look up “recorder:” in the online help - it’s an entry you woould add into your configuration.yaml. Doesn’t solve your problem, but starts to go in that direction.

#5

Yes I know, but once the data is collected, I want to make average sensors for e.g. last 12 months, last 3 months and last month, so that I can look at some kind of trends in e.g. energy use. The data is there, but it just isn’t very convenient to get it out. If I extend the recorder to 30 days, maybe my SSD is enough, but to 12 months, clearly not and there is no reason to keep 99% of the data for more than a few days.

#6

Long term statistics table (statistics) has the data per hour, so it should be relatively easy to calculate this on the fly without the need for extra sensors/entities/helpers or additional data records.
All the graphs and compare functionality in energy dashboard are also directly queried from this table.

So I imagine the compare functionality to not only compare to the last week/day, but a given period (in your case compare current with 30 days ago). The differences can be represented in graphs or textual. What also fits your request in this WTH.
There is also a separate WTH for that WTH, why can I only compare periods in the Energy Dashboard with the previous period? - #2 by Unlucky_Gagball.

#7

So I can do an SQL sensor to get the data out, but there should be a better way, indeed maybe without creating a new sensor which will just re-record practically the same data, but as you say on the fly. But currently there isn’t.

I think untying the bar charts which are being used in the Energy dashboard from the Energy dashboard itself would also go a big part of the way to deal with this. I’d like to be able to show this kind of long-term trend data for many things (e.g. rainfall) and the statistics card does not let me (if you use a bar chart, it only plots the sum column from the LTS database, not the period differences, which seems a crazy decision) – I feel a new WTH coming up.

#8

This can be done without sql via statistics if the recorder DB purge time is long enough, the sensor is a total_increasing type and it doesn’t roll over in the time period.

sensor:
  - platform: statistics
    unique_id: 'KWH_30D'
    name: "KWH Used 30D"
    entity_id: sensor.home_energy_meter_g2_electric_consumption_kwh
    state_characteristic: change
    max_age:
      hours: 720 
    sampling_size: 43200
1 Like
#9

Yes – but this is exactly what I am trying to avoid. I do not want to keep 99% of my entities for a long time. LTS solves this issue nicely, but there is no simple way to use it really.

Frankly, it would be a natural place that the statistics integration should be able to look back into LTS and allow some of the state_characteristics to use the long-term data.