Using location mode in new Automations

[robfg (Rob Greenwood)]

Hi All - I’ve been a ST user for many years and have some quite complex routines etc. setup, why am I telling you this? I’m a little embarrassed to be asking this basic question but it’s driving me nuts.

I’ve made the migration from classic to new (this was not easy, I have a pretty grumpy wife right now!). I’ve managed to get most things working again with one really basic exception.

I have a couple of automations that simply send a notification if something odd is happening when the system is “Home”, “Away” or “Night”. For example I wouldn’t expect doors to be opening or closing if we’re away - but the cat might trigger a motion sensor.

I’ve setup the automations for mode “Away” as a pre condition, then ANY door contact opens or closes. My issue is that this fires even when in “Home” mode??

The only way I can get this to work is to set the automation to “Away” as a pre condition and ALL contacts open or close, this just doesn’t make sense to me? To test I can then add “Home” into the automation pre condition and it will trigger for home too.

Am I missing something really basic re using the home status as a pre condition?

Where I’m using it in more complex lighting routines it seems to work how I would expect e.g. unless I’m in this mode, don’t do anything else?

[orangebucket (Graham)]

@robfg

Am I missing something really basic re using the home status as a pre condition?

The consensus of expressed opinion so far is that if you are, we all are.

The precondition hasn’t been documented, it just appeared one day. ST are funny like that. They do something potential unpopular and broadcast it from the rooftops, but long requested features just creep in unheralded. So we never get a convenient place to say nice things, ask questions, and report bugs. Yet when it comes to giving them a good shoeing, they make it easy for us.

But I digress. I think we all assume that the precondition is supposed to be like the ‘only when’ / ‘restrictions’ / ‘limitations’ / whatever we see on many rules based systems. That is to say something that has to be true for the automation to proceed, but not something that itself triggers it.

Essentially it has been assumed to be the missing link that is intended to let you do ‘if A or B or C arrive home, but only if the mode was Away at the time’ without worrying about a race condition when Away is set. This is key to being able to accurately replicate the behaviour of Routines.

