I have a piston in WebCoRE that triggers when a sensor’s reported temperature rises to or above a certain temperature. I don’t see “rises to” as a trigger option, so at the moment I have the trigger firing off of the thermostat changing to the heat state, put in a delay of 300 seconds, then check if the sensor’s temp is greater than X.
A workaround would be to create a rule that when the sensor’s temp changes, it stores the temp in a variable after copying the last value into a “previous reading” variable, and then doing a joint if test for exceeding the threshold desired and checking that the current reading is also greater than the previous reading. One downside is that this rule will probably fire every minute or two with the frequency the temperature is reported by the sensor.
They could, but that would trigger the rule anytime the value changed (and it was greater than the entered threshold).
Instead, it sounds like they only want the rule to trigger one time when the value was below a certain value and then changed from below the value to above the value.
I think you’re on the right track here, though I don’t know that you need to store the previous value.
One approach would be to use a True/False variable to indicate the status. I would use a separate rule just to track this variable… then use that variable changing as the trigger for your main rule.
There’s a few approaches you could take here - one is to just always flag the variable true/false based on the value that comes in. Then in your other rule, you would use a ‘state stays’ true in order to trigger the main rule.
In the example above, I’m using an expression as it simplifies the flow, but you could also use an IF Condition block and then set the variable appropriately within the THEN / ELSE sides if that’s more intuitive to you.
Then in the actual rule, we trigger on $ABoolean stays true for X seconds. If we use a ‘changes and is true’ trigger, then every time the value comes in and the variable is set to true again, it would retrigger the rule. The beauty of a ‘state stays’ trigger is it only triggers the first time the variable changes to our desired value and it has to change out of that state before it will trigger again.
Alternatively, some people prefer using nested conditions and only changing the variable if it’s not already the target value. The conditions make the rule look a bit more verbose, but it’s pretty straightforward when you read through it and it has the benefit of the true/false variable only getting updated when the status actually changes making it easier to use in other rules.
In that case, you can just use the variable changing to true as your trigger in the other rule since we are only setting the variable value if it’s not already in the target state.
Edit: Note that I’m using the Context Variable for the event value as the top-level IF Condition in this example. That tells the rule to use the triggering value in the comparison rather than having to query SmartThings again to see what the value is. It’s more efficient all around.
To give you more context, my use case is having code turn on a ceiling fan after the thermostat calls for heat and the temperature reported by a vent exceeds 80 degrees (no sense in starting the fan early if the incoming air near the ceiling isn’t warm enough yet). Hence my need for a trigger only once when the vent temperature crosses the 80 degree threshold on the way up. This should set another boolean variable that tracks the fact that the fan was turned on via code, so I can use that to turn off that fan when the temperature drops below some threshold when the thermostat goes idle.
I’m going to attempt to implement Josh’s expression version just to make the rule look cleaner. The Expression screenshot is a great example for me to follow.
I have some cases where I just let it run duplicates. Depending on how you’re controlling the fan (IR blaster that turns it on or off every time you use it wouldn’t work), I don’t think it matters much if you toggle it on multiple times. It would just stay on, depending on the refresh rate of the thermometer and how often the temperature actually changes.
It might be unnecessary traffic, but not huge.
I also like combining rules that are meant for a single case. So in @josh 's example, I’d add the second rule into the first one. It’s easy with the context variables. But I do wonder if it slows things down a lot, since it’s going over if conditions that are not met. It doesn’t work great for expansive things either, makes it hard to troubleshoot or add/change devices.
