How TCP is set to NEVER - when WAIT is not working in your piston

wait
tcp
#17

This is not entirely true… Take a look at this simple piston, with two triggers:

pic

In this test, I turned on Switch 2, counted 8 seconds, then turned on Switch 1.
Both WAITS stayed true, as seen here:

pic
pic.jpg788×440 49.4 KB

Side Note:

I did the exact same test again, but this time I turned on Switch 1 first…

The results were very different. Switch 1 never completed after the wait.

pic

Honestly, I tend to only use single triggers in each piston, so this doesn’t affect me much… but a lot of people use multiple triggers in the same piston. It is important to realize that (if TCP is set to default), the ORDER of the triggers plays a part.

In other words, in the code:

  • If the 1st trigger is below the 2nd trigger, they both work as expected…
  • If the 1st trigger is above the 2nd trigger, the 1st trigger cancels out.
(another) motion lights control question
#18

Very interesting. I doubt that was by design. But it does explain some of the “wait” problems that I have seen.

#19

In the second example above, I suspect it cancels because once the piston reaches the code for the 2nd trigger, it does not return back to the top to finish the 1st trigger…

Honestly though, it is the first example that really surprised me!

#20

For those following along, this is a great example of why it is so tough to accurately summarize “best practices” here in the forum or on the Wiki…

There are very few “blanket statements” that can be made without also listing a handful of exceptions…

Those who know me, know that I rarely use the words “Always” or “Never”… This is because nearly everything we have learned, may only be true some of the time, and in certain situations…

pic

I guess, from a philosophical point of view, real life is this way as well…

#21

Yes, because when you turned on switch 1 the piston entered WAIT A. The piston hadn’t reached IF B to evaluate it.

If WAIT A was say 10 seconds things should be different. Or indeed if there wasn’t a WAIT A. That way IF B would be reached.

Yes, when switch 2 fired the piston executed and immediately hit IF A and the trigger evaluated as false so WAIT A was cancelled.

Evaluation is everything.

#22

Here is another example where things don’t work as people might think:

if 
    Door Sensor contact changes to open
then 
    if Time is between sunset and sunrise
    then
        with
        Hall Light
        do
            turn on
            wait 10 minutes
            turn off
        end with
    end if
end if

So during the night, if the door opens the light comes on and ten minutes later it turns off.

The door being closed does not stop the light being turned off on a delay. Not only is the Time restriction not reached to be reevaluated but it probably wouldn’t have changed anyway. Only the parent condition affects TCP.

The only way the delay doesn’t complete is if the door opens for a second time during the wait and it is now after sunrise.

#23

I am not trying to be argumentative, but your second sentence is not true either… In this simple piston:

pic

If Switch 1 turns on, then the piston runs top to bottom… BUT… if Switch 1 turns off during the WAIT, the piston cancels, and does not finish after the WAIT.

#24

That’s what I was questioning above. If the state of the device changes, whether expected or not, then the wait is cancelled and execution starts at the top of the piston again. Yes?

#25

If a subscribed device’s attributes CHANGES, then the piston starts over at the top. Whether the WAIT is cancelled or not, is not an easy answer. Both Yes and No examples are above.

#26

Makes me want to avoid WAITS and TCP altogether. But sometimes, I just cannot build a better solution. Ugh!

#27

I wouldn’t avoid WAITs… They can really add ingenuity to our SmartHomes…

What I sometimes do is use a couple of Simulated Switched and a basic structure piston to play around with various logics and timings…

pic

Using log to console, it makes it real easy to see what was executed, and what was bypassed.

pic

43:54 = Switch1 manually turned on
44:25 = Programmatic logic
46:11 = Switch1 manually turned off
46:16 = Switch2 manually turned off

#28

Sometimes the most simple solutions are the hardest…

#29

A testing “Sandbox” is your friend… LOL

#30

Something really odd is happening at the moment. If I had run your piston this morning (as I did my own several times), the switch changing back to off would not have cancelled the wait, it would have woken up and completed. That is not happening. However neither is it being cancelled. It is waking up and not doing anything. That just doesn’t happen.

#31

This is really weird… Is this because of second nested IF ???

I’m not home Wcmore as you know so I can’t test it my self but let me ask you this example:

IF motion sensor x changes to active
Then
With RGB do turn ON
Wait 10 minutes
With RGB do turn OFF
Then do this do that (in the same IF block)

This supposed to wait 10 minutes and keep going after… correct?

#32

Just a reminder: The last ~20 posts have been focused on TCP kept at the default setting. The better we understand that, the better we know when changing to “Never” may help

In reference to this piston:

pic

It cancels because whenever Switch1’s switch changes (in either direction), the entire piston runs top to bottom, and executes anything not blocked by conditions. In this case, when the switch turns off, it checks line 18, determines it is false, and then cancels the previous WAIT. (unless TCP is set to Never, of course)

Well, if the trigger was a bulb changing to on, then yes, it would continue after the WAIT, as long as the switch was not changed during that WAIT.

But with a motion sensor… I dunno. If it follows the same logic as the switch trigger, then theoretically: IF the motion stayed ACTIVE for the entire WAIT, then yes, it should continue on afterwards… That being said, motion sensors may often go inactive briefly… even when you are still in the room… If that happens even once during the WAIT, then the piston will re-evaluate the motion sensor, and cancel out the previous scheduled wakeup. (which can, of course, by bypassed with TCP)

#33

Guess my testing isn’t thorough enough. I’m now consistently seeing the pistons not (re)scheduling the wake up and then waking up anyway and doing nothing. I’ve now no idea how anything works.

#34

I’ve had some sleep and coffee now, and I re-read this. This logic adds an additional dimension to the thought process when designing pistons.

Unable to restore lights to saved state
#35

I think you have a better grasp than most… It is just really hard to say a single sentence that is 100% accurate…

IE: Nearly every “rule” has exceptions to the rule…

Using Wait in a timer
#36

Oh I don’t mind being proved wrong over the nested IF example, even though I am pretty confident that I have tested it on at least three different occasions over the last month or two and it behaved differently. It still doesn’t claim to have cancelled the scheduled wakeup.

What is confusing me is that even with the simple one level IF THEN WAIT I am now seeing different behaviour to that I have seen for several months. Timer events that are supposed to be cancelled are suddenly firing the piston which then does nothing.

It is like the piston now doesn’t know there is a wake up scheduled so it neither cancels it nor reschedules it, but neither does it know what to do with it when it turns up.

Wait 5 Minutes and Turn Lights Off