Using location mode in new Automations

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?

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.

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 …’.

1 Like

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?

1 Like

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.

1 Like

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…

1 Like

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.


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

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.

1 Like

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.

1 Like

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.

1 Like

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.

1 Like

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!

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.

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.

1 Like

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

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.

I contacted support. Completely useless.