but what i am seeing is that first thing in the morning it retains the count from the previous evening, in fact the only time this history stat clears for the current day is when the sun goes above the horizon ?!
Hmmm, unless your HA thinks you are somewhere completely different I do not think that is it. And on second thought, sun would probably have been off then too.
I might disable the sun integration for a few days and see how it goes, just to rule it out.
I had checked it before going to bed one night, and again in the morning (6/7am) and even though the boiler had been running for 30 minutes (5:15 - 5:45 and the boiler entity shows this also), the history stat does not reflect this. then after 8am the history stat displays 0 runtime for the day and will count the next interval i put the boiler on like it should !?
Reset on the 14th was when i manually set the entity to 0 as a test, after that it only seems to reset around 8am.
The code is ok, right ? in that it should only display runtime since midnight (start of current day ) which should be zero if boiler hasn’t run, and 30 minutes if it has as that’s all it is currently set for
A.f.a.i.k. the code is right. You could put the template for the start time in the developer tools to make sure. It should give you a time of 0:00 in the right timezone (only millis are not reset, it annoys me but it doesn’t hurt).
The start time does seem to have shifted from before 6:00 am to after, more so than the sun integration would have caused. Did you change anything inbetween?
It is not the graph rising I’m looking at, but the drops. They happen when the history sensor starts at a new period (should be when the start time equals the end time=now). Oct 13 it is about 5:00 am, oct 15 it is more like 8:00 or 9:00 am. Oct 16 is even later.
That’s interesting, like history stats fails to reset when there’s no changes to the source our something like that. I would guess a bug if it were’n that I have similar sensors behaving just fine (though with a 3:00 reset and not 0:00).
ya. I have disabled the sun integration, and will monitor it for a few days just to see, if problem persists, i shall delete the entities/stats and run for a few days more before trying again and hoping for the best.
just a quick update for anyone following, I have disabled the sun integration, and last night (this morning) at 2 minutes past midnight, it was still displaying yesterday’s run time instead of zero so I performed a reboot.
It then calculated correctly and displayed zero.
I checked it this morning and it had correctly tracked today’s runtime.
Sun up now, and nothing has changed/reset.
Will monitor it for a few days, and if there are no issues, I’ll try reinstating the sun integration and see how that goes.
Does anyone know if it’s possible to force the history stat to update via a service call?
so everything was tracked correctly yesterday (previous post).
After midnight the history stat should have reset to 0, but still displayed the same value(the value that would’ve been the previous day’s entry as it was after midnight).
As per the image below, it seems that the history stat maintained this value until the boiler came on for the morning cycle, and when that state change occurred (boiler coming on for 30-minute morning cycle), the history stat reset, but did not track that 30-minute cycle, but- did begin to track the next cycle ?!
Does anyone know why this might be happening?
Since you mentioned my post in the OP, I’ve been following this. Twice now I’ve compared your entity definition with mine, and everything looks the same. I’ve confirmed that mine is still working as expected. I’m at version 2022.9.6.
I’m stumped. The only thing I can think of would be to create a totally new history_stats entity, with a different name, and try to duplicate the problem. At least that would eliminate any problem with the database. If you can consistently duplicate it, you could then start changing the start time and see if you get the same thing resetting hourly, and change the entity_id to something you can manually set.
Thanks, CaptTom,
I will give this a try in the coming days. What I have done as an interim solution was to create an automation that reloads the history stats service at 12:01, and although not ideal, it does function.
I’ll post back to let people know how I get on.