Hi all. I currently have a rule that triggers when a power measuring socket goes above/below a certain amount (lights turn on/off on computer on/off). I'm sure there is a better way to the way I currently have and was hoping the more knowledgeable here can point me in the right direction.
I have 2 triggers. 1 for power > 10w and another for power <= 10w. Then I have an action that is IF > 10w turn lights on, ELSE turn off.
That way when power ramps up on turning on, it turns lights on and vice versa. But that also means that this rule is triggered every time the socket records it's status, as the triggers cover everything possible. Surely there must be a better way of structuring to say always keep off unless the rule is triggered?
Thanks for any help.
Alan
KISS would indicate 1 rule to turn on @ >=10W and 1 to turn off @ <10W. Of course you can easily combine this into a single rule but there are no efficiency gains to be had.
Also everytime the plug reports <10W the rule will toggle off but as things are already off, this won't do anything anyway. (and vice versa)
True, it won't do anything but the Hubitat unit will still process that rule all the time and use resources that aren't needed. I just thought there must be a better way. Ultimately I want a WHILE statement. While > 10w keep light on. Just not sure how to do that here.
Required Expressions for your rule may help to reduce the monitoring of the power usage events, if that is what you are looking to improve. You may be able to introduce a virtual switch or something similar to keep tabs on when the power usage is elevated, ensuring it does not re-trigger while the appliances are in use.
Even so the hub still continues to receive the power meter events generated by the plug And the hub still has to process these events to keep the lights on or off, regardless of whether a trigger is set into motion.
I could well be wrong, but I suspect there are no significant (if any) performance gains to be made whichever way one chooses to skin this cat.
Does this use less overall hub resources though?
I can't reliably say yes, but it feels like it would, i.e. it wouldn't subscribe to the power meter events while the switch is on or off, however you configure the rule. "The vibe"... some may say.
That's why I mentioned overall. In order to keep the required expression state you would still need to be continuously monitoring the state of the virtual switch (or even a boolean).
Bruce would be the one to comment on the best approach, but I expect my suggestion at least is either not the preferred setup, or offers a negligible performance improvement, so it feels unnecessary to bother him with the question.... There's likely a similar discussion somewhere if I searched hard enough (at all).
To try and justify my suggestion, my understanding of the required expression was to essentially turn off the triggering of the rule each time the triggers occur, so loading the rule into memory and performing any actions, including evaluating expressions, would not need to occur, reducing the impact on performance where "chatty" devices are involved.
All very theoretical and with enough assumptions on my part that if you (@AlanB) are concerned about the performance of your hub, may be worth considering, but otherwise, I would start by making sure your logic is sound and satisfies your needs, with no impact on the hub. Then look to improve. If you are at that point... Then I probaby need to refer you on to others more experienced than me... 
or me for that matter 
My take on these things is that HE is an event/condition driven system. The more events are generated by a device ("chatty") or app (eg maker API) the more hub resources are used which over a period of time will require a reboot of the hub to clear,
As a heavy maker API user I've been forced (disciplined?) to limit the number of maker API updates for precisely this reason.
Yes, sorry, wasn't meaning to dismiss your input...
I was happy to offer it as an option, but only as something to try, leaving it out of the rule is equally worthy of a trial.
Lol no dramas. I'm being facetious as usual.
Then we are on the same level
Thanks for all the replies. I'm not having any issues. I was just wondering of a better way to remove issues that may come in the future when adding more and more devices 
So no need to dig any deeper
Certainly a good approach to take, and not one to let go.
Beyond the general support of HE staff and the Community for suggestions, use of the Logs screen in more recent times provides more and more stats like apps and devices consuming resources. You could also make use of @thebearmay 's Hub Information driver to provide a central location to assess general health of your hub. If you couple that with either the (no longer actively supported) Hubigraphs Community app, or exporting device details to an external analytical solution, like InfluxDB and Grafana, then you can look at trends in things like memory and CPU usage, temperature, etc.
To add some visual aide into the mix, below is my rule for the washing machine. My trigger is power>200W as that definitely means that the washer is running. By setting the private boolean to false after the first trigger, the rule isn't evaluated again until power goes back to 0 (meaning the cycle is done). So, in your context, you could implement the required expressions, set the trigger to just >=10W and wait for it to drop <10W before toggling the boolean back to true.
Anecdotally, I did this to clear out white noise from logging. I can't say whether or not there was a performance improvement per se, but I leave logging on for RM and this kept the washer rule from throwing hundreds of log entries during the cycle.
