"Stays Inactive" vs "Changes to Inactive & then Wait"

#1

1) Give a description of the problem
I want to understand the difference between two approaches to a common goal:

  1. Set Sensor to “Stays Inactive for X minutes” Then shut a light off
  2. Set Sensor to “Changes to Inactive” and Then “Wait X minutes” and shut a light off

Both of these are triggers if I understand correctly. When does it make sense to use one versus the other? Is one more resource efficient than the other?

2) What is the expected behavior?
To wait X minutes prior to turning a light off.

3) What is happening/not happening?
Both seem to work, just trying to determine which is accepted best practice.

Thanks for any insight.

#2

As you know they are functionally the same. However the big difference would be how the events come in.

Since these are both triggers there is an exact moment that both of these become true. They will not remain true for very long because that is the nature of the trigger. When the piston is no longer true it will start canceling tasks by default. This behavior can be changed but if it can be worked around it is better in my opinion.

So to expand on what I mentioned above about cancelling tasks. When you use the changes to inactive and then a wait. It will depend how long you are waiting. More than 30-45 seconds and you will see the rest of your tasks getting canceled. This is because your device no longer just changed to inactive. So your piston state is false. As I said before you can curtail this behavior by setting the task cancellation policy to never. All the tasks will execute and you’ll be a happy camper.

On the flip side of things you have stays inactive for xx time. Now this only becomes true after your time period which should allow for your tasks to complete. Unless there is some lengthy waits or fades you are trying to accomplish. Which then you need to start messing with the TCP again.

#3

Thanks, that was exactly the information I was looking for. I never realized on changes conditions could be nulled if the action becomes untrue during a wait period, but logically that makes sense.