Great! Thanks!
Is there a way to do a moving or running average over the last X observations? I've got an outdoor fridge with temp sensors in the garage. When someone opens the door to put something in it, it trips the temp limit I have. What I really need is a running average where the temp is trended and if consistently higher, it trips the limit. As it is now, it's the boy that cried wolf.
Suggestions? I've started looking through bangali's code around Room Manager as I think he has a moving humidity measure (that's what I've read, anyway). Any other suggestions?
You must have that temp limit set really low. On both my fridges the rule machine notification sends me a notification if either of them go above 50 degrees. Normally they stay within the 33-38 degree range. It takes a long time with the door being open for the temp to reach above 50.
45 degrees for fridge and 10 for freezer. I've been avoiding raising it because if it really was a failure, I'd want to address quickly.
It's a creaky side-by-side that continues to perform. I'm just waiting for the day when it fails. Open either door and all the cold just falls out. Temp spikes briefly and then drops back into range within 5 min or so. I've been pushing my wife to let me trade it out for a chest freezer, but she doesn't want to give up the fridge space.
If you're set on using the 45 degrees, then I would recommend using a different sensor that's driver is adjustable on when it takes temperature measurements and reporting. I use the Fibaro FGK-101's that use the native Fibaro Door/Window Sensor 2 driver, this way it would be every 5 minutes it takes a reading which should be more than enough time to recoup the drop from opening the door.
I have updated the app in the public repo to give a running average option. You have to pick how many sensor events you want to include in the running average. If you don't put a number of events in the app uses 1, which is simply the current average of the sensors. The running average is an average of averages.
How many events to choose depends on how sensitive you want this to be. The longer the running average, the less sensitive it is to each temperature event. You need to know the rate at which these events are happening to make that decision.
4 Likes
bravenel - You are a scholar and a gentleman, sir. I want to see how you did this as I could not figure out how to approach this myself. So many thanks!
waynespringer79 - I'm using a NodeMCU board driving 2 AM2302 temp/humidity sensors and two copper tape mechanical contact switches. I can set the sensor polling rate at 1 min per side. I need to think through the right window - to bravenel's point. Basically need enough time to get to local store and get dry ice if something went wrong while I figure out plan B. Like replacing the damned thing...Or hosting the neighborhood for a cookout.
Many thanks for the app, Noticed something strange with the "Current Running Average" computation when I changed the number of sensor events from 1 to 2. See the screenshots below.
1 sensor event:
Now after the change to 2 sensor events:
Looks like a bug in that displayed running average.
My first thought also, but examining the virtual device event data shows:
So the app wrote the suspect running average value to the device.
@bravenel, again thanks for the app, I did a little digging, fixed the issue by initializing the state.run array after the input parameter "useRun" is changed.
Here's the edit to the initRun procedure:
def initRun() {
def temp = averageTemp()
// if(!state.run) {
state.run = []
for(int i = 0; i < useRun; i++) state.run += temp
// }
log.info "initRun: state.run = ${state.run}"
}
1 Like
So I'm still pretty new with HE and especially with groovy code, but using the examples from @bravenel, I was able to create an app that basically sums all of my vent positions and calculates the total open vent area. My question is regarding the result, I ended up using a Virtual Illuminance sensor since it would hold larger value than a switchLevel. Everything works, but it just seems kind of hokey using an Illuminance senor, it would make more sense if their were a virtual device for a number, decimal or string? Am I missing something here?
Global Variables?
Virtual devices created and set by apps like this are somewhat an anomaly. It is, after all, a virtual device. And, devices have attributes that have such properties as number, decimal or string. So you're on your own when you are creating a "total open vent area" device. You could create a driver for that, and it could have an attribute of openVentArea, a number. That would make more sense than using an illuminance device.
Then in a Groovy app you could reference device.currentOpenVentArea as a number. Rule Machine could work with such a device using custom attribute, for triggers or conditions. If you like, I could whip up such a driver for you, and put it in our public repo. There isn't much to it: one attribute and one command (setOpenVentArea).
Check this out (don't know what unit to use for total area, sq. meter, sq. inch, etc. -- up to you):
2 Likes
This is perfect, I was going ask where I might find a simple driver example, but you already hooked me up, thanks.
I had one more question that I couldn't find a definite answer for, I was trying to define a input condition for the capability, but it looks like you can only specify one capability type on an input, is there any way around that?
input "tempSensors", "capability.xxxx and capabilty.xxxx",input "tempSensors", "capability.*",
I'm actually looking to do the opposite, I only wanted devices with a specific set of capabilities to show up. So in this case only keen vents, which have a switch, level and battery properties. So when I select a capability of switch, level or battery I get the vents in the list but I also get devices I don't want to see. Not a big deal either way I just wanted to know if that filtering was available or not.
Edit: in response to a now deleted post.....
The app creates a new device. You can use that in Rule Machine.
1 Like
Hi is there a way to lower the minumum samples for AverageThis? Will duplicating the sensor also have the same effect? 
