I am looking to possibly migrate over to sharptools from webCoRE and have been messing around recreating some of my automations in sharptools. Is there any guide/ documentation around best practices for rules being setup? For example I am trying to recreate my laundry room monitoring automation but I’m not sure I’ve created it the best way possible.
For the automation I am using power monitoring as a trigger to run pretty much all of the logic. If power rises above 50w I know the washer or dryer is running depending on the plug and if it drops below 10w for 30 seconds I know they are done with their cycle. I use variables to keep track of the different states and use the dryer starting as an indicator that the wet clothes have been taken out of the washer. I then send a reminder every 15 minutes if the wet clothes are not taken out of the washer.
I’ve created 3 rules to handle this 2 of which seem to be needed for the power being under 10w for 30 seconds. Not sure if that is the best way to handle it or not. Having the 3 rules instead of just 1 seems incorrect, but I’m not sure how else to reliably accomplish the tracking otherwise. I’m also not sure if having that main triggers in my main rule is efficient or going to cause issues / slowness. Would breaking each trigger into its own rule be better? I also can’t figure out how to create the reoccurring timer every 15 minutes seems like minimum is every 1 day.
The only issue I ran into was when the trigger was set to greater than or equal to 0, it triggered too often and stopped the rule. If you run into this issue, you may need to adjust the power in the triggers. I think it really just depends on the device measuring power though and you.
If by reoccurring timer you mean something like a loop, create a true/false variable. Set that variable changing to true as a trigger. For a 15 min ‘loop’, in the flow, set the variable to false, delay 900 sec set variable true. (This re-triggers the rule).
So like this? Is it okay to have it in the main rule or should it be in it’s own? I assume the 15 minute delay causes everything else in the rule to stop, or does each trigger spawn its own instance of the rule to run?
Edit: Realized I needed to move checking if the washer was empty from the “top level if” to within the if so that it would always trigger to cycle through the loop variable.
Yes, each trigger causes the rule flow to execute.
Edit: As @Terri mentioned, sometimes it’s better to break rules down into their constituent components. I know that’s a bit different coming from WebCoRE where each top-level IF statement could act like it’s own trigger – like multiple rules within a single rule. But as Terri mentioned, there are some rate-limits on rules and while most people won’t run into them in the vast majority of cases, this could be one of those potential cases as power attributes can be really chatty.
So in that instance (and for the dryer as well) those should be their own rules and use a variable to trigger the main rule so that way the larger rule flow doesn’t spawn too many times at once?
With more people moving over from WebCoRE, I suspect we’ll see requests for ‘rises above’ type triggers as you showed in your original WebCoRE rule. I believe that would both simplify this type of rule and significantly minimize the number of flow executions.
Technically, the system would still have to check each event against the triggers behind the scenes, but the rate limit is on the flow executions rather than the trigger evaluations – that’s why Terri mentioned that you might play with adjusting the ‘greater than’ and ‘less than’ thresholds in the trigger comparisons.
Another question I have… When a rule flow is executed is a “snapshot” essentially taken of the state of everything on the hub and then that snapshot is used for the remainder of the rule flow? And if yes, does that include sharptools variables as well?
No, each step in the rule evaluates the conditions / commands in isolation.
For example, if you have something like the following, the command from the first IF condition would likely impact the state when the second IF Condition is run.
IF My Light is 'off'
THEN My Light > on()
ELSE
IF My Light is 'on'
THEN My Light > off()
ELSE
I would note that Context Variables can be used to get a ‘snapshot’ of the event that triggered the rule. For example, you could grab the device name or device value that triggered the rule and it will not change during the rule flow (as it’s always going to be the same event that triggered the rule).
I have several pistons I’ll be converting that use timers. Instead of creating a specific timer for each rule like I did for the washer/dryer is it better to just make a general 5/10/15/etc. minute loop timer and then use that to feed each rule that needs it or does it not matter?
Loop timer, would use $LoopTimer2Minute turning false in other rules to "trigger the timer:
I don’t know if it’s better but it can make some things easier and a lot less variables to sort through. I use a combination of generic loop variables like your example to make sure lights turn on/off just in case the trigger is missed, as well as loop variables specific to rules (like your washer/dryer rule).
Edit the best part about using the generic loop variables is it doesn’t matter which state you select as a trigger since it runs constantly and will always change state.
I may be misunderstanding something but I had found that once a Rule enters a delay, while new triggers may well re-trigger the Rule execution, once any delay in a Flow completes that part of the Flow will continue. That is why you had to help me add statements to cancel the Flow when a delay completed.
That’s correct. Each new event that matches a rule trigger will cause the flow to start running from start to finish (of course ‘finish’ depends on the various conditions/states during each execution as they can impact each other depending on your rule’s configuration).
So if you had multiple events come in, then each will run the flow through to completion. Imagine we had a rule like:
Triggers
Switch 1 changes to on
Switch 2 changes to on
Flow
Wait 10 seconds
IF Switch 1 is on and Switch 2 is on
THEN Set $BothSwitchesOn = true
So if both switches start as turned off and Switch 1 turns on and then 5 seconds later Switch 2 turns on, then the variable would be set to true twice:
The flow will be triggered when the first switch turns on, will wait 10 seconds (and within that 10 seconds Switch 2 will have turned on), it will hit the IF statement and both switches will be on, so it will set the variable. And since the second Switch was also turned on 5 seconds after the first, it will run through the flow, hit the wait, then resume and the IF condition will also match the IF condition and set the variable.
Alternatively, if both switches start as turned off and Switch 1 turns on and then 30 seconds later Switch 2 turns on, then the condition would be false on the first pass and true on the second:
The flow will be triggered when the first switch turns on, will wait 10 seconds, it will hit the IF statement and only one of the switches is on, so it does nothing. Then the second Switch is turned on 30 seconds after the first, so it will run through the flow, wait 10 seconds, and at that point, the IF condition will be true so it would set the variable to true.
I changed the trigger to match the IF statement.
If power is less than or equal to 3
If power is greater than 100
I had to watch the device in ST closely for an entire wash cycle to get the power levels that worked best. I went with less than 3 because when the washer stops to drain before the rinse cycle power would drop to about 8. Less than 3 I know it’s actually done.
Here are my 3 washer rules. I used 2 variables for high and low power because I didn’t know what I was doing when I wrote them and as the saying goes “if it ain’t broke don’t fix it”
Hmmm okay, I think I need to record my washer and dryer running a cycle again and see if I can find more precious values. When I made the automation in webCoRE it didn’t matter if it was close or close enough.
