webCoRE has a built in mechanism to serialize piston executions. Sometimes, two events execute a piston at roughly the same time. Since you are building logic that is more or less a series of statements, you don’t expect things to change while you’re following the execution path. That is why webCoRE will attempt to have the second execution wait for the first (up to 10 seconds). This usually happens with very rapid firing events such as power meter events. If all works fine, I would not worry. You can always simply allow parallelism in the piston’s advanced settings.
Ok. So slightly understand more while slightly being more confused lol.
So if I understand correctly:
If I have 2 seperate if statements opposite in test (similar to else/elseif, but not excluded) to one another in the same “execute” in the same piston, semaphore waits are bad in this situation? Correct me if I’m wrong, but does that mean that if2 will not execute after if1 executes while piston is at semaphore. And so if there’s a state change while at semaphore it will not be seen?
I think my last statement just confused me more lol
I only ask as I’m having these semaphore waits cause delays with certain things
It’s about events themselves, not the statements you have or their order. Some or maybe all of your IF statements subscribe to events coming from ST. A semaphore is hit when two or more such events happen in a rapid succession. This can be the result of using power meter readings or what’s called “positive feedback” where you subscribe to events that are generated by the actions taken by your piston (ie subscribe to a switch change and have the piston change that switch - this will keep generating events that will rerun the same piston).
A green snapshot of your piston would help in figuring out why you’re getting semaphore waits.
I was about to post the same question. I have a door automatic lock piston based on the door lock and contact events. Every once in while, the open/close and locked/unclocked events are of sync due to the semaphore delay as 2 events can easily happen exactly at the same time. Is there anything that can be done to prevent this?
Wondering what happens if the event takes longer than 10 seconds? Does the piston continue on or just stop right there? Also curious if anyone has ever had issues where events took longer than 10 seconds and what could cause such delays. Is this at all common or extremely rare?
Hmm what do you know I’ve actually got a piston that seems to be doing this repeatedly just going a little over that 10 second maximum and that’s all it seems to be doing. The automation in the piston seems to work alright, but don’t understand why the logs are filled with that message.
Does this basically apply ASYNC to the whole piston? Wouldn’t that execute some piston lines out of order? Or does it just allow two pistons (or the same piston activated more than once) to execute simultaneously? (If that were the case, it would be nice if it was a system-wide setting).
By default, a new instance of a piston will wait for up to ten seconds to allow any already executing instances of the same piston to finish off before it proceeds. This can result in pistons running at the same time but it will be quite rare as ten seconds without encountering a wait is going it some.
With parallelism enabled new instances of the piston won’t wait, they just run straight away.