Indeed, check the logbook or history from 23:50 last night
Just did the folowing check which does not fully reflect your case
- testinput: 0.0
- testcount: history stats on 1. with value 0.0,
… restarted my HA
Observations:
testcount starts as ‘unknown’
when I put 1. to 0.1 testcount becomes 1…this is not as I would expect it
when I put 1. to 0.0 testcount becomes 2.as expected
when I put 1. to 0.1 testcount remains 2 as expected
The history does not show the state to be 1 before going to 2
Then I restarted the instance and lo and behold, the initial state of testcount being 1 shows in the history log
So…believe this is buggy, I see two issues now, the count from unknown to 1 should not have happened and history log should have shown the 1.
, you are welcome to report the first on the HA github:
Issues · home-assistant/core (github.com)
My last restart was on 04/09, so I think the restart is an additional issue.
My observation:
- Yesterday and today there was no log entry. State is anyway 1 and not zero. So it looks like that the state start always with 1. So it’s interesting without log entry the value is 1
But that doesn’t have to be a problem, because I also use the daily utility counter.
2. The counter is only incremented as soon as the value is >1. With 0 and 1 the counter is not incremented
For example today:
I think at 11 the state will be 2 and the counter is increased to 1. I will create a screenshot:
If the initial state is always 1 and the counter is still 0. Then at least the counter is correct.
- I have to test again what happens with the restart.
- I thought I also saw a zero value but according to the current observations, that can’t happen. I have to watch that again
Did you also test the sensor in combination with a utility meter/counter? Can you observe the same behavior?
@vingerha
I tested it again extensively (with restart)
The good news with the utility meter the results seem to be correct.
The count from the utility meter is always correct.
The status of the sensor is always shifted by 1 because it always starts with 1 even after a reset.
I can live with that if the value of the utility meter count is correct. Thats fine.
An edge case is, why I see this “issue”
If the count is increased by 1 at midnight (because of a status change), then both are completely in sync and not shifted by 1. Nevertheless, the utility meter count is still correct, so that’s fine, but this was confusing.
@vingerha I’ve been watching it, but it’s not entirely clear yet. It works for 5 days. Not (completely random) on 2 days.
Example is today, didn’t count the state change
I looked at your sensor, try to change to below, along the doc.
putting an ‘end’ in the future may provide odd resultsYou can try mutliple sensors at the same time to see which one works… as per (IMO) bug above, there may be other unexpected behavioral things
With me this is working A-OK for multiple sensors (aside the above menioned curiosities with restart)
platform: history_stats
name: "WP Taktung"
entity_id: sensor.wp_status_value
state: "0.0"
type: count
start: "{{ now().replace(hour=0, minute=0) }}"
end: "{{ now() }}"Ok I will try that, but currently opened a bug History stats unexpected behavior · Issue #92135 · home-assistant/core · GitHub
??? this gets weirder
Did you check if it possibly created a secondary sensor with (almost) the same name?
Again, try to setup a few of thise with different name WPTaktung1/2/3/etc. and different settings and see how they behave
EDIT: I just added a ‘count’ on 0.0 myself and even as this state 0.0 has not occured since my restart, it does count all the 0.0 since day-start
Your state is 0 not 0.0. History stats isn’t built to count numbers, it’s built to count static string states, like 'on' or 'off'. If your number changes from 0 to 0.0 depending on what your sensor outputs, then it won’t count one or the other.
Yes maybe i try it with new utility meter also for the state change on the name like off, heating etc.
No its string and 0.0, 0.2 and 0.4
As you yourselves have probably written mutliple times, the state is a string by default 
And, with me this works fine, i.e. counting 0.0 does it nicely along what I can see when checking the graphs
Yes, but 0 and 0.0 are not the same.
All I’m saying is that this is a point of failure and it depends on the source sensor. “works for me” is meaningless if his sensor does not output the same values under the hood.
Agree of course that with strings one has to be exact.
In my case and the case of the OP, the goal is to count occurences of zero (whatever the right format is)
That’s the problem. If it alternates between 0 and 0.0 you’ll miss one or the other and there’s no way to correct for that.
I even have 2 sensors I’m looking at now both have the same problem
platform: history_stats
name: "WP Taktung Status"
entity_id: sensor.wp_status
state: Aus
type: count
start: "{{ now().replace(hour=0, minute=0, second=0) }}"
end: "{{ now() }}"
But I see both start at 1 and never increased.
Both changed with 0.0 and with Aus.
How you see, the source(history_stats) starts always at 1 (IMHO a bug), but it’s consistent and count also after restart
The utility meter count right, but if the history stats count nothing the utility meter is also wrong
If your first Aus or 0.0 come from a state change before midnight, they aren’t counted. Only state changes between your durations are counted.
