I have automated my awning. My local personal weather station is measuring wind and at wind speeds above 5, it automatically retracts the awning. I am not entirely happy with the wind sensor, it’s too sensitive for my taste. I’m trying to filter out shorts spikes by taking an average.
My question is: what is the best way to take an average here?
This graph shows:
Actual measured wind speed (yellow)
Statistics sensor mean (orange)
Statistics sensor average_linear (blue)
Part of my confusion: I don’t get why the statistics sensors never get to 0, even though the measured wind speed has been 0 for a while. Is there a statistics sensor that actually measures the last minute or two and takes that average?
My statistics sensor mean:
- platform: statistics
name: wind_kph_avg
entity_id: sensor.bresser_6in1_0_ws
state_characteristic: mean
sampling_size: 4 # New measurement every 12 seconds
You picture confuses me, how can an average be higher than the actual?
Anyhow…
You can create a template sensor
You can also have the automation respond if windspeed > XYZ for ABC seconds/minutes
My picture confuses me too, that is why I put my question up here
I believe the average is higher than the actual sensor values, because of the way they are calculcated. Old values are carried over or something.
I was hoping a statistics guru could help out here, to find an appropriate type of averaging. These are already template sensors (of the statistics kind). And simply using wind speed as a trigger… I would rather use some sort of average because of the gusts of wind at random intervals (where the wind sensor updates every 12 seconds).
Then maybe post the templates so people can have a look?
With 12sec…I still believe you should take actual value > 24 sec as the wind gust may drive the average up higher then you want to trigger it on … depending on the time of trigger
I’m sorry, I’ve read this sentence five times but I don’t understand what you mean.
My thinking is: I would like to average out the actual wind sensor values for the last minute (or perhaps 2). That should take care of wind gusts, because in a minute time there would be a least 4 separate sensor reading available. But the statistics sensor doesn’t seem to calculcate the average like I expect it to (it’s not just taking the last four sensor readings and dividing by 4 but does some other magic).
I am assuming it is unlikely to have wind gusts twice in 24 sec. at measure moment.
Trigger: windspeed > 3 for period > 24 sec. then
Action: do something
…one can of course also take 30 or 60…
Just to throw in another option you might want to consider … how about an automation with a numeric_state trigger of wind_speed above XX km/hr for YY secs/mins?
I’m currently working on the same issue as @Emphyrio and thought about this kind of automation. However, looking at my sensor readings I’m pretty sure I still need to level them by using a statistics sensor before. The readings are all over the place.
I am really looking for a viable sensor for this use case. Not triggers and conditions, because that doesn’t fit my setup for securing the awning against too much wind. There are a lot of variables / sensors in play for automating the awning, using sensors I can structure the automations so I can make sense of it.
There are more forum members interested in properly averaging their wind speed. At first glance it doesn’t seem too hard but in practice, no one seems to have figured out a working and understandable configuration.
I am now looking at the Filter sensor, time simple moving average. So far, it doesn’t seem to differ much from the Statistics mean sensor except that it lags a little in comparison.
It seems the solution for properly averaging a statistics or filter sensor is called ‘force update’. This option ‘force update’ needs to be configured on the source sensor. What it does: “Sends update events even if the value hasn’t changed. Useful if you want to have meaningful value graphs in history.”
This option was indeed present in the rtl1433_MQTT Auto Discovery add-on I was using for the wind sensor. You can see the moment I activated it in this graph:
The statistics-sensor average-lineair (blue) and the filter-sensor time_simple_moving_average (purple) quickly took the zero values into consideration, diving to 0. The statistics-sensor mean (orange/red) did not respond as much, but now at least I can consider that this is probably by design.
For this purpose of averaging out a wind sensor, it seems the filter sensor ‘time_simple_moving_average’ is the best fit. It seems to respond the least to sudden spikes. I’ll keep an eye on it. Further insights are always welcomed
Hi there! I wonder how far you got beyond this point. I want to improve how I automate my awning. I’ve been using this automation for a year and I have not had the chance to test it because I tend to control the awning manually (when the day is windy, I simply keep it closed hence not giving it a chance for this automation to kick in):
I’m thinking of rather “profiling” the wind behavior and acting based on that profiling to actually disable a time based automation in case the day is very windy. In case it is not that windy, I would like to put out the awning automatically and have a reliable automation decide whether retracting the awning is needed.
I would love to read what you ended up doing, and also read other options.
Haven’t been using it much. Nowadays usually someone is home, controlling it manually.
I did realise there is a lot of difference between awnings, some are more wind proof. With a cheaper awning, that is more sensitive to wind, you might get a lot of motor action. Which you should prevent because the motor won’t last long.