Updates to the SmartThings Platform

Actually, you can do that particular one. Location mode is allowed to be a pre-condition to any others. You can also change the conditions from All (and) to Any (or). So you end up with:

If Location mode=somestate
then if
sensor1=not present
sensor2=not present
sensor3=not present

do something

One routine I have is “If either sensor is present, unlock the front door, change location mode, disarm security, send a notification of disarming”

Also, you have greater flexibility in some of the SmartApps like LUM where you can prevent certain things from happening based on location mode, presence sensor state, etc. In fact, LUM treats the Life360 presence sensor as part of “People” just like a mobile phone presence.

If you click on your Life360 Sensor under devices, but get an error and cannot access it, you may have to uninstall ST NewApp and reinstall it. I found this resolution in an old post. It was the only thing that got Life360 presence sensors working for me again. The “Member Location” utilizing the “Get your location from this phone” seemed to be just as unreliable for geolocation in the ST NewApp as ST Classic, (which I why I switched to Life360 in the first place).

Note: Once you sign in to the ST NewApp again, you won’t lose your settings, devices, automations, SmartApps, etc… however your main screen (rooms, etc.) will need to be re-ordered, as well as the devices in each of your rooms re-ordered. (The devices stay grouped in your rooms, but the order is reset.) Not the worst of problems, but just a heads-up.

1 Like

Thanks. I didn’t realize there was a pre-condition option for location mode, that helps a little. Still removes the ability to have an x-minute buffer after leaving to run the automation, but it’s a start.

Now if anybody has any ideas as to why it thinks my Weather Station is somehow a motion sensor, I’ll all ears, ha ha

1 Like

Thanks. The issue isn’t that I can’t access the sensors - I can. It’s that the new app doesn’t treat them like it does the built in location, which is dumb on many levels.

How do you see the built in presence devices other than using the Classic app? Are they suppressed in NewApp? All’s I see is in History, device “Glen’s Galaxy S9” occupancy:inside (which is well after the geofence is entered and presence:present fires)

You don’t. they’re suppressed.

What I did, is create an analogous Simulated Presence Sensor for both me and my wife, then used WebCoRE to set those based on the status of the built-in presence sensors. Bonus side effect, I can apply intervening filter logic such as - never set sensor X ‘away’ if a certain calendar item is present in [this Google Calendar] (I’m using GCal Search [UPDATED 3/27/18] GCal Search for that functionality BTW)

1 Like

Only problem is preconditions are currently broken and aren’t respected.

1 Like

See that there, to me, is the first nail in the coffin, and loudly demonstrates that Samsung ST is actively working against their community, suppressing information that we power users need for the sake of simplifying their mass-market experience. That, and I’m sure they’ve received their share of presence not working support calls, which is no way to deal with a problem by hiding it.

Disappointing at least. Enlightening at best. I now know clearly what I need to do.

1 Like

That’s certainly not the only problem, but it is one. Another one I just found (possibly related). I can’t have a precondition on location mode, and also have the automation run a scene which affects location mode.

Looks like I’m off to WebCore once again. It’ll be faster than fighting with this thing

1 Like

I read it differently - I don’t think it’s so much ‘suppressed’ as I suspect they have to go out of their way to ensure backwards compatibility with the old Groovy IDE. If you’ve ever tried to get funding for a backwards compat project for a platform that has an EOL date already - you’ll know that’s PAINFUL… In this case, they DID make it where the newapp presence sensor at least DOES show up as a device that can be subscribed to and in fact I USE it in my WebCoRE Automations. Working against would have been - “screm em - they don’t need it.”

My scotch is half full.


Also, you can delay actions on devices, but not on location mode changes, security mode changes, running scenes, or notifications. Why the inconsistency? Who knows?

1 Like

Yeah, the automations are all sorts of messed up, and with no public change log or open issues we can’t even set expectations appropriately. As a replacement for routines, they are not production ready.

1 Like

This describes how to create a simulated presence sensor that minics your real one, so that it shows up in the new app (and has history).

1 Like

I’m a product manager (in real life). I understand the trade-offs, believe me – but it does boil down to priorities, which in the Presence case and indeed in this whole thread, demonstrates they are not at all acting in the interests of this community. Especially the whole bellyaching over Echo Speaks is really childish – if they had an issue supporting @tonesto7 's architecture, they should have worked it out with him in advance, or provided a replacement within the ST product. It was an excuse. Respectfully disagree.

I have had so much trouble with presence over the years – really its the second thing in this platform that gave me the most angst. (The first is the unreliability of scheduling and the crap-shoot if it will run your scheduled function from day-to-day.) And the whole NewApp “Get your location from this phone” should not be creating alternate presence devices, which makes it necessary to edit all your routines to reference the new device after retiring Classic. Another de-prioritized disservice to this community.


I thought this upgrade was supposed to increase stability?

And chocolate rations are increasing!


Since the NEW alexa skill is not currently working (routines, and not being able to select what devices to add), has any thought be given to delaying the retirement of the classic Alexa skill currently set for Sept 8th. That is only a few weeks away.


I am in agreement. I don’t think there is a deliberate plan to alienate developers it’s just an unfortunate consequence of the direction ST took to move the platform on and to save money. ST was clearly not delivering what Samsung wanted and this may have been the price we paid to have ST still around. Note other HA systems were just plain killed when their usefulness to their corporate owners came to an end. Things could be worse.

Presence is one of the top items when automating a home, so this really could and should have been done better. Especially hiding the presence. That used to be one of the items on my home screen. Now it have to use additional simulates presence sensors and webcore pistons to do the same thing. Painful.

BTW, I have also worked in product management. When customers are unhappy with how something works the issue falls into one of two camps. A bug or a feature enhancement. A bug is only when something is not working as the developer intended. What was intended may have been stupid, but there it is. Any change is a feature enhancement and that usually takes more time and justification to even get in the queue.


Apologies if I missed this earlier in the discussion, but regarding the upcoming update in September:

Hubs with older firmware (pre-0.32.x) will begin using hub connectivity status to determine online/offline status for hub-connected devices (e.g., Zigbee devices, Z-Wave devices and locally executing LAN devices). Note that Cloud-connected devices (typically WiFi-based products) will continue to operate and display online/offline status as usual.

Does this mean my V2 hub is not going to get the 0.32 firmware, and thus will have degraded functionality, or does it simply mean that I will have degraded functionality only if I do not update to the latest firmware? (I wish Samsung was more clear about this).

We expect v. 2 and better to get the firmware to enable this. (v. 2/v.3 are already at 31.x so this will probably come in ths next firmware)

If you have a V1, the Nvidia solution or the ADT integrated hub however, you’re probably out of luck.

Although it does bring up a good point. Hubs have shelf lives. Now with the new hub migration tool announced yesterday, if you are on a v. 2 its worth looking at an upgrade sometime within a year. Im currently on a v. 2 and you can guarantee if they release a v.4 I’ll switch.

Edit: @jamclam Smartthings does not give choice of firmware version, you MUST take updates. Period.


The only thing with the ADT hub is they still sell it on their website and through other vendors!! So you would expect it to still be supported.