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