System is in “Mode A”
If I have a contact sensor kick off a Smart Lighting automation that is restricted to only trigger in Mode A, and that same contact sensor is also a trigger for a routine that changes the mode to Mode B… which one wins? Is it a race condition? or is there a guaranteed order of operation (i.e., SmartApps first, then Routines)?
don’t do that. Problem solved.
I don’t think you can guarantee execution order without flag devices or modes. A simulated switch can be used as a flag.
Bummer… I guess I’ll have to come up with a better scheme… Let me tell you what I’m trying to do:
I have three Modes: Away, Arriving, and Home.
When the house is Away, and my iPhone comes into the geofence, I switch to Arriving. Arriving turns on some lights in the house (if after sunset) and disarms SHM. This is done via a mode-switch-triggered Smart Lighting automation and routine respectively. This is ok because the mode switch event is picked up by both smart lighting and the routine.
Now the house is in “Arriving” mode - I then want to take an action based on which door I open. Say, I open the kitchen door, I want that event to both turn on the kitchen light AND switch the mode to Home. And since I don’t want the kitchen light to come on every time I open the kitchen door, I want to tell the lighting automation to only fire if the house is Arriving mode. You can see, I’m trying to use the Arriving mode as a way to indicate that it had been Away and someone recently arrived… so the very next “door open” should do something, but only because someone recently arrived.
Sometimes the easiest way would be to have the automation trigger the routine or the routine trigger the automation rather than trying to trigger them both off of the same mode change. That way you force a serial sequence so you know exactly what happened first.
Use a virtual switch as a go between if you need to.
Better to have a few extra routines and know exactly what’s going to happen when than to try to trigger too many things off of the same event and guess the order they’ll process in.
Thanks @JDRoberts, I will give that a go. I have to say a post you made some time ago was the inspiration for me to have that “Arriving” transitional mode. I used to have an app that would do all of this by subscribing to the mode change events, if statements to check if arrival was recent, if was after sunset, etc… but now with the local processing of Smart Lighting, I want to try to use that built-in as much as possible. And this transitional mode idea solves that.
I have similar modes:
Then routines that trigger:
Day Time Home, only when in H:Morning
Night Time Away, only when in A:Evening
Evening Departure, when everyone leaves, only when in H:Evening
You get the drift. SmartThings makes it VERY annoying to deal with multiple timeframes within a day. Also the fact that you can’t set a Routing to work in ONLY selected modes (you can do the inverse, which requires a lot of checkboxes,)
I’ve written custom apps in the past to help with this, but I try to stay native as much as possible, and this works.
I have found that it’s cleaner to not have “away” modes at all. Instead, add a presence check to the code triggering the lights on and off (when using Motion or Contact open). Also set up a Routine that turns off all lights when no Presence detected.
I have done that in my Flexi lighting apps.