klogg
June 24, 2021, 4:38pm
1
What more can I add?
Seconds is the standard unit of measurement for time, not hours as the History Sensor currently measures returns.
As it stands now we get anomalies like this where my switch was on for 10 minutes today (controlled by an HA timer) but the sensor rounds this up to 0.17 of an hour which is 10’ 12".
And bizarrely…
gives an attribute value: 9m?
All this could be avoided by measuring in seconds. Or more accurately not converting to hours:
See Line 260 here
# Save value in hours
self.value = elapsed / 3600
I’m not sure why this was ever thought a good idea but then this sensor has been around a long time (since 0.39) so maybe it was an oversight?
Ideally it should be a configuration variable named unit_of_measurement. And I would like also a precision configuration variable to round the state value.
1 Like
Chrisvdw00
April 12, 2022, 4:17pm
3
Is it possible to change this manually in your home assistant installation? (Hopefully this indeed becomes the standard in some update)
Anyone ever work out how to do this?
This is a pretty ridiculous oversight and should have been rectified ages ago.
amosyuen
July 26, 2023, 6:25am
6
My pull request Stop rounding history_stats sensor by amosyuen · Pull Request #97195 · home-assistant/core · GitHub just got merged which should stop rounding the sensor. The default precision is still 0.01, but you can fix that by changing the entity setting. Either set the time unit to seconds or change the precision to 0.0001.
2 Likes
Anyway I still see rounding in time sensors.
opened 06:00PM - 13 Jun 23 UTC
integration: history_stats
### The problem
Consider these sensors:
```
input_boolean:
testing_boole… an:
sensor:
- platform: history_stats
name: testing_hs_time_1min
entity_id: input_boolean.testing_boolean
state: "on"
type: time
end: "{{ now() }}"
duration:
minutes: 1
- platform: history_stats
name: testing_hs_count_1min
entity_id: input_boolean.testing_boolean
state: "on"
type: count
end: "{{ now() }}"
duration:
minutes: 1
```
Here the `testing_hs_time_1min` sensor is calculated for the last 1 minute.
There are problems with displaying a value for this sensor.
Test card:
```
type: vertical-stack
cards:
- type: entities
entities:
- entity: input_boolean.testing_boolean
secondary_info: last-changed
- entity: sensor.testing_hs_time_1min
secondary_info: last-changed
- entity: sensor.testing_hs_count_1min
secondary_info: last-changed
- type: history-graph
entities:
- sensor.testing_hs_time_1min
- sensor.testing_hs_count_1min
- input_boolean.testing_boolean
hours_to_show: 0.0833
- type: logbook
entities:
- input_boolean.testing_boolean
hours_to_show: 24
```
Start changing the `input_boolean` value.
It may be displayed as:
and also reported as:
And then after next changing of the `input_boolean` I see this:
and also reported as:
What I see is
- `1:12` and `0.02` are same;
- `36` and `0.01` are not same - it probably should be displayed as `0:36`
- only these two values are observed - seems there are some precision limitations.
Questions:
1. WTH we have these limitations? Why it cannot be of "1 second" precision?
2. `0.01` should be displayed as `0:36` (not `36`).
### What version of Home Assistant Core has the issue?
2023.6.0
### What was the last working version of Home Assistant Core?
_No response_
### What type of installation are you running?
Home Assistant Container
### Integration causing the issue
History stats
### Link to integration documentation on our website
https://www.home-assistant.io/integrations/history_stats/
### Diagnostics information
_No response_
### Example YAML snippet
_No response_
### Anything in the logs that might be useful for us?
_No response_
### Additional information
_No response_
klogg
August 4, 2023, 4:05pm
8
I don’t remember who it was (sincere apologies if you are reading this) but someone soon after I originally posted about this (ridiculous) state of affairs attempted to deal with all these rounding issues with History Stats, and a lot more. It looked to me like a very good implementation which not only solved the problem but made the whole sensor much more useful.
His pull request got rejected for I don’t know what reason. It was around the time when when the long term recorder/history stats came in so I think he (we) assumed that it was rejected because ‘they’ had plans for this sensor.
amosyuen
August 4, 2023, 6:16pm
9
Did you change the precision mentioned in my post above? Also are you on a version that includes the change e.g. 2023.8?
Using 2023.8.
!!!
Seems that default precision settings do not allow to show precise data. Is it possible to change this?
amosyuen
August 4, 2023, 6:37pm
11
Looked at your post, looks like your HA version is 2023.6 so you won’t have the PR yet.
That issue was made in June, now I am testing with 2023.8.
amosyuen
August 4, 2023, 6:41pm
13
Ah ok that makes sense.
I wanted to set the default precision higher, but maintainers asked me to set it to match old behavior .
I see. Well, it is not a big deal to manually increase a precision. Thanks a LOT !!!
