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

wait
tcp
#12

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.

#13

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

pic

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

#14

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
#15

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.

#16

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.

#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?