It would be good to see the actual Presence and Occupancy history for the sensor.
I don’t know about the new integration, but when the Groovy DTH parses an ‘occupied’ it will always set the presence to ‘present’ first if it isn’t already set (vice versa for ‘not present’). It would be good to be able to eliminate that as a mechanism.
I created simulated presence sensors for both of my devices and used a webcore piston to sync and track it.
I found ovwr a two week time my phone magically ‘jumped’ out of the geofence about a half dozen times then immediately jumped back. I attribute that to the phone itself, not SmartThings as its presence sensors are just reacting to the phone GPS.
What it did tell me is I needed to absolutely set at least a 1 minute delay on all of my presence automation. I ran my automations notify only for a bit but just adding the one minute delay seems to prevent the jumps from causing false triggers
I just had another weird, but what now seems like normal (abnormal) behavior for SmartThings, where I’m here sitting working from home and all of a sudden my automation to initiate my Goodbye scene runs and I get my notification that an Automation ran.
All my lights turn off, STHM arms, IFTTT stuff runs to arm my Blink systems, and then my EnvisaLink integration arms my Honeywell system. WTF?
This automation trips when ALL mobile presence sensors are gone, but holy cow I’m here and so is my phone. I can see it’s here in the IDE and the sync’d virtual presence device says I’m here.
So what happened? My wife left and her phone tripped the Automation. I think so at least, BUT it’s IMPOSSIBLE for me to know because there’s no longer any logging to tell me what tripped what and what device is associated with what Automation.
@blake.arnold, I’m not sure what ST was thinking when you guys decided to change how mobile presence devices work on the platform that now cause phones to show up as “placeholders” while retaining the old mobile presence device to totally hose up “stuff” people had working great prior to this “upgrade”. You guys broke another thing on the platform that was working fine prior to an "upgrade, again.
@blake.arnold, where was the communication to your customers about this new broken feature about how mobile phones get “converted” after upgrading to the new app? It’s not in any release notes that I can find. Fail.
@blake.arnold, because of another bug with your “new” mobile presence device, I’ve had to disable Automations for my wife’s phone, and remove it from others, because it freaks out shortly after she enters our large geofence area:
You guys seems to be going a thousand mile an hour driving with your rear view mirror looking back at what you’re trying to get away from without realizing you’re putting up more and more speed bumps in front of you.
I use Life360 for tracking and as you discovered and I can confirm in the new application code 1.7.51.42 broke the presence of this service in the NEW smartthings. the sensors are there but the location of whether the user is present or not is no longer functioning. IDE shows it correctly. when i downgrade back to 1.7.50.21 the presence detection is restored and i can see in the new application that all my users are now listed as present or not present as they should.
Personally I’ve always relied on WebCore for handling the rules pertaining to presence. My rules for presence are more complicated than the built-in Automations (or routines before that) have ever been able to handle. Even with all the new changes to presence, my WebCore piston for presence has been working flawlessly. And WebCore also gives pretty detailed logging about what it’s doing, as well.
I know that’s not the answer you’re probably looking for, but it may give you some ideas of how you can work around SmartThings’ weaknesses.
I have been having a very similar issue where my leave home automation changes STHM Arm and location mode to Away.
But my Arrive home does not disarm STHM and change the Location mode Home where it should do this and did up until a few days ago
Since I am new to ST, I don’t have the same migration issues as many others. However, presence has been spotty. Right now, I have a WebCoRE presence sensor and the presence sensor generated via ST (I changed Type = Mobile Presence). I have only been testing this configuration for about a day, but the ST has been much more responsive, even when used in a WebCoRE piston.
Arriving home from work last night:
ST = 5:44:43
WC = 5:58:52 … 14 minutes later
Leaving home this morning:
ST = 7:15:14
WC = 7:17:32 … 2 minutes later
If I have learned anything from the last few weeks with ST, it is to wait a few days. Things that don’t work might be fixed in few days. Things that do work might also be “fixed”.
I’ve always had bullet proof experiences with all our mobile device from the very beginning of SmartThings up until now, and because of that we’re sensitive to crap breaking. I’m going to keep pushing their buttons on this issue.
Yeeeeaaaaaaaa!!!
Yeah, I’m getting sick and tired of their “progress” trying to abandon their legacy platform and app, but the amount of problems and issues being introduced is wearing thin. They’ve only been at it for a couple years, so let’s just cram all the backed up work and issues into a couple months of customer he11 and leave developers with half-baked tooling and documentation to help bail them out of this when custom crap stops working. If only Hubitat would have a UI my family would tolerate…
So i have been having a mobile presence issue. This occurs in The New App (placeholder) AND Classic app (mobile presence)
When i Arrive Back Home within the same minute it has me Away/Bye Bye
5-10 minutes later it has me Arrive Back Home and stays in that status.
This error has been pretty consistent. Arrive Back Home/ flips to Away/Bye Bye
So this time I put in the automation Arrive/Back Home and check marked 
Stays In this Status for How Long?
1 minute
My last attempt after many Other attempts.
So far this is working…
You’re not alone in this
It will probably work just for notifications. What if you actually run something like disable alarm, unlock doors, etc? Timer will be reset every time presence status changes.
At first I had it set for 25 min
When i got home…Arrival/back home
It stayed in that status
When it reached 25 min mark. The automations kicked in
Since my issue is
Back Home/Arrival within the same minute it flips to Away/Bye Bye
I set it to 1 min
Increased geo-fence just a tad.
So far it works…
Will keep you updated.
For my Arrive home automation I was using Location Mode ‘Away’ as a pre-conditon…
I have now removed the pre-conditon flag, so checking the presence and location mode as an ‘and’.
This seems to have fixed it for me.
I also had issues with phone presence sensor when upgrading from classic app, and now with new version of ST also created issue with presence sensor phone, i deleted all phone presence sensor entries in all my locations and reinstalled the new app, the new app created new placeholder presence sensor and it’s been ok 7 out 10 times. I am having an issue with a scenario that came up last week, i left home and a repairman was working there, my phone presence armed the system, automations ran ok, but i needed to turn off SHM since there was a person there, everytime i turn off SHM it would turn on right away. I tried for 10 minutes still it would arm right away, the only solution was i had turn turn off the automation for that day
I created a Virtual Switch called ‘Security Switch’
Then my automation I added the switch to the if section of the automation so:
If Security Switch is On and everyone is not home then arm STHM
So if I know I need STHM to stay as Disarmed I would just switch the ‘Security Switch’ to Off either via SmartThings or Google Assistant.
This will ensure the alarm is not activated until you switch the ‘Security Switch’ to On
