Unfortunately “change” or “state” options unavailable from stats card configuration - it’s greyed out.
That’s why i’m stucked)
And History Graph is totally different - it doesn’t represent “per hour cycles”.
Maybe it’s just a bug ?
Unfortunately “change” or “state” options unavailable from stats card configuration - it’s greyed out.
That’s why i’m stucked)
And History Graph is totally different - it doesn’t represent “per hour cycles”.
Maybe it’s just a bug ?
Ok you can only use change with state_class: total
(or total_increasing). But forget that.
Looking again at your graph it is working fine. From 3am to 4am it turned on 9 times. And that is what your graph shows at 4am. Remember you defined it as now minus one hour:
end: "{{ now() }}"
duration:
hours: 1
So the 4am bar is for 3am to 4am.
For 4am to 5am the count was 0. And that is what shows for the 5am bar, at least I think it does it is hard to see behind the tool tip.
There is no bug. It is working as expected.
Ok, minus 1 hour, i got it. So here’s another recent examples.
23pm bar (should be 22-23 right?) - 4 times
History bar 22-23 - 1 time
0 bar (should be 23-0 right?) - 6 times
History bar 23-0 - 4 times
1am bar (should be 0-1am right?) - 3 times
History bar 0-1am - 3 times
It’s somewhere right, somewhere wrong… And i can’t find logic here
P.S. Changed from end: “{{ now() }}” to start: “{{ now() }}” to see what happens…
Perhaps it is because it is a sliding one hour window ending now not “on the hour”. What time did you make those graphs?
Um if you make it start now with a duration of one hour that probably requires time travel to collect data. Now to one hour in the future?
To get it to reset on the hour you will have to do something like this which will collect all day starting at 0:00:
start: "{{ today_at() }}"
end: "{{ now() }}"
Then feed that to an hourly cycle utility meter. Like you were doing, but now with history stats sensor, not stats sensor.
ooohhh… i think i got the main idea…
But can’t we just say something like “beginning of each hour” with some templating ? and duration 1 hour ?
Or why it’s impossible to make smth like this ?
start: "{{ today_at() }}"
end: "{{ now() }}"
duration: 1 hour
The thing is to get almost realtime stats…
I think this might do what you want:
end: "{{ now().replace(minute=0,second=0,microsecond=0) }}"
duration: 1 hour
Thanks, i’ll give a try!
I just updated the template. Both should work but the new version is simpler (only one replace
instead of three).
If you replace end
with start
in Tom’s template you’ll get closer to real-time updates. The counter should increase within a minute of a state change, and it should reset to zero or 1 (see below) within a minute after each new hour.
A peculiarity of the history_stats count
method is that it is NOT a “rising edge” counter. Instead it counts the number of times the device has been in the desired state during that time window. In other words, if you are counting on
states, and the device was already on
at the start of the window, the counter will count that as 1, even though there is no rising edge. That is important because if the pump is already running when a new hour starts, you’ll get a count of 1 added in the previous hour and a count of 1 added in the new hour, even though the pump only turned on once.
If you want a rising edge counter that updates immediately upon state changes and returns to zero immediately at the start of every hour, then the only option is a trigger-based template sensor with some fancy templates.
If the peculiarities of the history_stats don’t bother you, then there’s no need to go down that path.
To be honest i’ve started this “investigaion” after i’ve made up garden water output and started changing my water pressure tank and relay settings for maximum capacity (minimising water pump starts/stops).
So +/- 1 start/stop isn’t pain in the ass…
But last template sems to works strange as well…
If you want to do the template method, you can use this:
template:
- trigger:
- platform: state
entity_id: binary_sensor.nasos
to: 'on'
- platform: time_pattern
hours: '/1'
sensor:
- name: Water Pump Hourly Counter
unique_id: 6759e0f7-e104-4690-a700-3fce4d92bddc
state_class: measurement
state: "{{ 0 if trigger.platform == 'time_pattern' else this.state | int(0) + 1 }}"
It will be unknown
until it gets triggered for the first time.
Seems it works more mystique than before:)
History - water softener rinse from 3 till 4 am - 9 times, and 3 time from 8 till 9 am
Stats
Is this the correct sensor in your history stats?
It’s named Hacoc in your graph.
Correct, it’s just edited in dashboard
Just in case - this is my history stats sensor
sensor:
- platform: history_stats
name: Pump ON today
entity_id: binary_sensor.nasos
unique_id: pumpon.nasos
state: "on"
type: count
end: "{{ now().replace(minute=0,second=0,microsecond=0) }}"
duration:
hours: 1
Looking at the open issues for the History Stats integration there are a couple that almost fit what you are seeing: Issues · home-assistant/core · GitHub
You should open an new issue about the count being incorrect. You can drag and drop the images you used here into your report.
@tom_l @mekaneck Guys, i’m stuck:) i left both solutions - history stats and template method.
But statistics graph is wrong again.
Here’s history from binary_sensor.nasos
Now stats graph
How it happens ?
I apologize, the state_class
of the template sensor should be total_increasing
instead of measurement
.
Show us the history plot (not the statistics plot) of both sensors (history_stats and template). I suspect it looks like what you wanted/expected.
The statistics are calculated from the max value for the period e.g. between 1pm-2pm, and the template and history_stats sensors both reset their values at e.g. 0.01 seconds after 1pm, which unfortunately is late enough to be considered in the new hour.
I think the state_class might fix the problem by itself because HA just considers going back to zero as a “meter reset” and so it shouldn’t actually affect any of the statistics (I think). You could also eliminate the hourly resets entirely (in addition to fixing the state_class) and the statistics plot should still show you the hourly change.
Wow, thanks a lot! Now it looks exactly how it should be.
History
Graph
I think i should open issue on Github as @tom_l recommended.
You can do as you’d like, but in my opinion this would be a feature request and not a bug report. The history_stats sensor can be used with many different window configurations, and with a continuously sliding window (e.g. the previous hour) then a measurement
state class makes sense. It’s only when you have a window config such as yours (non-overlapping intermittently updating) that a total_increasing
state class would be desired. So the feature request would be to add the ability to specify the state class in YAML when configuring the sensor.
That being said, it may already be possible to change it using customize.yaml, but I have not attempted it.
I’m in agreement w/ @mekaneck here, history stats sensor should change to
sensor:
- platform: history_stats
name: Pump ON today
entity_id: binary_sensor.nasos
unique_id: pumpon.nasos
state: "on"
type: count
start: "{{ now().replace(minute=0,second=0,microsecond=0) }}"
end: "{{ now() }}"
This would capture the current hour, which should make total_increasing make more sense.
Then in configuration.yaml
homeassistant:
customize:
sensor.pump_on_today:
state_class: total_increasing