Count state change from sensor

Nope, you’d have to check this via the ‘history’ of the sensor, they should remain wiht their old state. templet sensors may go to blank, depends on how you set that up

After a small test after every restart it’s increased by 1.
How can I avoid this? This is my stats?

  - platform: history_stats
    name: "WP Taktung"
    entity_id: sensor.wp_status
    state: "Aus"
    type: count
    start: "{{ now().replace(hour=0, minute=0) }}"
    end: "{{ now().replace(hour=23, minute=59) }}"

And what i have to do for a right utility meter? It is always zero…

    source: sensor.wp_taktung
    cycle: daily
    source: sensor.wp_taktung
    cycle: weekly
    source: sensor.wp_taktung
    cycle: monthly
    source: sensor.wp_taktung
    cycle: yearly

Again, what does the history of sensor.wp_status show…if this goes to Aus after restart then this is the source of the issue, maybe you can control that sensor?

Good question how i can debug this?

I get the value from a html site with scrape.
Then i translate the value to an status:
value == 0 → Aus
value == 1 → An
value == 2 → Other State etc.

So yes i have both sensor “under” control. But not sure what is the status for the restart and the initial value. IMHO the last state is Aus and after restart is also Aus. So no state change

Use the history of the sensor? Check logbook or history from the left menu item before+after the last restart. If it indeed comes up with ‘Aus’ then this may be fhe issue, I donot exactly know how hsi_stats counts but I think the sensor starts with ‘blank’ and then goes to last value…only one able to check this is you

Yes i check the logbook and there is a entry
“wp_status wechselte zu Aus” so it’s change to Aus after restart, but i don’t see the value before.

Normally it looks like this
“wp_status wechselte zu Heizung ausgelöst durch Zustand von WP Status Value wechselte zu 0.2”

So I see the complete chain of changes. So i think the initial value is wrong.

Ah maybe I need this availability

@vingerha i don’t understand it. The most time it works finde, but sometime the count is wrong:

My sensor looks like:

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().replace(hour=23, minute=59) }}"

Here is the state and the logbook. The value and count should be one, but is two. I have no idea why?

did you consider a trigger based template sensor? I use this to count and reset a certain event:


  - trigger:

      - platform: state
        entity_id: automation.reload_tradfri_integration #counter.
        attribute: last_triggered
        id: count

#       - platform: state
#         entity_id: input_button.reset_tradfri_reload_counter
#         id: reset

#       - platform: state
#         entity_id: counter.reload_tradfri_integration
#         to: '0'
#         id: reset

      - platform: event
        event_type: call_service
          domain: counter
          service: reset
            entity_id: counter.reload_tradfri_integration


      - unique_id: count_reload_tradfri_integration
        name: Count reload Tradfri integration
        icon: mdi:eye-plus-outline #counter
        state: >
          {% if == 'count' %} {{this.state|default(0)|int(0)+ 1}}
          {% else %} 0
          {% endif %}

and you could replace that trigger with the template you need:

      - platform: state
        entity_id: sensor.that_changes_to_off #counter.
        to: 'off'
        id: count

and reset could also be done automatically, by changing the trigger to ?

the beauty would be it does not trigger on HA restart, and it also survives a restart during the day

What is the value of the sensor shortly befor emidnight? If that is not 0.0 then I guess it would start with 0, if it is 0.0 then it would start with 1…but to be 100% honest, the details on a restart of a history stats sensor is not fully transparent to me.
You could try it out with a different start (during daytime) and manually update the sensor to see what it does
what I (me) would expect
23:59 state: 0.0

00:00 wp taktung: 1
why: it restarts, finds value 0.0 so 1

with similar thoughts:
23:59 state: 0.1 (not 0.0)

00:00 wp taktung: 0

However, it could also be that the reset at midnight means to start from 0 and only after it re-hits 0.0. then it starts counting

Of course I can do it myself with more effort. I would still be interested why it does not work, what it is intended for.

As it works 99% of the days I would say the value is 0.0 at 23:59.
Can I see the different value in the logbook? Currently it’s pretty easy, the value changes at 11 am o’clock from 0.0 to 0.4
and at 11:30 am o’clock from 0.4 to 0.0.
So it should currently always be 1. Which it usually does, but sometimes it’s two, which makes no sense at all.

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