Executing piston from another piston in high frequency...potential problems?

#1

When executing a piston from another piston in high frequency, is there a potential risk of their execution getting cancelled? I guess my understanding of how pistons run is pretty blurry. I don’t know if each execution runs in it’s own instance, or if it’s like a physical machine…if it’s running and something else calls it, then the caller either has to wait, or the piston restarts from the beginning cancelling whatever it was in the middle of.

I know there’s settings to define whether to wait for an executed piston to finish or not. As well as settings regarding parallelization and execution/cancellation policy. I’m still trying to read up on those, so I’m sorry if this is already covered in those sections of the wiki.

See my example piston below. I’ve built this to handle all of my notifications…I can set it to notify via SMS, Echo Speaks or PUSH. I can also choose which contacts for SMS messages to be sent to.

In most cases, I don’t see this piston being a problem…but for some uses, I’m worried that a high frequency could cause problems, and I don’t have an easy way to test this off the top of my head.

For example, I have a piston that will notify me for every physical action that takes place in the house, if everyone is away. If something happens, then it executes this piston telling it to send me a text for each action. However, our roommate is not part of our smartthings setup, so when only they are home, I’ll get a stream of texts for things like doors opening/closing, motion triggering, etc. I’m curious to know if while the piston is in the middle of running, and it gets another execution request…do those execution requests pile up, or do they tell the piston to give up what it’s doing and start over?

download
download.png1178×1515 179 KB

#2

Pistons are essentially event handlers, be that time schedules, or device attribute subscriptions, or in the case of executed pistons, bespoke location events.

The default behaviour of webCoRE is to serialize piston execution. So if a piston fires up a new instance in response to an event (in your case execution) and there is already a piston executing, it will ‘wait at a semaphore’ (a busy loop) to give the piston a chance to finish. The code suggests a semaphore wait is up to ten seconds but I’ve never seen one that isn’t ten seconds (plus or minus a little bit). That doesn’t mean more than one piston instance won’t execute at once, but ten seconds is a long time for a piston to execute so it makes it much less likely.

Executing serially is good for avoiding conflicts with local variables, and indeed other conflicting behaviour. However where conflict between instances isn’t going to be an issue, and/or semaphore waits create problems of their own, you can enable parallelism.

As for whether high frequency can cause problems. Quite possibly but I can’t offer any specifics. As SmartThings evolves I suspect we will move towards more limits on what can be done in order to protect the wider system.

#3

Awesome, thanks for the info. I’ve been wondering what that semaphore log message was for. I’ve seen that on a handful of my pistons in the logs. Which is funny, because I’ll see that message even on pistons that don’t even run that often. I wonder if there’s something causing multiple executions to trigger that semaphore event that I need to look into and fix.

#4

If you consider unlocking a door fitted with a contact sensor and entering a room fitted with a motion sensor, you could see that a piston handling all those events could get fired three timesun a second or so. That is one typical semaphore wait scenario.

Another would be what is sometimes called positive feedback. A piston might subscribe to the state of a switch and also set the state of that switch, or cause something else to change that switch. It effectively triggers itself.

#5

Thank you!! That was the word I was looking for! :+1:
(like bringing a microphone too close to the speaker)