I have a sensor that can go “on” (+ other states) and “off”. I would like to count how often the sensor switch from “on + other states” to “off” every day.
What i understand from the documentation:
First I need history_stats type: count with state “off” and then a utility_meter with cycle: daily,weekly etc. for the statistics.
Is this the correct way?
Thanks
I am blind (or sloppy…take a pick)…yes this is how it could work.
The utility meter sensor will just show a growing figure during the day…so depends a bit what you want to do with the data
I would like to see my cycles (‘On’/‘Off’) for the heat pump over the day, week, month, year.
That should work I guess, depends on what you want to do with the data. Using utility meter you at least have it in (longterm) statistics. Either way, there is no harm in trying it out and see what it does
First idea was something similar to the energy board.
Filter for day, month or year and then show a Chart.
Have not so much experience with charts, but this could do the job maybe 
ApexCharts card - A highly customizable graph card
@vingerha yesterday it works. Today not 
I thought the history stats count the if the state change from off to “on”–>“other state” → “on” → “off” count increase by 1
That is unexpected for me too, it should count the switch to the value you entered
Ah the history stats seems to work. Example today is 1 (right), but the daily utility is 0 (wrong)
@vingerha do you know the behavior after a restart? I think currently it is also increasing the counter.
Maybe it goes from “unknown” to “off”
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…
utility_meter:
wp_taktung_daily:
source: sensor.wp_taktung
cycle: daily
wp_taktung_weekly:
source: sensor.wp_taktung
cycle: weekly
wp_taktung_monthly:
source: sensor.wp_taktung
cycle: monthly
wp_taktung_yearly:
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:
like
value == 0 → Aus
value == 1 → An
value == 2 → Other State etc.
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:
template:
- 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
event_data:
domain: counter
service: reset
service_data:
entity_id: counter.reload_tradfri_integration
sensor:
- unique_id: count_reload_tradfri_integration
name: Count reload Tradfri integration
icon: mdi:eye-plus-outline #counter
state: >
{% if trigger.id == '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 sensor.date ?
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
@Mariusthvdb
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.