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.
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.