What exactly does the "Precondition" check on Location mode do in Automations?

In the latest iOS version of the new App I noticed there’s now a Precondition slider as an advanced option for Location mode when used in an if condition. I can’t find any documentation on this anywhere (yet) … wondering if anyone on the forums knows what exactly it’s supposed to do.

I see that when Precondition is enabled and used in combination with multiple devices (e.g. motion sensors) the Location mode is not included in the ANY/ALL list of conditions, which leads me to believe it’s Location mode AND (device condition OR device condition OR device condition). Beyond that, it’s not clear if it makes a difference in any other evaluation criteria.

1 Like

Nice spot. It is in the Android app too. That format is used for time periods, so I’d interpret it as the long requested restriction - that is to say a change to a pre-condition doesn’t trigger a run of the automation itself. If so, this is big news.

It doesn’t have a visible effect for a single condition. Does that mean it isn’t applied or is it a display issue?

Sadly I can’t seem to add Location retrospectively to my arrival automation, and that is the main one I’d want it for.

UPDATES: A simple test suggests my interpretation is correct. Also the pre-condition does work with a single condition but it isn’t made visually obvious. It also does work with the OR group I used in my automation when implemented from scratch but I couldn’t add it retrospectively.

Are you saying that the Precondition on location mode means only run if you’re already in that mode, and not if the mode is changed into the mode you’re evaluating?

1 Like

Tagging @jody.albritton

Yes, that is what I am saying and indeed I just tested it and that is what it does.

There has been much demand from the community for this capability (as there also has for grouping with AND and OR) , particularly for the Location mode. In particular it is difficult to effectively replicate the four default Routines from the Classic app without it.

For example, it has been possible to replicate “all users have departed” or “someone has arrived” as an AND or OR grouping of multiple presence sensors, with the condition triggered by a change of status on any presence sensor. However it has not been possible to say “if all users have departed and the location mode is currently home or night” (as a condition for changing the mode to away), without it also triggering any time the mode changes to home or night. It has not been possible to concisely replicate “if someone has arrived and the location mode is currently away” (as a condition for changing the mode to home) at all.

UPDATE: Text changed to report result of testing.

In playing around with some automations this morning, it looks like precondition ON means “When Location mode is already XYZ” whereas precondition OFF means “When Location mode changes to PDQ”.

Enabling Precondition requires some additional qualifying criteria, and if that criteria is time based then it has to be a specific time (e.g. Sunset) to work with a Precondition; otherwise a time range (e.g. Sunset to Sunrise) doesn’t qualify - which makes sense when you translate it to “between time X and time Y when the Location mode is already XYZ …” because there still needs to be something else that would trigger actually doing something.

2 Likes

this sounds exciting. Off to play…

1 Like

Playing around with this a bit more and found something that doesn’t seem to work like I thought it would. I created an automation based on time of day + Location as a precondition, and motion on any of two motion sensors:

I have another automation that changes the Location mode to Home when the security mode is disarmed:

With these two in place, I would have expected that the first time the motion based automation is triggered to set the security mode to disarmed, the second automation would then kick in and change Location mode to Home. Because Location mode is now Home, the motion based automation would not continue to fire. Instead, even after Location mode is set to Home the first automation keeps firing whenever motion is detected on either sensor.

Interestingly, if I use only a single motion sensor in the automation it works as expected.

1 Like

Sounds like a bug to me

1 Like

@orangebucket, I’m not sure I fully understand why you are using the location mode at all? My routine for setting the alarm whan all users (i.e mobile phones) have left is like this:


and my routine for when someone comes home is:

Neither of them rely on the location setting and it seems to work correctly?..

The VDisable-Alarm is used to completely disable the alarm (for occasions like when we’ve got a friend/relative staying and the rest of us are out, or if the kids are in the garden until the early hours when the auto-alarm automation would normally have kicked in for setting the ALARM(Stay).)

@SQLDBA I’ve got a slightly different “Good Morning!” automation that combines both of yours as below…


Between the time specified, It only fires if the internal sensor on the landing detects movement AND the STHM is in “Armed(Stay)” mode.
If the sensor detected movement during this time and the alarm was “Armed(Away)” the alarm would go off.
If the sensor detected movement during this time and the alarm was “Disarmed” nothing would happen.

It seems to work correctly… (had a few hiccups during initial migration from the Classic App which caused the alarm to go off much to the annoyance of the missus!)

That is simply because you have chosen to use the Security mode in the conditions in the way I use the Location mode. That’s fine as long you have STHM enabled and can work with the three modes it gives you.

I could do it like that too but it seems like the cart pulling the horse to me. I don’t think of the automations as arming and disarming STHM, I think of them as putting the location into ‘away’ or ‘home’ mode, with the settings of STHM being but one consideration when I do.

1 Like

Fair enough… I didn’t really get the point of having the location modes and the STHM modes (and still don’t) but it looks like we’ve come up with working solutions. :slight_smile:

