I have a simple automation that turns a light on in the closet when motion is sensed.
This automation has worked perfectly for YEARS and the light would go on just about instantly.
The past few days, this automation takes 5-10 seconds before the light comes on.
Any idea what is causing this?
It is a Smart lighting automation.
Have you tried a Routine just for a comparison? 
but there have been others talking about a slowness over the past few weeks.
I could, but to be honest, I’d rather know and understand why something that has worked for years perfectly is now sluggish.
couple of possible suspects:
does the contact sensor display the current state in the app promptly?
you will probably be asked… which hub do you have and which brand/model motion sensors
SmartThings is currently undergoing a substantial change in their entire system. This has been communicated via email and is discussed all over this forum. The old SmartLighting app is being replaced. The new one seems to not be fully baked. In addition to that, the underlying architecture that controls your devices (Device Type Handler) is going from a cloud based system to local on hub execution called Edge Drivers.
All of these things will ultimately lead to a better experience. But we’re in the midst of a major change, so expect problems.
While everything @RJGill84 says is true. Still is VERY frustrating for people. Their most likely just looking for something to point them to a hint or answer to try and make things more stable.
I can say this from my personal experience during this transition. Yes I am trying to change things over and get things to be more stable as many here will suggest. I am also trying to be very patient and live with the glitches.
To that end, it is hard to do when you have routines that work and then next time don’t work. Or maybe work but some random time later.
You have lights that randomly come on whenever they want, or just never come on.
You have motion sensors, door sensors reporting temperature and motion events but automations struggle to function off those events.
So while what you say is true, it’s a hard pill for people to swallow. It gets old and frustrating when you have to keep swallowing it over and over. Keep tinkering, adjusting, trying to figure out why over a VERY long period of time.
Just my 2 cents on the matter.
For @pbusardo I don’t have any help, just share your frustrations and also trying to keep my Smartthings setup functional for my house. As you can see I’m experiencing the same issues and then some.
For what it’s worth. I have a simple motion sensor trigger that turns on garage inside lights. It triggers within a second or less as it always has.
Mine is running in the new Smart Lighting on Hub V2. The motion sensor is a SmartThings one and has not yet been converted to an Edge driver.
A little more fuel for the fire…
I have 3 open/close sensors. All are edge, never had them with dth. I have these included in 3 routines, with 3 lights set on or off depending on the open/close of the sensor. 2 of the rules have the condition that they only operate between sunset and sunrise. They all worked essentially as soon as the door was opened. In the last week the one light without a nighttime condition started lagging so it would take at least 4 seconds to come on. These are all running locally.
One thing I’m considering as part of these lag problems is the route the signal takes. We used to be able to see the hops, but with Edge, as far as I know, we can’t see the hops back to the hub anymore. As devices get converted, do they change the hops they used to take? I’m thinking absolutely they do. A device that is cloud connected couldn’t be part of the hop for a locally running device, can it? As the migration continues, I suspect this is a major issue. Running a Zwave repair may fix issues IF your problems are in the Zwave network.
Another issue we’re probably facing is the limitations of our hubs. Now that they are processing more local actions, the strain is probably starting to show. Especially if you have routines that are constantly polling.
I would guess not but I’m purely speculating. Even if the DTH ran in the cloud pre-conversion, the Z-wave or ZigBee network communication was and remains strictly between the hub and the device.
From what I’ve read, everyone has been reading much more into the very limited routing information that the IDE have. Z-wave and ZigBee are mesh protocols. Any given message can hop thru the mesh via any available path. Each device keeps a list of “neighbors” and can use any neighbor for any message. The IDE showed one neighbor only.
I’m sure I’ve vastly oversimplified this and missed some key points. 
You always have the option of triggering a rebuild of your meshes.
Just thought I’d update everyone. The automation is now back at full speed with no action taken by me.
Thanks everyone for the suggestions.