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

ike2018 · 2019-11-20 14:11:08 UTC

any suggestions and/or corrections, please jump in…

SergL · 2019-11-20 15:09:55 UTC

Great start! This is good info to have/share. The specifics that I would like clarification on is why the piston used as an example would not complete. It is my understanding that because the trigger is “changed to” active which starts the chain. Once it waits those 10 minutes, the device no longer “changed to” but “is” active and that’s why it cancels the subsequent action?

Lastly a more concise clarification on when or why to use wait might be helpful as well. For me I have very small wait times (600-800 milliseconds) in some pistons to allow ST to be able to process all the commands. For example when adjusting multiple bulbs I would set color, set level, wait, turn on. It might have been my previous inexperience with WC but in the past I felt that just sending large waves of commands to ST clogged it up and by adding some wait times it assured a more precise execution.

ike2018 · 2019-11-20 15:15:38 UTC

Yes exactly… if a trigger or a condition or both is/are no longer TRUE in your piston, the piston will stop…

Even with conditions it’s the same thing:

Lets say you want to use a condition but you want something happens X amount of time after condition is no longer TRUE… You can use wait.

IF the bedroom lamp IS not ON (condition)
Then
WAIT 5 minutes
And do this do that

And this is not in the original post but lets say you have a WAIT 10 minutes in your piston BUT if certain things change, you want to stop the WAIT, then you can use the command CANCEL ALL PENDING TASKS…
Now piston will stop the count down.

WCmore · 2019-11-20 15:22:24 UTC

This will be very helpful to new users… Thanks for taking the time to compose this.

Pro Tip:

Here is how you can change the TCP in only two clicks:

Click on the empty space next to the WITH. (shown highlighted in magenta)…
Change TCP in the top right. (shown highlighted in yellow)

ike2018 · 2019-11-20 15:29:00 UTC

Oh dang!!! @WCmore I didn’t know that…Thank youuuu

And yes this post meant for new - brand new - users only:))))

orangebucket · 2019-11-20 19:31:56 UTC

Not quite. A wait over five seconds is implemented by scheduling a new execution and exiting. If, during that ten minutes, the motion sensor changes state the piston will be fired and executed from the top. The ‘changes to’ condition will no longer be true as the previous value will now be ‘on’. At this point the scheduled wake-up will be cancelled (you see log messages about cancelling schedules all the time).

If the motion stays active the piston will wake-up after ten minutes, execute, fast forward to after the wait and turn the lights on. It does not check the conditions after the wait.

If the wait was only 5 seconds or less (roughly) and the motion changed, the new execution would be held at a semaphore and wait up to ten seconds for the current piston execution to finish (in my limited experience it is always ten seconds but it is supposed to be up to ten). That means the light would turn off.

If the piston were more complex and didn’t reach the parent condition of the ‘wait’ when executed the wake-up would again not be cancelled. It is only the immediate parent that matters.

Setting the TCP to Never prevents the scheduled wait being cancelled if the ‘wait’ must happen. It can be applied on the ‘if’, the ‘with’ or the ‘do’ (in ‘do wait’). If you think about it hard enough you could come up with different outcomes.

Pantheon · 2019-11-20 20:57:33 UTC

I think this is an excellent topic. I was very confused about all of this when I started using webcore. Some aspects are still confusing…such as…

Is there any good documentation of this material anywhere? I would be happy to write it up and add it to the wiki if not. However, with the imminent changes to webcore just around the corner, would it be fruitful to do so now?

ike2018 · 2019-11-20 21:23:59 UTC

I thought about the same but mean while new users are keep coming, so I started the topic.
But most will be useless soon I guess…

ike2018 · 2019-11-20 21:25:48 UTC

A lot needs to be covered of course. My topic is only for simple WAIT and do this do that questions…

WCmore · 2019-11-21 03:31:30 UTC

Sorry for paraphrasing below, but with regards to the default TCP, this is worth repeating…

In the past, a trigger such as:

