Count state change from sensor

Indeed, check the logbook or history from 23:50 last night

Just did the folowing check which does not fully reflect your case

  1. testinput: 0.0
  2. testcount: history stats on 1. with value 0.0,
    … restarted my HA
    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 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 (


My last restart was on 04/09, so I think the restart is an additional issue.

My observation:

  1. 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.

  1. I have to test again what happens with the restart.
  2. 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?

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

@vingerha changed it, but now it count nothing :frowning:

??? 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

EDIT: Unless that’s not the source sensor

As you yourselves have probably written mutliple times, the state is a string by default :slight_smile:
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.

Here you see different time ranges.

I would expect two count one for 27.4 and the second for 28.4, but its zero