Have started using this app for Illumination devices. It works great in most cases.
@csteele
It appears that the trigger for adding a new value to a child device is a change in the illumination reading. Discovered this when the overnight reading for the child device stayed at the same value it had when the illumination reading gave its low reading. In this case 46 lux when the reading was 2 lux. The average never went to 2 lux.
While this is not a current problem for my rules, It would be great to have an average that triggered at a set frequency, where the user could set the frequency individually for each child.
Edit: Created a set of children with different averages. In the Watchtower app it appears that when there are no or small illumination changes from my weather station, the children don't average the update.
If that is the case, then setting an update frequency is necessary to get a true time average.
I don't use this app but I do use a somewhat similar method. In my case, I chose to have a decaying sliding window, i.e. when samples within the sampling window of N samples (to be considered for averaging) get older than X minutes, they get discarded and the window gets smaller until N = 1 (the last event value).
AverageThis receives every Illuminance, Temperature and Relative Humidity update from your selected devices and adds it to the existing Average, per the formula:
"avg -= avg / N;
avg += new_sample / N;"
Where N is 200, approximating 200 samples into the past.
Your selected Illuminance devices establish the period or repetition of the samples added to the rolling average.
I created this App after reading about averaging without using time and was intrigued. It's expecting the intervals between samples to function as the timer, more or less. Thus you have some options of reducing N which makes the "sample window" smaller and the average becomes more weighted by the newest sample OR, alter the reporting "speed" of the device you're tracking.
I've been using this driver to track and feed into my thermostat control. The actual thermostat I own does NOT auto switch between Heat and Cool. I've wanted that feature for as long as I've had a thermostat on the wall. The task is to guess which direction the internal house temp is trending vs the set points from the thermostat. If the house is trending colder then set the mode to heat, If the house is trending hotter, set the mode to cool. Mode does NOT turn on the heater or air con, it simply tells the Thermostat which setpoint to consider
Bruce created an averaging App, using another method:
I have both on my Hub and for my purposes they are similar enough:
(gnore the "between noon and sunset tile" but you can see the 5 averaging instances I have deployed. AvgWhole, AvgUpstairs, AvgDownstairs are all using my Average This App while the "byBruce" tiles are using his. They are almost never the same but they track against each other in a similar way of the day.
A 10 point time average should have one data point per minute for 10 minutes.
Further update:
The log shows that the weather station device gives 1 or 2 updates every minute. It is configured with 1 minute update frequency.
The 2nd update comes within 0. 1 seconds of the first update and has the same lux value as the first update. As a result, the average is for less than the desired time frame and gives double weighting for some arbitrary data points. Until @snell can fix this sporadic updating, we need a periodic trigger option to get a true time average.
The task is to guess which direction the internal house temp is trending vs the set points from the thermostat. If the house is trending colder then set the mode to heat, If the house is trending hotter, set the mode to cool. Mode does NOT turn on the heater or air con, it simply tells the Thermostat which setpoint to consider 
