View source for Task Cancellation Policy

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<br/>
* 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.

__NOTOC__