History Stats and graph card not calculating correctly

Hi All - I hope someone can help me…

I have created a template sensor (history_stats) to record time / day that my heater is on. The data in the sensor looks good and is correct but…

If I use either the build-in statistics graph card or a custom card and use the statistics data, it does not calculate the max/day correctly.

If I use a custom card and use group by the calculations and data/chart is correct.

raw data view from sensor history attached plus the chart using statistic graph card. In the config for the graph card, I have daily max in the config.

What am I doing wrong?

1 Like

Does the history stats sensor generate long term statistics?

Good question! I think so. I just followed the instructions for the creation of the sensor template (history_stats). If I go to developer tools > statistics I can see all three that I have created.

If I use a custom card (e.g. RomRider apexcharts-card) and use the statistics function, it works but is incorrect data. The built-in Statistics Graph Card also returns incorrect data

If I use apexcharts-card but use group_by function, I can get the right data to display but will need to test how far back in time the data goes…

Thanks for helping by the way. Many of your posts have helped me get started with HA so big thanks!

Ok that’s definitely proved that it does generate LTS.

My guess is that it may be a time zone issue. i.e. the daily maximum may be using UTC time for the day instead of your local time.

Have you set up your time zone in Settings → Sysyrem → General ?

Also what installation method do you use?

If it is a VM of any type the system time zone has to be correct too.

The time zone of the system you are running your web browser/app on may have an effect too. There is now a setting in your profile (circle icon bottom left menu) to set the display to the server time rather than the web browser time.

I had already set time to use server as i noticed time related stuff was playing up when overseas on holiday a few weeks ago

I have a number of date/time sensors and they all return the correct date/time so I think its all ok - see below. I can confirm time is correct!

image

My install is via a docker container - i am using the latest and correct source for the container.

Check out my heating dashboard - very proud of it. The wife thinks i’m crazy haha.

Took a load of work as the heater is basic but has a remote control with on/off so I use an IR blaster and created a template switch that turns it on and off. Limitation is that it’s not possible to get the actual state of the switch but I found a solution to that too!

Does the system that the docker containers are installed on have the correct time settings?

100% yes. have worked through all of these things I think. I will double check the actual container and see if I find anything weird.

Looks fine volume in the compose file for the container uses the host time/date. host time/date correct with correct timezone configured

volumes:
  - /etc/localtime:/etc/localtime:ro

Hi,
It looks like the daily reset of your sensor is after midnight. Therefore you have the old max value on the next day, if the next day is not higher. You see, that August 4 and August 5 is correct, because the max of August 5 is higher than August 4. But August 6 is wrong because the value for that day is lower.
I have the same issue with an entity that comes from Homematic which is there reset at 0:00 but until it arrives in HA it can be 0:00:30 and then you have the old value in the next day…
I am also still looking for a good solution for this problem.

Interesting. So if i set the sensor day reset at 11.59pm, would this potentially help?

actually - thinking about this a bit more, why would group_by day (max) work and statistics by day not work?

I think there is something in what you are saying. Looks like the reset takes 31 seconds. But why? That is strange and must be a bug.

I will change my history_stats sensors to start at 11.59pm and see if this resolves the issue

Please keep me updated, as I have the same issue.
How can you set the reset time to 11:59pm?

You’re not running Home Assistant on a Mac mini by any chance?

Nope. on a RPi - works great with HA so far

I am using my own template sensors using the The history_stats sensor platform so I can do what I like within the scope of the platform. I think it will be more challenging for you but you might be able to take a similar approach.

I have changed the start variable by converting it to a time stamp and removing 60 seconds

from this:
start: " {{ now().replace(hour=0, minute=0, second=0, microsecond=0 ) }} "

to this:
start: " {{ as_timestamp( now().replace(hour=0, minute=0, second=0, microsecond=0 ) ) - 60 }} "

lesson I just learnt was to test it works in dev tools > template before saving the config and restarting. haha

I will see if this fixes the problem at about 11.59pm tonight :slight_smile:

Another (shorter) way:

start: "{{ today_at() - timedelta(minutes=1) }}"

wow. That’s great.

Do you have some similar ones for:
1 minute before the start of the current week
1 minute before the start of the current month

mine are as follows…
{{ as_timestamp( now().replace(hour=0, minute=0, second=0, microsecond=0 ) ) - ( now().weekday() * 86400 ) - 60 }}

{{ as_timestamp( now().replace(day=1, hour=0, minute=0, second=0, microsecond=0 ) ) - 60 }}

{{ today_at() - timedelta( days = now().weekday(), seconds = 60) }}

Not a lot shorter:

{{ now().replace(day=1, hour=0, minute=0, second=0, microsecond=0 ) ) -  timedelta( seconds = 60) }}

By the way, if you are using history stats for an entire month you need to adjust your recorder purge keep days setting. It is only 10 days by default.

Great. Thanks. I have just setup the weekly and monthly sensors so I hadn’t seen the impact of purge.

I have history stats for my weather integration going back 3-4 months - from when I first started playing with HA. How is this possible?

I also see what you are doing with the time stuff - keeping the data as date/time rather than timestamp. makes sense to me now