Difference between revisions of "Task Cancellation Policy"

Latest revision as of 13:17, 26 November 2019

When a task execution is delayed by any means (i.e. a Wait task), it may become necessary to cancel its execution before that delay passes. For example, you want to wait for 2 minutes before turning off a light, but during the two minutes, a need to keep the light on arises. In this scenario, the Turn off task needs to be canceled. This is where the Task Cancellation Policy" comes into play, allowing such scenarios.

Task Cancellation Policy, or for short, TCP, has four possible options:

Never cancel tasks

Use this option to allow the task to execute even when conditions change

Cancel tasks on condition state change

This is the default option and will cancel any pending tasks if the parent condition's state changes. If the tasks are not executed as part of an IF statement, then this option is the same as Never cancel tasks

Cancel tasks on piston state change

This option will cancel any pending tasks if the piston's state changes.

Cancel tasks on condition or piston state change

This option is a combination of the previous two and will cancel the tasks if any of those conditions are met.

Quick Summary

Since this topic is normally researched when dealing with WAITs, here is a quick summary:

With TCP set to default:

• If, during the WAIT, the trigger device stays the same, the piston will wake-up on schedule, and continue
  
• If, during the WAIT, the trigger device changes, then the scheduled wake-up will be cancelled.
• If, during the WAIT, the trigger device changes twice, (away & back), then the original schedule will be cancelled, and a new one will be set.

If you do not want the WAIT to be cancelled, then set TCP to Never on that WITH block.