would only be true for a few seconds…

Just now, I tested a full 8 minutes, and it was still true and continued to process the next line of code (as long as the switch did not change during the WAIT). I am running an 8 hour test now.

This is great news, and means that a lot of blocks will no longer need TCP fiddled with…
(perhaps ixnay on motion sensors though, since they change so often)

Edit:

I have not tested this logic with contact sensors changing to X yet…

orangebucket · 2019-11-21 07:56:36 UTC

Yes, I have seen a lot of comments to that effect, and a previous one about how it has changed. I’m a relative newcomer to webCoRE compared to many on here and I’ve never encountered that behaviour. I’ve never known if the behaviour has actually changed or if users just believed that was how it worked and so had been making perfectly correct changes to TCP for the wrong reasons, along with some unnecessary but harmless ones.

In the code, triggers are simply comparisons involving a new value and a cached value. They can only evaluate as true if the piston is currently executing because of a change to the attribute in that trigger. If the piston hits a ‘wait’ that is long enough for it to exit and wake up again (say five seconds or more) the trigger can no longer evaluate as true.

As the trigger can only evaluate to true for the short period the piston executes, it could be considered that it is only true for a few seconds. However it is rather an artificial concept as it is only true or false when it is evaluated.

A companion to ‘triggers are only true for a few seconds’ is the idea that pistons get to the end of a wait and then go back and check the parent conditions. It is perfectly reasonable to think that is how TCP might work and generally harmless. You can see from the logs that it isn’t what is really happening though.

WCmore · 2019-11-23 03:01:34 UTC

I just want to confirm… even after eight WAITS (60 min each), the piston was still going strong using this trigger:

IF Device's switch changes to on

Essentially, even with TCP set to default, it continues to work until the switch changes.

Pantheon · 2019-11-23 12:50:50 UTC

So, I’m still trying to understand this better. I assisted someone recently with code that I frequently see here…

If Temperature_Sensor_1's temperature is above 90 degrees
Then
  Do
    Wait 10 Minutes
    Turn on Light_One.

I understand that it would be better to use Rises Above 90 degrees. But would the IF statement result change (or be re-evaluated) as the cycle time of the temperature sensor changes and the temperature changes from say 90 degrees to 92 degrees? And if so, would the Wait be cancelled and therefore not execute the Turn on?

Similarly, would the following be a good reason to use TCP set to Never? Or is there a better way to code this?

Turn Light_One On    
While Motion_Sensor_1 motion stays active
      Do
        Wait 5 minutes
      END while
Turn Light_One Off

orangebucket · 2019-11-23 20:29:05 UTC

If the piston is fired during the wait, and the execution gets to the condition, and it evaluates it and the result has changed, then yes the wait could be cancelled. Obviously if the temp was 90 there wouldn’t be a wait to cancel, but if it was 92 and then 90 there would.

The question is whether the piston is fired during the wait. If that is the whole piston then it will do if the temperature changes. If is part of a bigger piston then it depends. There being a wait doesn’t change the usual behaviour.

‘Stays active’ takes a time argument and does the equivalent of a wait so it isn’t really a valid piston.

The point of the discussion is that ‘TCP Never’ is often being used correctly, but for the wrong reasons, or is being used needlessly, but generally harmlessly. Sometimes it is being recommended when it is just wrong.

orangebucket · 2019-11-23 20:50:23 UTC

However it should be emphasised that it will stop if you hit the ‘Test’ button in the meantime, or execute the piston in another way. The key is that the parent condition has to be evaluated. Once it is the trigger will not evaluate to true as the device’s switch hasn’t just changed to on and TCP kicks in.

WCmore · 2019-11-23 23:30:54 UTC

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

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

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.

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.

Pantheon · 2019-11-23 23:49:05 UTC

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

WCmore · 2019-11-24 02:32:03 UTC

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!

WCmore · 2019-11-24 05:18:39 UTC

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…

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

orangebucket · 2019-11-24 08:21:56 UTC

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.