Hello,
I don’t know since when, but all my utility meters are resetting one hour too early, which cause my meters to be off. This is the case with the dailymeters, but also the hourly meters.
What can cause it to reset at 23:00:00 instead of 00:00:00?
Thanks
Rick
I suspect the timezone. Your meter names sound Dutch but the reset timestamp has a UTC timezone.
Yes I thought the same, but my timezone is correct. GMT+1, Amsterdam.
I changed the utility meter from yaml to a helper, let’s see if this solves the problem.
Unfortionatly this was not the sollution. Does anybody have an idea?
I experience the same problem, only with a two hours shift (resetting at 22.00 instead of 00.00) on (several) utility meters resetting on a daily baisis.
And, yes, my time zone i correct…
Running Home Assistant 2023.8.2, Supervisor 2023.08.1, Operating System 10.4
Did you fnd any solution?
Regards,
Chr.
Are you sure that you have a problem?
As I understand it, the last_reset attribute is shown in UTC time.
What is your time zone?
And what is shown as the History of the Utility Meter?
This is an example of my daily water usage Utility Meter History graph:
And this is the accompanying last_reset attribute:
last_reset: 2023-08-18T22:00:00.038782+00:00
When the time zone is GMT+01:00 and it is DST there is a time difference of + 02:00 from UTC ( when it is 22:00 in Greenwich it is 00:00 local time).
This means that the last reset occurred at 2023-08-18 at 22:00 UTC, which is 2023-08-19 at 00:00 local time.
So, at least in my case, it is working perfectly.
You’re right - it works as it should.
I export data to a txt-file and was looking at the timestamp.
Have now added a different field with the actual time and that one shows the meter is reset at midnight as expected.
I’ve also seen the utility meter to reset earlier and mess up with the data :
The daily resetting helper however re-rest correctly :
they both show similar last_reset value :
meter_period: monthly
cron pattern: 0 0 1 * *
last_reset: 2024-03-31T23:00:00.007521+00:00
unit_of_measurement: kWh
device_class: energy
friendly_name: Electricity Monthly
meter_period: daily
cron pattern: 0 0 * * *
last_reset: 2024-03-31T23:00:00.021553+00:00
unit_of_measurement: kWh
device_class: energy
friendly_name: Electricity Daily
Has anyone also experienced this ?
The last reset value, as stated earlier, ends with +00:00. That means it is not local time but UTC. If your timezone is +01:00, then this time is equal to 2024-04-001 00:00:00.021553 in local time. So if this was for instance in winter in the Netherlands you are fine.
Also note summer time has just begun. So now the time zone for example in the Netherlands is +02:00. If a time from a few days back is interpreted using the current offset of +02:00 then things may look weird. So it may be the time it reset was right, but displayed unexpected/wrong. Or you may be reading UTC notation the wrong way.
Strictly speaking it not helpful that we are accustomed to reset daily/weekly/monthly counters on local time. Because of it, and summer/wintertime, not all days are 24 hours, and not all weeks are 24*7 hours. It is also not helpful that 365 is only dividable by 5 and not 12 and that February is so short. We can blame the Roman Emperor Augustus for that. But now I’m ranting 
.
Thank you, yes the last_reset time seems fine as it’s in UTC, however, the graphs show the monthly utility meter to reset at 23:00 ( +01:00 my local time ) , but only for the monthly resetting helper, the daily resetting helper does show the values correctly at 00:00.
It does seem to be related to the summer-time change as it was showing the correct value in previous months.
I am not sure how to correct the monthly helper as it now shows incorrect values for last month.
Same problem here.
Not only the Utility Meter reseted one hour early, but it has recorded also wrong status.
and it is correctly reported in console:
What need to be configured in order to align the time zone used everywhere (cronjobs, hystory, etc…)?
No, that is not what is said. The reset is executed local time but is recorded by converting it to UTC, which looks weird but is the only way to do it right.
You need to convert it to local time to interpret it. It is hard to interpret right, even harder if you just changed between summer/wintertime. The 31st of march is exactly the date that the switch occurred. It may be the graph shows it wrong, because the day is split across two different time offsets because the offset changed at 2:00 AM.
So don’t look at the graph, it may be wrong. Look at the UTC time that the utility meter was last reset. Add to that the time offset that was relevant to that date at 0:00 to interpret when the reset took place in local time.
Until now no one has shown any conclusive evidence the utility meter acted weird when the time zone was set right. The only thing weird seems to be last_period. Maybe that is having a hard time when a summer/winter time change happens at the end of the month.
In my case, the last_reset time for both daily resetting and monthly resetting utility meters are 2024-03-31T23:00:00 +00:00 , however the monthly resetting utility meter seems to be recorded differently, apart from looking at the graph, also checking the states table in the database :
Monthly :
Daily :
Also, some other template sensors using the monthly utility meter were writing their values with the re-set meter’s values from one hour earlier, so the actual reset did happen earlier.
To me it seems that the utility meter is acting weird, what would be conclusive evidence I can provide ?
