I the below simple rule to monitor our fridge as the power frequently tripped in that area (breaker replaced now and seems to be fine).
It's showing in the top 5 of my apps on busy time but it's very simple, is there a better/efficient way to do this
Does the sensor device send frequent reports? The trigger logic processes on every update to the power level attribute. Could try to slow things down by adjusting the reporting frequency or threshold levels on the sensor device.
its not overly frequent but that's why i have it set for just upper lower end changes.
just 2 lines long average runtime 243, i think cancel delayed action is quite resource intensive . hence looking for alternatives
That rule will run whenever the devices report any power level. It has to check the value to see whether or not to trigger. So the limits on the triggers don't stop that. Only way to reduce is to change the reporting from the device.
Thanks it wasn't the number of runs it was the relatively high cycle time.
I'm guessing it's the cancel delays, so was wondering if there was a more efficient way
This takes almost no time at all. All it does are two simple system calls to unschedule two methods.
What do you mean by 'cycle' time? Have you logged what's going on? With Events, Triggers and Actions all turned on?
Think of it this way: if your fridge power load is usually within nominal range, then the actions hardly ever process. Most of this rule’s processing time is spent handling the trigger tests. Every time the power level is reported to the hub, this rule is going to check if the reported value is under 5, and if that fails (which it will under normal conditions) then it will check if the value is over 70. That’s two math-driven tests every time the device reports. How frequently does the device report? How frequently is that reported value under 5 or over 70 causing the actions to fire?
You could try a few things to narrow the possibilities. Figure out the rate at which the actions fire, then clone the rule and change that new trigger to a timed event set to the same rate. Or, clone the rule and delete the actions, just leave the trigger conditions. Compare app stats after a period of time.
from the runtime - app stats page 243 is the average run time
great idea, ive cloned it with no actions, reset the runtime stats lets see.......
after 5 min
after 55min
negligible difference
ive cloned the original rule again, but this time removed the up front evaluation (<5 >70)........ but was slightly worse
so updated to just one condition (>70)
What problem are you trying to solve? Is there a problem, or is this just a chase down a rabbit hole stemming from runtime stats?
No rabbit hole, just trying to tweak and improve, understand most efficient way to do things.
This was one of the top heights average run times just trying to improve it.
I'm guessing it's as fast as It can be and only improvement would be a custom app.
The original question was is there better way,
I liked the questions and I’m glad you asked 
It's going to notify no matter what, but after 5 minutes of no reports from the refrigerator. Is that the intent? To discover that the refrigerator stopped reporting? If so, it doesn't really matter what the trigger is, and you could use a single trigger of Power Level changed. Also, instead of cancelling a delay, just put in a Wait for Elapsed Time of 5:00 minutes. That is automatically cancelled when the rule is triggered (irrespective of whether you use your original triggers or above suggestion), and then it starts over again. Then you can remove the Cancel Delayed Actions, not that it is an expensive thing to do.
Normally it was > 50 min and something was up, breaker had triped.
But yea testing show it can't get much better using RM, having only one trigger event has had the best effect shaving off abut 20ms the average.
Will try 2moz with a wait
Is their a 'lighter app ? Simple automation? Basic rule??
Yeah, but neither have Power Meter...
Custom app would be very simple....
definition(
name: "Notify No Events",
namespace: "hubitat",
author: "Bruce Ravenel",
description: "Notify when no event",
category: "Convenience",
iconUrl: "",
iconX2Url: "")
preferences {
page(name: "mainPage")
}
def mainPage() {
dynamicPage(name: "mainPage", title: " ", install: true, uninstall: true) {
section {
input "thisName", "text", title: "Name this notifier", submitOnChange: true
if(thisName) app.updateLabel("$thisName")
input "meters", "capability.powerMeter", title: "Select Power Meters", submitOnChange: true, required: true, multiple: true
input "period", "number", title: "Enter number of minutes to wait", range: "0..*", submitOnChange: true, required: true
input "notify", "capability.notification", title: "Select Notification Device", submitOnChange: true, required: true
}
}
}
def installed() {
initialize()
}
def updated() {
unsubscribe()
unschedule()
initialize()
}
def initialize() {
subscribe(meters, "power", handler)
runIn(period * 60, timeUp)
}
def handler(evt) {
unschedule()
runIn(period * 60, timeUp)
}
def timeUp() {
notify.deviceNotification("No event for $period minutes from $meters")
}Cool thanks can't wait till 2moz to see how quick it is