You have also illustrated another case where it should enhance functionality. It essentially permits the “(if location mode is Home AND (A or B or C happens)” conditions that are missing. In this example it possibly wouldn’t matter if it triggered when the mode changed, but that is moot as you can’t do it.

It has been observed in more than one thread now (and someone more diligent than me may come along and link to them) that the precondition just doesn’t do anything when used with the ANY condition group. If it isn’t a bug no one can work out why not because it really ought to be. The one specific use case where it is absolutely critical, turns out to be the one where it doesn’t work and makes things worse.

It also displays in a confusing fashion when there is only one other condition, but that’s an extra issue.

Extra: Without even realising I’d done it, I found myself on one of the threads. This is the first report I saw of it. It took a while to realise what was happening because I don’t think any of us thought it was credible it didn’t work.

Just converted one location why is this is this automation firing multiple times

See pics I did confirm the system is in home mode and as I understand the automation it should not continue to fire? [Screenshot_2020-08-03-11-29-27] [Screenshot_2020-08-03-11-24-33] [Screenshot_2020-08-03-11-24-28] [Screenshot_2020-08-03-11-23-49] [Screenshot_2020-08-03-11-23-53]

It is something that is worth reporting to support if you have support that responds quickly as it raises awareness. It is the sort of thing we have to suck up in the UK as our current response time is in excess of a month. So it is a bit ‘Dear Fire Brigade, FIRE, FIRE …’.

[robfg (Rob Greenwood)]

Well the home status seems to be VERY flakey, my automations have become really hit and miss when I have that as part of a condition.

I’m a little surprised something so fundamental to a smart platform isn’t creating much more noise?

[swamplynx (Chris)]

Agree. I’ve checked my mobile presence logs, and presence is spot on, so my issue is definitely with these flaky automations.

I have one automation whose intent is to unlock the front door when someone arrives, but someone else is already home, without running the full blown welcome home automation from an away state. So I have a precondition for one of the someone already home modes, and an anyone at home presence condition. Here is what it looks like:

Best I can tell, it fires when someone leaves, not when someone arrives. So bizarre.

Also confusing is that the automations speak in terms of present / not present, as opposed to arrival departure, so it is not clear if a state or a state change is the trigger. That issue extends to other conditions as well.

Am I missing something or are these automations hosed?

Don’t get me started on automations where there is a mode precondition, but multiple other OR triggers, in which case the precondition is totally ignored. See the below, which should be mode restricted, but is not.

Before forcing us off routines, these needed to be much more robust, capable, and reliable. Only thing worse then going through the migration pain and rebuilding my routines manually, is having them not even work properly. Tier 1 support is useless, and I’m not going to waste another hour with them telling me I’m the idiot to try to get a bug report logged. Ugh.

[robfg (Rob Greenwood)]

Hi Chris - I honestly thought I was missing something here, clearly not!

One observation I’ve had (apologies if this is teaching you to suck eggs) is that I’ve always used virtual switches to mimic state so that I can test automations easily, they also help when we get a failure.

So the automations that are the most reliable right now are…

(Automation #1) If mode changes to night turn on switch “night time”
(Automation #2) when “night time” switches on…

It’s a hack and overhead but it does have some benefits. The only thing is that the switch can’t act as a pre condition, so it’s not a complete solution.

Out of interest I’ve never tried to use support, always hacked around problems, but there doesn’t seem an answer here. Did you raise a case at all that we can start getting behind? If not how do we do this without being treated like a 5 year old first?

I’m seriously looking at alternatives now…

[orangebucket (Graham)]

@swamplynx

Best I can tell, it fires when someone leaves, not when someone arrives. So bizarre.

My expectation would be for the Automation to be triggered by any change of presence and then work out if it needs to do anything. So without the ‘After being away for 5 minutes’ I’d expect the Member Location to just return true if anyone is home.

The ‘After being away for 5 minutes’ is rather vague and I’ve only seen the wording when it is applied to one person so I don’t know how combinations work.

What does it even mean anyway? I am currently ‘present’ and last time I was ‘not present’ it was for over five minutes. But that was actually days ago. Am I at home ‘after being away for more than 5 minutes’?

Or is it trying to turn a present condition into an arrival event? Is it succeeding? How does it apply to two or more people arriving at the same time?

The Automations need to be able show what they are actually doing in a more precise logical language.

[perduewv]

@orangebucket

What does it even mean anyway? I am currently ‘present’ and last time I was ‘not present’ it was for over five minutes. But that was actually days ago. Am I at home ‘after being away for more than 5 minutes’?

Or is it trying to turn a present condition into an arrival event? Is it succeeding? How does it apply to two or more people arriving at the same time?

The Automations need to be able show what they are actually doing in a more precise logical language.

According to my arriving and leaving automations (which are working correctly)…

• blue person icon with arrow pointing to the left = arriving
• orange person icon with arrow pointing to the right = leaving

[swamplynx (Chris)]

@swamplynx

I have one automation whose intent is to unlock the front door when someone arrives, but someone else is already home, without running the full blown welcome home automation from an away state. So I have a precondition for one of the someone already home modes, and an anyone at home presence condition. Here is what it looks like:

Best I can tell, it fires when someone leaves, not when someone arrives. So bizarre.

I ended up fixing this by creating two separate automations. One for EACH separate person. It now works as intended. Best I can tell something in the logic is hosed if you have multiple people in an automation, when the state changes for one person (whether arrival or departure), it also checks to see if the others are present or not present. So in my case, where I only wanted something to run when someone arrives, but someone else was already home, it was running when one person departed, because someone else in the automation was home, even if their state hadn’t changed. Making separate rules fixed this. Silly.

[Jacob_L]

@swamplynx

ng this by creating two separate automations. One for EACH separate person. It now works as intended. Best I can tell something in the logic is hosed if you have multiple people in an automation, when the state changes for one person (whether arrival or departure), it also checks to see if the ot

I have a similar issue to this where it would disarm 5 minutes after I left. I switched this to individual ones so hopefully that fixes it.

[m1kegibson (Michael Gibson)]

I have the same issue. It is impossible to use a precondition in the way ST suggests. It states “Location mode will be checked before all other conditions”. Actually the precondition only works when the subsequent conditions are AND (ie all must be met) as when the subsequent conditions are OR (ie Any of them met) it triggers regardless of the mode.

Plainly, someone at ST has gotten some brackets in the wrong place when evaluating these conditions. Hopefully someone at ST will pick up the various threads identifying this bug and fix it.

[orangebucket (Graham)]

@m1kegibson

Actually the precondition only works when the subsequent conditions are AND (ie all must be met) as when the subsequent conditions are OR (ie Any of them met) it triggers regardless of the mode.

I thought preconditions were fixed several weeks ago, though checking back it was about three. They certainly work correctly for me with the Any/Or as I’ve spent the last five minutes testing them to make sure I hadn’t been imagining things. You may perhaps need to save the automations again.

[m1kegibson (Michael Gibson)]

Deleted and recreated the automation and still not working as expected. One of the presences is my mobile phone so perhaps that makes a difference? I know mobile presence is flakey but I cannot see how this might result in triggering of an automation when the house mode is definitely in the Home state. I’ll keep playing!

[swamplynx (Chris)]

Preconditions are fixed for me when presence isn’t involved, but automations don’t respond to presence events consistently if there is a precondition. (I’ve confirmed via the IDE that my presence works fine, the automations just don’t fire) Who the f knows what is going on. I’ve had a ticket open with support for weeks, but they are useless.

[m1kegibson (Michael Gibson)]

Similar problem as I am having. The preconditions seem to work when presence is not part of the test. In essence all I am trying to do is replicate the original I’m Back routine and have it fire only once rather than on each arrival. One would have thought this would be one of the use cases tested as I assume the whole purpose of the precondition is to replicate the “advanced” option within the original Set up of a Routine.

[swamplynx (Chris)]

My ticket number open with support is 1032504 if you want to pile on.

[dnikles (Dustin)]

Any updates on this one? I was told weeks ago that mode preconditions were fixed, but they definitely are not for us. We have a precondition when mode is “babysitter” that it will not arm the alarm when we leave, but it arms every time.

[dnikles (Dustin)]

I contacted support. Completely useless.

[JSchlackman]

I migrated yesterday and while working through the pile of badly-migrated crap I had to fix manually this is the one automation I’ve not been able to get working the way it is supposed to:

Right now this automation fires any time someone arrives (that bit is correct), but it’s doing so even when the location mode is ‘Home’. Seems like it is just plain ignoring the location mode precondition. It’s been tricky to diagnose since neither mobile presence nor mode is actually shown in the new app (come on devs, that is simply ridiculous) but I have verified using the IDE that the mode was Home the last time it fired this afternoon.

[CodeMunky (Chris McKinley)]

I have the most basic home/away requirement which has been impossible to get working consistently in the new app. Two iPhones as presence sensors, both leave the house at the same time. I typically get an “arrived home” notifcation 5 minutes after we have both left the home (which should be impossible with a pre-condition of away for the arrived home rule, but anyway…) then I get the “you have left notification” after 10 minutes of being away. OK we’re getting somewhere now… Then we arrive home at the same time, open the front door, and the alarm goes off because the STHM is in away mode still. I never get an “arrived home” notifcation. After a while, the app seems to realise both iPhones are home and sets the mode to Home, but the STHM stays in armed away mode!!! How do I set the STHM to disarm when I get home? Is it not automatic? This all used to work flawlessly in the classic app.

I’ve had SmartThings for 5 years now and have invested heavily in WebCore. This new app is totally hosed. I am a matter of days away from throwing in the towel with SmartThings. I feel betrayed and let down! They’ve broken my Smart Home.

If anyone has an example automation for “Goodbye” “Welcome back” routines which use two smartphones as presence sensors, please could they post them here so I can try them?

I have read on other threads, that this may just be fundemanetally broken if you try and use two smartphones, and instead it’s better to have a rule per smart phone and somehow use virtual switches to link them into a single gooby routine.

So hacked off with SmartThings right now.

[JSchlackman]

OK, here’s how I got mine working the way I want them. I am 100% convinced now that creating a rule using a location mode precondition along with ‘when any condition below is met’ for presence is simply bugged, so to work around it I’ve split the rules up a bunch. This initially seemed counter to the elegance that the more complex rules should be able to provide, but the upshot is they are easier to debug and most importantly they actually work.

The first thing I did was remove Location mode changes from the arrival/departure automations and coupled them directly to security mode via three short automations as shown below. I found this was also important since I want the location mode to change even if I arm/disarm manually using the home screen STHM controls (which I was doing a bunch when the rules were screwing up and my alarm kept getting set off). Now none of my other automations change the location mode: they only change the security mode and location follows it automatically. This approach may not work for everyone’s setup, especially if you have additional location modes, but it works for me.

Now the Everyone Leaves automation is fairly straightforward and is working for me as follows (actual phone names redacted):

The key to getting arrival working (any single person arriving will disarm the alarm), was to split each person/presence sensor into their own rule per the example below so that each automation only contains a condition based on a single presence sensor/phone.

(+2 more like this with my wife’s phone and our guest sensor).

While this does turn what were originally two automations into a total of 7 for me (with three presence sensors) it does work consistently and as expected now. Splitting the arrival automations up also has the added advantage that the push notifications actually name whose arrival turned off the alarm, instead of just saying ‘Someone arrived’.