Sorry if this is in the wrong category. I’m wondering about the intended function of
"were not" as a condition. As in The sensors 'were not active for at least 10 minutes."
Does that mean
Thanks
The sensors were not active for the last 10 minutes.
I think.
I suppose it depends on how you use it.
Care to post your use case?
Sorry, that is the exact phrasing I was questioning. Do you mean that you think its like my Option 1?
Here is one example.
I asked for a general clarification becuase it seems this configuration should work, but it did not in various pistons I have used in the past. So others have told me to go with…
That is what I had, and this morning and it failed. All my lights shut off on me while I was walking around getting ready this morning. I think at the 10 minute mark it checked and by random coincidence all of the sensors had just switched that second to Inactive.
You could change it to.
IF
Time is between
AND
All contact sensors are inactive.
THEN
WITH
All your lights.
DO
Wait 20 minutes
Turn off.
On the WITH, click on the settings cog at the bottom and set TCP (Task Cancellation Policy) to never.
This way if there is no motion in the wait period the lights will turn off after the 20 minutes.
If motion is detected in the 20 minute window the timer stops and when inactive again the timer restarts.
Is this what you are after?
Never cancel? But I do want it to Cancel if motion goes active, don’t I? I’m confused. The rest, I understand what you are proposing. (I would love the education of the TCP, because I’m clearly not understanding it correctly if Not Cancelling on State change is the right answer)
I would also like the education of why people often recommend not using Restrictions and putting them in the IF section. It seemed like Restrictions were there for a reason. I would love to know if its for a different reason (thus I’m using them incorrectly)? Or if Restrictions cause glitches and that is why folks tell me not to use them?
But what I really want to know is why "were not active’ is not the right answer. I need to understand it rather than find a work around, so I can learn the language and keep applying it correctly. If the answer is that that means Not active for 10 minutes straight’, then it makes sense not to use it. But that seems unlikely to be what that is supposed to mean. ‘Were not active’ seems like it should mean not active during the specified time frame.
The correct interpretation of the Were Not is what I truly am looking for. This particular piston worked fine for months until it glitched today.
Thanks so much for your help. It is tremendous when someone takes the time to teach.
If you leave the settings to the default “cancel tasks on piston state change”, then when the piston state changes, which it will because you have stated “changes to present”. By picking changes to present, this will only be true because you have used changes to. After a short period, I think its 10 seconds but I’m not sure, that statement will become false as it will reset and wait for it to change again. Therefore you tasks that follow it in WITH > DO will cancel because TCP is set to cancel on piston state change. If you select never then it will not cancel the tasks when presence changes to not present becomes false after 10 seconds.
Also when never is selected, as I said in my earlier reply, the tasks will continue to run unless the piston becomes true again and then it all restarts again from the top.Make sense??? I’m useless at explaining these things.
I do use restrictions for time as well. There is no right way I suppose, just a preference that I have.
I don’t think they cause any glitches.
I do use that as well believe it or not. From my point of view I have been there at the early stages of webCoRE and these sort of actions were not available.
To be honest I’m not sure if as soon as the piston is resolved, that the timer starts, or whether it knows how long they have been inactive and then evaluates them straightaway. I suspect it’s from when the piston is resolved.
Looking at your piston, I cannot help thinking that it could be that you are mixing a trigger and a condition in your IF. What happens if you change “changes to not present” to “is not present”.
Also you have “were not active” for 10 minutes and also a wait 10 minutes in the DO.
Try changing the “were not active” from 10 minutes to 20 minutes and deleting the wait 10 minutes in the DO.
Hope this all helps. 
It is option 1.
Was/were evaluates the past
Stays evaluates the future
So when a piston executes a was statement it looks at the previous time.
When a piston executes a stays statement it needs to wait until the future for the time
