I stopped trusting the app after the first time it didn’t change 
I did however try @bravenel suggestion of deleting the Goodbye! routine and recreating it. It helped with manually changing mode. So i will have wait till tomorrow when everyone leaves
Just an update for me. I have seen this before but didn’t think much of it. Then, I started logging the mode the app thought it was in before executing. Ive witnessed multiple occasions where the hub is in multiple modes. I.e., the app would take the correct action in the correct mode, but a second instance of the app would trigger in an incorrect mode. I reported this to ST
As far as I can tell, the root issue seems to be copies of apps that shouldn’t exist – and on top of that they are stuck in the wrong mode. I suspect it’s a previous mode.
I wonder if there is a way to just kill all apps that are running? In v1 disconnecting the hub for 10 min would do this. I dont think this is true with v2
What helps me is not even deleting it but just go to the routine, pretend to reconfigure and just click “Done”! It works for me nearly every time.
My experience and testing with this has been a little different.
Your typical one page smartApp has the the mode selection options added by the back end, and therefore they do not need to be included in the actual smartApp code, presumably the app should not even fire if one of the selected modes is not the current mode. But I have seen it happen numerous times now, I’ve checked the current mode in the IDE, and it’s in a mode where the app shouldn’t be running, and yet it did.
So as an experiment I took a one page smartApp app that I was having incorrect mode execution issues with and added in a preferences section for mode selections, then added a modeCheck procedure within the smartApp, allowing the actual event code to only run if the current mode was in the selected list.
Of course this gave me two mode selections in the smart app, the one I created, and the one created by the back end.
I unchecked all the mode options on the back end mode selections (this would allow the app to fire in all modes), then checked the mode options in the app’s preferences.
Since I’ve done this, this smartApp hasn’t fired in the incorrect mode, and it’s been working correctly for almost a week now.
Prior to this change it was happening almost every other day.
So there you have for what it’s worth.
I redid ALL of my lighting automations based on motion, and like this, they started working reliably. There are bugs all over their built-in stuff. They tried to be too cute, but fell down somewhere in the execution.
I noticed some improvemens already in their automation on motion, but the ‘dark on motion’ seems to persist with the Smart Light app. I hope this will be soon adressed too. My wife keeps doing the chicken dance in the kitchen, when our cabinet lights go off, even though she’s been moving around, except for when she’s stiring the pot.
Routines are still not working. Even if you manualy switch to goodbye and your prescence device shows “away” the lights specified to turn off do not turn off, doors dont lock,etc. Same for if your presence shows “home” and your stuck in away mode and you manually click the routine Im Back! - the mode still does not change.
Support finally acknowledged this and sent me the following:
"Hey Anthony,
I see now. I’m sorry for the confusion on my end. There is currently a bug right now that isn’t allowing routines to change modes for some users. Our teams are working on a fix and it will be deployed as soon as it becomes available. I truly apologize for the confusion on my end as well as the inconvenience. In the meantime, please let us know if you run into any other snags."
Ok so i’ve been digging into all of the available data exposed through the API. So I was logging this just to see how much info I could pull out. And since i have had some major issues with modes since the V2 hub this really stuck out.
If I look at the JSON data at https://graph.api.smartthings.com/api/locations it shows the same mode as my mobile devices and the IDE.
"mode": {
"id": "data_omitted",
"name": "Morning",
"locationId": "date_omitted"
}
If I add the following code into my smartapp:
def modeId
for (item in location.modes) {
if(item.name == location.mode) {
modeId = item.id
}
}
log.debug "location current mode: ${location.mode}"
log.debug "location current mode Id: ${modeId}"
Which will return the following log entries:
3:31:28 PM: debug location current mode Id: modeId_omitted
3:31:28 PM: debug location current mode: Away
Something is seriously out of whack and I cannot believe it has not been resolved yet. It’s a very annoying bug!
Same problems here as the rest of the bunch.
Yesterday I am back failed to trigger and disarm SHM when my wife and I returned back in the evening even though the mobile presence was detected well in advance. I have a ticket open. If you have not, please do… Clicking I am back manually resolved it temporarily.
Same issue. I have been updating my open support request everytime i have an issue 
Hello!
I’ve got a ‘Welcome Home’ routine that is supposed to activate when EITHER my wife or I come home. It works great when both of us are not there and one of us comes home. It does NOT work, however, if one of us is already home and the other one then comes back.
I’ve checked my settings and it is set to go off regardless of ‘mode’. Any ideas?
Your best bet is to try and watch the event logs at https://ide.smartthings.com when you know the routines are going to fire. See if you notice any errors.
Keep reporting it to SmartThings support and cross your fingers that someday they will find this mythical bug that is crippling this system 
Thanks! I ended up making separate routines for my wife and me. It worked the one time i came home yesterday.
That’s how I have mine setup, but it doesn’t always work. Unfortunately there is no sure fire work around fix yet. We just have to deal with it till smartthings tracks down the underlying issue and fixes it
OMG OMG OMG…
My house actually shows the away mode today it’s been forever since I have seen it change 
Did the routine causing the problem include a mode change? If so, it might be a different issue altogether:
Well i’m not sure if the issue has been actually fixed or if it’s a coincidence. Every single routine that was supposed to change modes worked as expected both yesterday and today. Either way thanks ST
Not me, my wifes phone presence still shows PRESENT when away. This is both with smartthings presence and with life360 though the life 360 app shows her not at home
This happens to my wife occasionally because she never opens the app and for some reason even though background activity is allowed for the app it will just stop sending presence data. Plus she also forgets to leave her wifi on which really skews the geofencing.