Simultaneous Arrivals

#1

I have a piston that has been working for a while and I have just been dealing with a particular problem. When multiple people arrive at the same time, my piston would not restore the lights to the previous state. Thus I wrapped the entire piston in a variable called “someone_arrived” and it is default to fasle. The idea was to have it set to true when someone arrives thus if multiple people arrive, the piston would continue to run and restore the lights for the individual and eventually reset the variable to false.

However, my variable is not always resetting to false and remains on true, thus not running until I manually reset it.

image
image.png1178×1805 243 KB

#2

You need to add a set someone-arrived to false at the end of your activity. Right now nothing changes it back once you are done setting the thermostat.

#3

On Line 31, I’m setting someone_arrived back to false. After doing so, shouldn’t the piston continue to execute the remainder of the commands?

#4

Line 22 is a trigger, meaning it is only true for a brief moment. Normally, when the trigger turns false, (a moment later) the rest of the code is aborted. This can be overridden by setting the “TCP to Never” on blocks containing a WAIT and the blocks below. This will force the code to continue to process, even if the trigger or conditions are no longer true.

The tricky part will be what happens when a second person arrives or exits. The code will once again start at the top… yet there may still be previous code scheduled to run…

#5

Would you set the TCP to never on the block from 30 - 31 or would you put in on the entire If statement beginning on line 24 to cover the entire piston?

I already had it set on line 70.

#6

Honestly, I try to avoid long waits on pistons that get triggered frequently…
Instead, I would move the waits (and the final logic) to a separate piston.

This lets the presence trigger be quick and snappy… and if done right, the piston with the wait will only trigger once at a time.

#7

I only set TCP on WITH blocks. Never on IF blocks.
(I don’t think the IF block acts like an umbrella)

#8

If you don’t mind making some minor changes to your piston, you can take advantage of some of the features of task blocks. So, instead of using booleans to mitigate your simultaneous arrival problem, try this:

execute-tasks-on-conditition-state-change-only
execute-tasks-on-conditition-state-change-only.png1178×479 41.5 KB

Insert your tasks within the DO block; notice its Task Execution Policy is set to “Execute tasks on condition state change only”. So, when the first present sensor arrives, the condition for the IF changes to true and the tasks within the DO block are executed. When subsequent present sensors arrive, the DO block is not executed since the state condition of the IF is still true, i.e., its state did not change because there is at least one present sensor that is present.

Also, a word of caution — be careful using nested ASYNC IF blocks. IIRC, there was a problem during webCoRE’s development that when using nested ASYNC IF blocks to a level of two (or was it three?) or greater, the piston behaved very inconsistently. I don’t think this was ever fixed.