It makes more sense when you’ve read the ‘Alarm System’ (cf. SHM), ‘Security System’ (cf. STHM) and ‘Location Mode’ capabilities. The security modes are effectively just the attributes of an optional virtual device being given undue prominence over every other device, while the attributes of the Location ‘device’ get completely buried.

The following FAQ refers to the classic app and its STM security modes, but the principles are the same, and it has a number of examples which should help explain the difference between location.mode and security.mode.

It’s confusing, because smartthings chose to use the same names for the two different sets of values. They didn’t have to do it that way, but they did. :thinking:

Anyway, see if this helps clear up the confusion. (The topic title is a clickable link)

1 Like

I’ve found very little documentation anywhere… can you point me to where you’ve read about this?

My comments were based purely on having used the REST API to show me the available capabilities. There are about two hundred of them and these three (one considered defunct and two live) seem rather familiar.

{
    "id": "alarmSystem",
    "version": 1,
    "status": "dead",
    "name": "Alarm System",
    "attributes": {
        "alarmSystemStatus": {
            "schema": {
                "type": "object",
                "properties": {
                    "value": {
                        "title": "AlarmSystemState",
                        "type": "string",
                        "enum": [
                            "away",
                            "off",
                            "stay"
                        ]
                    }
                },
                "additionalProperties": false,
                "required": [
                    "value"
                ]
            },
            "enumCommands": [
                {
                    "command": "sendEvent(alarmSystemStatus,off)",
                    "value": "off"
                },
                {
                    "command": "sendEvent(alarmSystemStatus,stay)",
                    "value": "stay"
                },
                {
                    "command": "sendEvent(alarmSystemStatus,away)",
                    "value": "away"
                }
            ]
        }
    },
    "commands": {
        "sendEvent(alarmSystemStatus,off)": {
            "arguments": []
        },
        "sendEvent(alarmSystemStatus,stay)": {
            "arguments": []
        },
        "sendEvent(alarmSystemStatus,away)": {
            "arguments": []
        }
    }
}
{
    "id": "securitySystem",
    "version": 1,
    "status": "live",
    "name": "Security System",
    "attributes": {
        "securitySystemStatus": {
            "schema": {
                "type": "object",
                "properties": {
                    "value": {
                        "type": "string",
                        "enum": [
                            "armedAway",
                            "armedStay",
                            "disarmed"
                        ]
                    }
                },
                "additionalProperties": false,
                "required": [
                    "value"
                ]
            },
            "enumCommands": [
                {
                    "command": "armStay",
                    "value": "armedStay"
                },
                {
                    "command": "armAway",
                    "value": "armedAway"
                },
                {
                    "command": "disarm",
                    "value": "disarmed"
                }
            ]
        },
        "alarm": {
            "schema": {
                "type": "object",
                "properties": {
                    "value": {
                        "title": "String",
                        "type": "string",
                        "maxLength": 255
                    }
                },
                "additionalProperties": false,
                "required": [
                    "value"
                ]
            },
            "enumCommands": []
        }
    },
    "commands": {
        "armStay": {
            "arguments": [
                {
                    "name": "bypassAll",
                    "optional": false,
                    "schema": {
                        "type": "boolean"
                    }
                }
            ]
        },
        "armAway": {
            "arguments": [
                {
                    "name": "bypassAll",
                    "optional": false,
                    "schema": {
                        "type": "boolean"
                    }
                }
            ]
        },
        "disarm": {
            "arguments": []
        }
    }
}
{
    "id": "locationMode",
    "version": 1,
    "status": "live",
    "name": "Location Mode",
    "attributes": {
        "mode": {
            "schema": {
                "type": "object",
                "properties": {
                    "value": {
                        "title": "String",
                        "type": "string",
                        "maxLength": 255
                    }
                },
                "additionalProperties": false,
                "required": [
                    "value"
                ]
            },
            "setter": "setMode",
            "enumCommands": []
        }
    },
    "commands": {
        "setMode": {
            "arguments": [
                {
                    "name": "mode",
                    "optional": false,
                    "schema": {
                        "title": "String",
                        "type": "string",
                        "maxLength": 255
                    }
                }
            ]
        }
    }
}
1 Like

Hi, My automation doesn’t work, my expectation would be that if the location is not Away, then motion or opening of sensors would not trigger the automation. If it is set to Away, then as soon as any of the sensors are triggered it would do the actions. Is this a bug or am I doing it wrong? Cheers

2 Likes

There have been a couple of threads started about this. The common factor is that the ‘any’ condition has been selected.

I am hoping it is a bug, because if it isn’t the setting is doing something that users aren’t expecting.

1 Like

I have the same thing and it should be a bug. I have an automation away mode as precondition and ANY sensor is activated and it still triggers when it is in Home or Night mode. Then i broke it down to seperate automations using “Away AND Motion Sensor Activated”, and it worked as expected.

1 Like