Task Scheduling / Wait

#21

To “close the loop” on this one, here is what I found works better than stays:

image
image.png1178×514 25 KB

The important bits (for others that might come across this later):

  1. Since the motion sensor is in a condition, not a trigger, and since there are other triggers in the piston, the Subscription Method attribute of the condition needs to be changed to Always. (Otherwise the piston would not subscribe to the motion sensor’s events.)
  2. The Task Execution Policy attribute of the with statement (or all the statements in the then clause if there were more) need(s) to be changed to “on condition state change only”. (I put a “C” in the comment since this attribute is hidden in a “with Location” statement. This setting is needed, otherwise the tasks in the with statement would start over if the piston ran again while the motion sensor was still inactive - e.g., if the button was pressed.)
  3. The if statement’s Execution Method attribute needs to be changed to Asynchronous. (Otherwise if the piston runs again for another reason - say the button was pressed - the if statement’s condition would not change and the statements following the if statement would be skipped. IMHO this is a bug, but changing the if to asynchronous makes it work.)
#23

And what I am saying is that there are other ways to get the functionality you want. If you use a condition in addition to a trigger, then you will get the result you want. I have an example with routines for my thermostat. You’ll notice that there are only 4 triggers. But the other conditions prevent the actions from happening unless they are met when the trigger happens. You can do the same thing with your I’m Back routine. If you only run it when you are away, then it won’t run again while you’re home, right?

download%20(3)
download (3).png1178×1241 134 KB

#24

I’m confused. I thought we were recently talking about the behavior of the “stays” trigger. I don’t see that anywhere in your piston.

Yes, in general, I totally understand how conditions can filter triggers. But I don’t think that helps with the fact that the “stays” trigger can become true again if the piston runs for other reasons. That’s all I’m saying here. I’m not arguing with the fact that conditions can filter triggers, which of course, is a very useful thing.

#25

You were saying that stays will trigger again…and yes it will…unless you use another condition to cancel it out. That, IMHO, is a lot easier than screwing with TEP.