Petro thank you very much for your explanation. Everything is clear now. For me I agree with Edwin that the data should be “unknown” or “0”. It should not give us a wrong data when there is no database to check. Interestingly the data comes up as it should with other newly created stats such as:
This is again monthly stats for being away from home. The code is selected from the 1.st day of the month and the template was also created yesterday. The result comes up as normal. It starts to count from day 1 and when there is no data until yesterday it shows as 0.
But my home status template behaves different. Anyway for now I solved it as pulling the date to yesterday(12th) as you proposed. Thank you very much.
You still aren’t understanding how it works. away is showing a small number because away is not the first state in your database. You’ve already proven that home was the first state in your database in your other post. That means, this is what’s happening:
Be aware that if you create a history stats sensor for “away”, it does not always mean “away from home”. If you create more zones, the state could also be “school” or whatever other zone you care to define and go to. This caution also applies to state triggers and conditions in automations. It is safer to use from: home than to use to: away.
If you look at this pretty normal use case in the link below, you can see the history_stats sensor is not doing what it should regarding states that initiated before the period at hand:
I think there’s still a bug in there that is pretty evident when using it on binary sensors.
Also, there’s something in your state transition graph above that is still not clear to me. The first found state in the window. You place it on the timeline in a spot where the state did not change. For a binary type sensor that is not happening. Why would the state be saved if it did not change at that point? The graph you drew supports your answer, but I do not think it supports a situation you would normally find in the history.
The only way to know the state at the start of the time period, is to know the last state that was recorded before that period. If there’s nothing in the history at all for that period, the only valid answer is unknown.
Have you looked at the post I referred to? There is data in the history there. It gets ignored. 10 hours worth. Until you expand the period to include it, then it gets counted.
And you also keep ignoring the fact that if data gets purged, there may also be nothing before in the database. And then too your example is not something that would happen in real life. You keep ignoring the fact that history stores changes. so the value before can be anything EXCEPT the value that was stored at that point. Unless we are talking about a whole new database. How long ago was that for you?
A new user would expect the values before the existence of the database not to be counted, If that user even uses a history stats sensor within 10 days of adopting HA. Never happens. It is a useless use case to begin with.
I seem to have started getting problems with my statistic sensors after upgrading to 2022.6.x versions.
I have statistics sensors set up to monitor the change of energy meters for the past 7d, 24h and 1h.
What I see is that when the 1h change is not present (no change in energy consumption for an hour) it will return “unknown” instead of 0.
As I understand this is due to no states within the window start/end.
I have an issue in 2023.3.3 version with all history_stats. I have sensors counting occurances “events of ON” (from MQTT) since midnight, as well sensors counting time since midnight. The problem is that midnight does not reset the sensor.
This is my bug description: history_stats timeperiods gone haywire / 2023.3.3 · Issue #89696 · home-assistant/core · GitHub
By reading what you have had, then we likely have some similar data issue (HA not handling the data).
And yes, I as well did change some data retention (purge days) after 2023.3.3 update, from 20 to 15 days.
Thoughts?
