2 of my 3 automations in question contain only local devices. The third contains all local except a Smartthings cam which is of course cloud based but it is the trigger
I had an automation working for over a year. 1 sensor to trigger 3 lights simultaneously. 3 lights to stay on for 2 minutes and all auto turn off together. Now 1 light, lets call it light A will turn on only. After 2 minutes when light A turns off, light B will turn on. After 2 minutes when light B turns off, light C turns on for 2 minutes.
In the automation if I toggle the the “Auto turn off (after 2 minutes)” to off for each light, then they all turn on together as expected when the sensor is triggered. However its a middle of the night, hall/toilet/bedroom automation where I need the lights to turn off when I go back to bed without me having to manually do it.
This has ongoing for 2 months now…since the app update that moved automations to rules API
It’s broken. 
For now, the easiest workaround for your situation would be to create three separate Automations, each one triggered from the same sensor but working with only one light.
There might be a slight “popcorn effect“ where one light comes on a few seconds before the others, but at least you won’t have to manually use the app.
This what I had to do, though I shouldn’t have to half bake something that has worked literally for years just because of ST “growing pains”. This is unacceptable
2 Likes
Yeah… very frustrating & disappointing… im now also finding that occasionally 1 of my lights affected with this issue turn on during the day (when the automation is set to not turn on during daylight hours) !!
Almost time to replace smartthings completely!
1 Like
@troy_owens , @Fletcher_Moss, @Alex_A,
It is not the solution to the problem with automations, but while they solve it, I don’t know if you have tried it, but the same automations can be done with the smart lighting smartapp. Except the one activated by the camera, I think.
I changed them all to this application, in my opinion now it works better than automations and if are local devices they run locally.
Can’t do with the smartapp is:
- individually activate and deactivate each automation. this only can be done in IDE, localization, Smartapps
- Mix trigger devices, motion, switch, contacts…
1 Like
tried smart lighting but there is no option to turn lights off after a specified period of time
Thanks, I’ll take another look. Totally missed that
1 Like
I am experiencing the same problem. Actions are being executed serially instead of parallel.
This is ongoing for 2 months now. .it’s become quite obvious that there is no intention of fixing this issue as Brad has replicated and forwarded this information to the engineering team twice now.
That’s kinda pathetic. A company the size of Samsung should have a software QA process in place that includes automated regression testing. How did something like this get through QA?
I can see adding sequential execution as a useful option, but the default should remain parallel for backwards compatibility unless there were software release notes to the contrary.
I have been using Smartthings / Automations for a few years and they have been relatively stable, so this one appears to have slipped through the cracks or I missed the release notes.
1 Like
Because literally, nothing is thoroughly tested before it is released. That is the reason ST is the hot mess that it has become
1 Like
If there is any QA going on it’s by a group that is utterly ill-equipped.
1 Like
What? ST has QA? Since when?
1 Like
Yeah… im done with it !!
Spent way too much time on trying to fix this issue… pity st dint care as much.
1 Like
I tested this yesterday, created an automation that switches on 2 lights when my garage door is opened… And I sort of expected to run into this problem, but somehow, I didn’t. I did get a little bit of what @JDRoberts called the popcorn effect… there’s a bit of lag, even though they are in the same automation, they don’t go on at exactly the same amount, there’s like one seconds between them, but I did not get the effect you mentioned above where one light has to go off before the automation moves on to the next light.
How could this only affect some people, but not everyone?
It depends on the exact configuration. If you read the other posts in this thread, you’ll see that it seems to have to do with DTHs which are running locally and maybe with the specific model and factors in the automation.
1 Like
Right, missed that bit… Mine are used on switches with custom DTH that are (I believe) running in the cloud, so yeah, there’s the difference. Big inconvenience then for these guys 
2 Likes