@JDRoberts Thanks. Won’t work for me - most of my devices are ZWAVE…
1 Like
I also use a fair few Zwave devices, they have been more reliable than zigbee and only lack a decent UI to control them fully, which was available in Smartthings until Samsung changed to the restricted UI which blights todays inflexible outdated buggy app
1 Like
As part of the migration,should all our automations start getting local operation check marks ?
Only two of mine have them.
Not all. There are still multiple conditions that can prevent an automation from running locally. For example, if you include a device which is cloud to cloud, that won’t get the checkmark even if other devices in the routine are running locally. Scenes do not run locally yet. Some virtual devices do not run locally.
I believe @h0ckeysk8er has a list of conditions that affect this. 
This is a list of things I have found that cause Routines to run in the cloud:
- Scenes
- Lighting Groups
- Member Location
- Devices from cloud->cloud integrations
- Notification actions
- Weather triggers
- STHM triggers and actions
- " Any Day" time precondition
- Cloud virtual devices
- Devices on two different hubs
4 Likes
THank you
Wow so anything with a notification cannot run locally.
I have switched all my virtual devices to be using the edge virtual devices
.
Is SHM running locally and all changes to that such as change mode to home
or mode to away ? Seems like SHM would be the most important thing to run
locally.
when you say STHM actions is this what you mean ?
Thanks,
I am no ST expert, relatively new to the system, but I have 99% of my routines running local, excepting those with ST notifications.
The other routines, marked as local, I send a virtual switch to Alexa to give me the notification.
So I ask, what is the difference if in both cases the routine is triggered locally, and runs, if the last action is lost in the cloud on the way to Amazon or can’t run in ST?
SHM was the home monitor in the old architecture. STHM is Smartthings Home Monitor and is the new monitoring solution. So any Routine with a trigger based on “Security Mode” or any action that changes “Security Mode” will not run locally.
There is really no difference. ST->Alexa is cloud to cloud and Notifications rely on the ST cloud. Just a reminder of the current ST architecture courtesy of @JDRoberts
2 Likes
Exactly. But the point I’m trying to make is, with so much discussion on “local” or “cloud”, is it really important whether a routine that triggers and runs locally should have the last action in the cloud? Does that make any difference to the user?
Or is there more to it…rules don’t have notifications for example.
My experience so far has been that local actions execute more quickly which makes other things better. Lights that I had mirrored with the old SmartLighting app would often take several seconds to go on/off. With Routines (or Z-Wave association groups), mirrored lights turn on/off nearly simultaneously. And if I have any Internet fade, my local automations do still run without the connection to the cloud.
But, in the end, ST is a mainly cloud based system and you have to evaluate whether that’s an issue for your needs. If so, there are other home automation solutions that have greater local autonomy.
1 Like
The Third Reality sensors are new and SmartThings possibly doesn’t have the firmware files yet. Hubitat only just got them.
However, SmartThings has the firmware files for classic Centralite devices like the Iris v2 and v3 sensors. In fact, only SmartThings has them (as Centralite went out of business before Hubitat could get the firmware).
Echo That!
2 Likes
@SmartThings I know I’m late on the ball here, but why did you think it was wise to discontinue Groovy code and break hundreds of 3rd party Smart App’s and Device Handlers in the process. If it ain’t broken, don’t fix it!
Because they were continuing to have to scale up the cloud hosting service to support device handlers and SmartApps and it was costing them a lot of money. The goal was to move to an architecture where device handlers (now Edge drivers) are running locally which decreases the dependency on the cloud. For SmartApps, the architecture provides hooks for ST to interact with 3rd party applications that will now be hosted by those 3rd parties.
There has been plenty posted in the community over the last couple of years about the motivation for the transition. At the end of the day, hub-based ST users account for a very small percentage of those who use ST today. And of those who are hub-based, a large percentage have a dozen or so basic devices and these changes are completely transparent to them.
Yes, it’s a pain for those of us who have more sophisticated home automation environments, but I think we’re in the minority of ST users and that was certainly factored into their decision.
On the bright side, at least there is a platform transition direction and they didn’t just pull the plug on supporting hub based home automation.
6 Likes
@h0ckeysk8er Fair play, but then why not give people the option to run Groovy code locally, either on the ST hub if it’s powerful enough or on a normal computer talking to the hub?
ST without a hub to provide Z-Wave and Zigbee support amazes me and seems a tad strange as I moved over from X10 to ST in 2016. If most people are hubless, what are they using to control lights, appliance sockets, fixed-wired switches, sensors, etc…
WiFi, Samsung devices, cloud connected devices. Devices are connected by various technologies and Samsung is trying to position competitively so that Google and Amazon are not the only players in the market.
1 Like
That is rather begging the question. They probably aren’t doing those things. Those that do would be proportionately more likely to be using hubs, but I suspect the hub users would be outnumbered by those who started with a Samsung appliance and added a few cheap WiFi devices.
2 Likes
There was a post long long ago from Smartthings explaining that Microsoft had bought the IDE servers, as Samsung did not want there technologies run from Microsoft services (at the time) they decided to move away from the IDE and Groovy
Subsequently Lua was decided it was the best language to move to which then led to the advent of edge drivers
Edge drivers were then touted to be easier for users rather than the (complicated) Groovy drivers and IDE
I remain highly sceptical about the whole deal, to me it seems to be the beginning of the end for 3rd party integrations and a move towards Samsung only products
1.IDE groovy gone, completely removing user created integrations
2.Samsung stop producing hubs
3.Samsung replacement drivers limited to the basics and a small subset of what was once available, community developers picking up the slack
4.Zwave not available on the new charger/striped down hub
- Smart apps are available but only Samsung smart apps, there are a few user created smart apps but they are not for the general public and easily implemented
6.The app has morphed into a restrictive design giving developers and users little or no options on device control, what can be achived now is NOT as extensive and user friendly as it used to be
The upshot from my limited view perhaps is that Samsung is funneling home automation into something that is Samsung only devices
Without our current community developers, Smartthings the app would no longer be of any use to 90% of hub users…
You could argue that there are now more devices available to control than before, true but only because of 3rd party community developers who have run with an opening, how long before that gets deprecated but with Matter on the horizon and available in a very limited and complicated way right now, Zigbee and Zwave are looking doomed, just not publicly