Prevent same piston from running again


1) Give a description of the problem
The piston runs multiple times.

2) What is the expected behaviour?
This piston is meant to arm my Ring Alarm (‘Unknown Device 2’ in the screenshot), Change the Location Mode, Set a lighting scene, Change an Ecobee Comfort Setting, and a few other Mode-dependent actions (e.g. wake up and unlock my car, change a light to red when the alarm is armed, etc.).

3) What is happening/not happening?
The piston runs successfully. but since the Location Mode changes the Ring Alarm state and vice versa, it ends up running twice. I think this is happening because the respective routine also change the Mode. The mode change is desirable if the piston was triggered by Ring Alarm, but I’d like the piston to not run a second time. I thought an Exit statement would help, but I think it’s exiting the piston and then just running the piston again.

4) Post a Green Snapshot of the pistonimage

5) Attach logs after turning logging level to Full
I’d rather not since this involves my Ring Alarm



When you are subscribed to a device (IE: location mode on line 19), then whenever it changes (in any direction), the entire piston will run top to bottom, and execute any code not blocked by conditions.

For example, do not code like this:

If LocationMode changes
    Then execute RoutineA

If RoutineA executes
    Then change LocationMode 

Even if that logic is spread out between two pistons/automations, it still causes needless chatter, and at the very least, double triggers(but often much worse issues)


@WCmore Thank you. Is there a best practice example that would allow me to keep both in sync without creating a double trigger situation?


Normally, I make one the “Leader”, and one the “Follower”… Trying to tell both devices to follow each other can create real chaos…

Imagine if you tell your kids:

  • Susie, follow Adam
  • Adam, follow Susie…

You will be in for an entertaining afternoon! LOL

If you insist on attempting this, I would use a THIRD device (perhaps a Simulated Switch) to be the real “Leader”, and let that device tell the others what to do…

Alternatively, you can use a third device to be the dedicated “Follower”… so both of the real devices can control the SimSwitch, but the SimSwitch controls neither. This works great for display purposes.


Thanks. I hear you, but this approach allows me to use the SmartThings app (to set via Location Mode changes) or Ring app while my wife can stick to just using the Ring app to arm the alarm (all she really cares about) while the other stuff also happens…which she’s indifferent to…until I show there’s value to having two ‘Away’ states, etc. ;-).

I like the third virtual device as leader option and will explore that.



To get you started, here is a bare-bones structure:

Piston #1

If LocationMode changes to Home
    Then turn on SimSwitchHome

Piston #2

If RoutineHome executes
    Then turn on SimSwitchHome

Piston #3

If SimSwitchHome changes to on
    Set Location mode to Home
    Execute RoutineHome 

This method prevents the Location mode from double triggers… but the Routine will double fire if it is the one that started the logic… (although you could always add more conditions (time check etc) to keep that one to a minimum)

Also note that each Location mode (home, away, sleep etc) must be in a separate piston (with separate SimSwitches), or you are back to double triggers again…

Yes, it is a lot of work to do what you want… I admire your tenacity, but I would probably make only one device the “Leader”.

Side Note:

You will also have to program the SimSwitches off at the appropriate times as well…
(I would definitely sketch this one on paper as a flow chart before coding anything)


What I meant was something like this:

Piston #1

If SimSwitchHome changes to on
    Set Location mode to Home
    Execute RoutineHome

If SimSwitchHome changes to off
    Set Location mode to Away
    Execute RoutineAway

One piston… Two triggers… All control comes from that SimSwitch, which can be controlled in any numerous ways…

It syncs the devices whenever the SimSwitch changes… but again, if you leave your current logic in place, that old code will still double trigger. The idea above only works if it is the only programming in place.

Side Note:

Why don’t you skip all this craziness, and simply tell your Routine to change the location… and tell your location piston to execute your routine? It will make your programming much more straight forward… (although I usually recommend not using Routines if webCoRE can handle the commands directly)