Thanks @bptworld have updated and will check it out.
@bptworld love your app - I use it to avg temp sensors around the house as a baseline on my temp control and floor heater.
Recently I began an adventure to build out a tool to monitor batteries in my devices. Not the battery levels per se, the actual batteries themselves like date changed, type, etc. During my app work I couldn't understand why I had 3 devices showing up in my data that had no batteries! until I realized the custom drivers had been given Battery capability by mistake. (well. I assume by mistake!)
Averaging Plus delivers an A.P. driver which in turn creates a virtual device. This device is advertising it has a battery capability. Would you think about removing that line if you agree it's unnecessary? You do use a battery attribute also, but I didn't dig to see what function if any was being handled by it. TY for your consideration.
(PS - I'm going to modify the pick list so as to 'blacklist' devices that needn't be monitored.)
AP can be used to average batter levels, so the driver has to have the battery capability. Without it people that wanted to use that average, wouldn't have access to the value as a battery.
Make sense?
1 Like
slaps head yea. makes sense.
1 Like
Here's a feature idea which may or may not fit with the objective of your app. It really is something that could be done outside of it...but I thought I'd throw it out there to see if you and others saw any value of having it within your scope.
Use Case:
Take for example -
Multiple Temp sensors within a space (let's say a greenhouse) being averaged by Ave Plus.
and...
Single Temperature "reference or control" sensor (or I guess it could be multiple averaged) somewhere external to that space.
then wanting to see...
the DELTA +/- temperature difference (or this could be luminance, humidity, noise level, battery, etc. for other applications)
With the option to affect your automation based on delta min, max thresholds.
OR one might simply use this as a means to track that delta for environment/system efficiency monitoring over time, no automation required e.g. just how much warmer/cooler, darker/brighter, wetter/drier, noisier/quieter is environment X from my reference environment Y (or uncontrolled space).
Of course being able to produce a dashboard graph of hourly averages vs reference over the course of a day, week, month in HE would be grand; but that's a totally different and controversial subject 
Just throwing this out there to see if it strikes a cord. You may not see this as falling under the Averaging Plus umbrella for KISS purposes.
Not a bad idea. I've seen others talk about stuff like this a long time ago. Basically about Bathroom humidity vs hallway/bedroom humidity. No promises but I'll definitely add this to the do-to list.
lol, not going to happen here. 
Thanks
1 Like
Perhaps I'm doing something wrong here. I'm averaging 8 temperature sensors, but the average is wrong--with the readings below, it should be 61.7, but it's returning 53.7:
On the topic of an "anomalous average"
I was thinking this morning, "this one sensor in this location of multiple sensors does tend to run out of battery quicker than others, ...and what's left on the device data screen is the last temp it recorded before losing battery".
If that factors into the average before I notice it's OLD data (like if it died in the middle of the night when the temps were lower) then I might have a bad average every hour after that point and take some action according to that mis-information.
Don't know how to amend that other than to somehow check that the device is alive or that the data is fresh/current.
1 Like
New version on GitHub...
1.1.6 - 02/03/22 - Minor changes, new option - Max hours since device has reported
1 Like
I have an involved use case for temp averaging.
I have 4 temp sensors, let's call them A,B,C,D. They are in different locations in my home.
I am using the average to control the Thermostat Controller app for a Honeywell T6 stat, along with the Thermostat Scheduler, as the temp sensor for the Controller app.
I specified a virtual sensor in AP to hold the averages, named temp avg. .(yes the period is intentional).
Then, I created 4 AP children using different combinations of A,B,C,D with the children updating the SAME virtual sensor (temp avg.) and this is where I am having problems.
I also created a basic rule that, based on time periods, each time period would enable ONE of the AP children and dis-able the other three.
So for instance, at midnight, AP child "night time" would be enabled and use sensor A and C.
Then in the morning, AP child "morning" would be enabled and use sensor A,B,D.
etc......
The virtual sensor "temp avg." would be updated with the child that was enabled.
This doesn't seem to work with AP.
I am running some tests to generated a useful log for you, but I wanted to see if all this is even possible to begin with.
The problem seems to be with multiple children updating the same virtual sensor.
Is this true? If so, is there another way to do this?
Thank you for your work!
Here is a screenshot of the error that I am having. Also, the averaging stops when the child is enabled, and restarts when I open the child app's device. I don't do anything else to re-start the child.
the error is at 13:15:00.039 (the bottom).
First thing, it's never a good idea to use 'special characters' in a device name. I would delete that device and create a new one without the period.
So, with that. Go into the first child device and slide the switch over to create a new device. Finish with all the other options and hit 'done'.
Now go into the second child and leave the slider in the off position. Select the device created in the first child. Finish up all the other options and hit 'done'.
Do this for all remaining child devices.
That should fix the problem.
Thank you! I will give it a try.
What other special characters are not allowed in device names? Is a space considered a special character?
spaces are fine 
so, for my information about the app, the FIRST child's virtual sensor is created by the child, then any other child apps can use the FIRST one and the sensor will be updated by THAT child.
What I had going on was that EACH child was trying to create ANOTHER virtual sensor with the SAME label, and that was giving me the error?
But if I used the SAME virtual sensor in other AP apps, the virtual sensor would be updated and NOT tried to re-create the sensor?
Thank you for your help! I'll let it run and see if it is performing the way I wanted it for my thermostat.
Well the errors don't show up any more, but I am using the Enable/disable function with a virtual switch on each of the children, and the disable seems to work, but when I turn the switch off (enable the app), the child does not start.
Is that the correct way to enable and disable the child?
FYI... when I:
1)disable the app (turn the switch ON).
2)enable the app (turn the switch OFF).
the log doesn't show the child running
3)open the child's app device and click DONE
4)the child starts again
The enable state doesn't seem to be enabling the child (switch OFF).
New version on GitHub...
1.1.7 - 02/11/22 - Adjustments
WOW THANK YOU!!!!!
Works GREAT! with my enable/disable switches!!!!
Just a question..... When I set the update speed to 1 minute, what "timer" is used to trigger the update? System clock/when the app was enabled/or...?
Is there a way to keep the debug log running rather than auto timeout? OR increase the auto timeout time? Would be nice for longer logging, but not necessary.... just a thought.
No idea
Easy enough, coming up
New version on GitHub...
1.1.8 - 02/11/22 - Adjustment to Debug Logs
