Automations Vs Smart Lighting in new IOS app

I have been testing both the new Automations and Smart Lighting. To test I set up a simple flow that I wanted to achieve. It consists of a Motion Sensor and a Smart Plug. Both devices use standard device type handlers and run locally. The flow is simple the motion sensor senses motion and turns on the plug. I then created the Automation in Automations and put a tape on the floor, so that when I step into the sensor range it would be from the same place. I stepped into range, and the plug came on with a lag of about 4 seconds. I tested this 4 times all +or - 2 seconds. I then used the internal switch in Automations app to disable the Automation. I then created the same automation in Smart lighting. I again tested from the tape on the floor and found that the plug came on almost instantly. I tested this 4 times, and all tests were the same. Why “Automations” reacts slower than “Smart Lighting” is a mystery. I am curious to know if anyone else has found this.

I did find a bug with graphics rendering in Smart Lighting, but I think it is because I am using IOS 14 Beta. Hopefully this graphics bug is fixed when the final release is out. If not I will contact support.

Automations run in the cloud. Smart Lighting does run local. I avoid Automations at all costs because of this.


Thanks, but then I wish ST would update Smart Lighting in order to have a smarter system. Example Automations has delay off in seconds, not minutes like Smart Lighting. Something I want that ST will never give us is a PC/Mac app to run on the desktop. It would be so much easier to work on my iMac. I am looking for a decent emulator for IOS. Most emulators run in a small window, but I want it to fill the screen. X-Code is what I use now.

1 Like

I worry about the future of Smart Lighting (And webCoRE for that matter). For that reason I want to use Automatons, but I’m having some buggy results using them… I really like the local execution though!

As noted above - not a mystery. Cloud vs. local execution.

Smart Lighting will almost certainly go away next year with the Groovy infrastructure shutdown.

Optimists will hope that eventually Automations will execute locally. Or the new Rules API will execute locally. Or some other front end that replaces them will have rules that execute locally.

Pessimists will note that SmartThings has been promising more local execution for 5 years and hasn’t delivered it at all. And everything that they have introduced to replace existing functionality has been sorely lacking in many ways.

(Realists will simply buy a Hubitat hub and move on)


This. And automations are buggy AF. Stick with SL.

1 Like

I am running IOS Beta 14, and have found Smart Lighting to be buggy. Example: Create a task that requires a start and finish time. The time selector opens twice for start and finish. In order to save the start time I have to fill in the time twice for start and twice for finish. Then even after that graphics remain on the screen. But it runs so much faster than the Automations.

Now my SL routines are randomly not running the turn off after portion of the rule… so lights go on… and stay on and on and on and on…

its costing me money now… you can check in but when you leave the lights stay on… im sure someone wrote a song about this.

I had about 25 lights set up in an Automation and it kept on crapping out, some lights worked, others didn’t and it was random as to which. Transferred it to Smart Lighting and now it works perfectly.

Local rather than cloud executions make so much sense.