It looks like its going to break again since its accessing the database from the event loop which effectively blocks Home Assistant from doing anything (accepting connections, running automations, updating integrations, etc) until the database call finishes. Doing this will raise an exception in 2022.6.
I’ve added some notes to that issue on how to fix it.
Hi,
I created a sensor using this integration:
sensor:
- platform: average
name: outdoor rain info cycle # dati relativi alla pioggia nel ciclo impostato (average, min, max)
start: "{{ (as_timestamp( now()) - (states('input_number.ciclo_irrigazione')| float *86400))}}"
end: "{{now()}}"
entities:
- sensor.total_rain_rate
the input_number.ciclo_irrigazione is a value that I set through a slider.
When I change the input number value the update of the average sensor it’s not instant, I’ve to wait up to 20secs
Is there a way to recalculate the average sensor instantly when input_number.ciclo_irrigazione is set to a new value ?
I tried to put a tap action/hold action on the slider and call an homeassistant.update_entity service targeting the average sensor but nothing happens
thank you
Did you get solution for this douple graph issue? i have same and it is related to unit of measure on average sensors.
Is it possible to calculate the average with ha-average (GitHub - Limych/ha-average: Average Sensor for Home Assistant) not timebased? So techincally just the mean value. I am trying to calculate my average weight on a weekly basis, so it doesn’t matter how long the state is the value just the changes matter.
Does the recorder “keep_days” setting have to be larger than the number of days I want the average to be calculated for? I want to calculate the monthly energy cost average. I currently have “keep_days” set to 7. Does this integration operate independently of this setting?
Why do both recalculate states upon HA restart during the day?
- platform: average
name: "Daily average outside temperature yesterday"
unique_id: "daily_average_outside_temperature_yesterday"
entities:
- sensor.fasada_temperature
- sensor.aqara_temperature_1
start: "{{ today_at() - timedelta(days=1) }}"
end: "{{ today_at() }}"
- platform: average
name: "Daily average outside temperature yesterday"
unique_id: "daily_average_outside_temperature_yesterday"
entities:
- sensor.fasada_temperature
- sensor.aqara_temperature_1
end: "{{ now().replace(hour=0, minute=0, second=0) }}"
duration:
hours: 24
How to fix this?
SOLVED:
One of sensors is unavailable upon restart.
These 2 provide identical state.
Compared with statistics average_linear they do not. Which one is correct time based: “ha-average” or “statistics with average_linear” @Limych ?
that is last 24 hours
This is from midnight
They are not the same they are both correct but you are measuring 2 different averages. The first one is likely giving the same result as the statistics integration
They are both identical (last 24hours from midnight).
And neither is giving the same result as “statistics average_linear”.
i have an energy sensor counting my house load consumption
how do i utilize this average to get a last 7 days average sensor ?
which source entity should i use for this ? the original one ? or a utility meter one ?
Hi,
I just installed the sensore. I would like to create a sensor to average the night temperature, ie. from sunset to sunrise each day. So the start and end time should change based on, for example, sun entity. Is it possible to do that? Or have I just use “fixed” start and end time?
FYI - How to replace this integration
Due to this integration is abandoned, I’ve finally replaced it with the built in solutions. Problems to solve:
After several failed experiments I’ve ended up with 2 sensors:
sensors:
# - platform: average
# name: 'Living room Temperature Average'
# entities:
# - sensor.living_room_temperature
# duration:
# minutes: 1
# precision: 1
# process_undef_as: 25.0
- platform: filter
name: "Living room Temperature Average"
entity_id: sensor.living_room_temperature
filters:
- filter: time_simple_moving_average
window_size: "00:01"
precision: 1
template:
- trigger:
- platform: state
entity_id: sensor.living_room_temperature_average
to: # empty = any state change, no attribute change
- platform: state
entity_id: sensor.living_room_temperature_average
to: "unavailable"
for:
minutes: 1
id: "unavailable"
sensor:
- name: "Living room temperature average for heater"
state: '{{ states("sensor.living_room_temperature_average") if trigger.id != "unavailable" else "25.0" }}'
unit_of_measurement: '°C'
device_class: temperature
availability: '{{ states("sensor.living_room_temperature_average") is not match("un\w*") }}'
UPDATE: added the new availability attribute.
It’s not abandoned - last commit was a few months ago. It’s also still working perfectly. I know the author is in Russia which is a hinderance…
Is there any way to use arithmetic mean? Also what safety does this have for offline sensors?
I’m currently using the sensor group helper and it freaks out when there’s a sensor drop, even if it’s set to ignore nan sensors.
As opposed to what? The average is the mean
Hello;
I also have a sensor setup using the built in sensor grouping set to arithmetic mean, as apposed to median. My group sensor had a slightly different number than this plugins result, so I could only assume it didn’t use straight arithmetic mean, or else it would match closer.
However after having them setup overnight it seem to have equaled out. So no problem after all.
I’m still curious about safety for sensors that drop. Seems to handle it from my testing, unlike the built in helper, but it’s only been a day so far.
Hi your proposal to replace this integration with the ‘filter’ is interesting, I have not seen it before, and myself I migrated to the ‘statistics’ integration (as probably many others).
However I have found out that there is a significant bug in the ‘statistics’ sensors that occur at each restart of HA, where the value can go wayyy off charts for a few minutes (looks like a bad variable initialisation or alike), which is making any automation linked to the sensor do wrong things.
I was wondering if the ‘filter’ sensors were capable to filter values over a 24h window? As I read in the warning of this integration, it may seem it is more made for near-real-time filtering, right?
At this moment I’m doing something relatively similar to your setup, I’m doing a first average with ‘statistics’ then a filter with a template sensor… not too nice.
It’s a shame because I have never had any trouble with this average sensor ever before.
I think it is abandoned unfortunately. The commit that was fixing the deprecation introduced by HA 2023.4 was prepared months ago but never pushed to publication.
Many people have been waiting until the last moment to see if this integration would be updated in time, and the answer is no…
Now I’ll put my effort on the bug fix of the statistics integration instead.
You can always push that commit locally. Pretty sure I did that months ago
A few years ago I made some experiments and started to use filter, becasue it seemed less faulty (see Extend documentation comparing your sensor with the HA built-in filter sensor · Issue #26 · Limych/ha-average · GitHub). In my case the short timespan (1 minute) do not require any recorder access after restart, and a temporary unavailable value is OK for me, and I can handle it with the wrapper template sensor.
I have no experience with statistics, though for long time averages (like 24h) filter seems to be a bad choice, because filter doesn’t use recorder after restart to read past sensor values. Maybe another wrapper template sensor that hides the statistics sensor’s value after restart for a few minutes? Returning unavailable for a few minutes? This is only plain guesswork from me.