Optimizing Rules in SharpTools

When it comes to building rules in the SharpTools Rule Engine, there is a lot flexibility in how you can set things up. And while there's no 'right' way to build a rule, there are some ways to optimize your rules.

These tips focus on how to make your rules run more efficiently and thus, faster.

Redundant Triggers and Conditions

A common anti-pattern we see is when a Trigger and Condition in a rule effectively do the same thing.

In this example, the rule waits for an 'on' event which then triggers the rule flow to run. The first step in the rule flow is to query for the state of the switch to see if it's 'on' – since we already know that the switch is on, the rule is taking unnecessary extra time to query for the state. In this case, the IF Condition could be dropped completely.

But what if your trigger is based on a range of values and you still want to use IF Conditions for various cases? See the next tip on using context variables!

Context Variables

If you want to use information about the event that triggered your rule, Context Variables are your friend. These provide context about the event like the device name, attribute, value and other helpful details.

A common example is using the 'value' from the event that triggered the rule as a condition. Rather than having to query for the state again, the rule can just use the value it already knows about from the 'event context' which saves precious time. When setting up conditions or actions within the flow, you'll find context values under 'Variable' selection.

This means you could use the value that triggered your rule in a condition (for lightning-fast comparison) or you could even include it directly in a notification!

Variables - Snapshotting Conditions

While Context Variables are helpful when you are looking to reference details about an event that triggered your rule, regular Variables can be used for a broad range of use-cases. Variables can be used to store data, can be referenced across multiple rules, and can even be used to trigger or act as conditions with other rules.

A neat way to use variables is to snapshot complex comparisons or calculations and use them across multiple rules. For example, you might have several conditions you like to consider within multiple rules. Rather than having to add the same triggers and same conditions across multiple rules, you could create one rule for evaluating your comparison and saving it to a variable... then you can use that variable in your other rules!

For example, I might create a rule + variable to track when everyone in the house is home. That way in other rules, I can just reference this one simple variable without having to recreate the condition over and over. That also means that if the condition ever changes, I can just change it one place and it will automatically take effect in the other rules that reference the output variable:

Scenes / Routines

If your hub has a concept of groups, scenes, or routines you may be able to use those resources in your rules. When sending multiple sequential commands from a directly from a rule, you might notice some 'popcorn' effect as each light turns on slightly after the previous one.

Using groups/scenes from your hub can be an efficient way to trigger multiple actions all at once.

Even if you hub doesn't natively expose your desired group/scene, you might be able to trigger it using a rule within your native hub interface. A common approach is to expose a Virtual Switch to SharpTools which can be controlled in a SharpTools rule. Your hub can react to that virtual switch changing and run your desired group/scene.