Rules execution order

Hi

I’m a new here and I’m still trying to figure out how all this smartthings rules, automation etc. works. So please forgive me this dumb question.

Let’s say I have two wiz light strips. And I need to synchronise them, when one switched on/off other follows. Lights have on/off switch on wire.

I quess robust thing to do this 4 rules. If dev1 is on then dev2 is on. If dev1 is off then dev2 is off and vice versa. Sure someone might do this much better.

Anyway, in which order rules are executed and is it possible that these 4 rules causes somekind of eternal loop? Dev1 is on → dev2 is on → dev1 is on…

Install Smart Lighting and use the mirror option.

Note: Smart Lighting will get updated soon and I would assume all the current features will be in the new version but you never know until it is released.

Add Routine > tap the discover tab > scroll down to find smart lighting to install.

2 Likes

Do you know of a way to access Smart Lighting in Europe? I’m situated in Denmark, and Smart Lighting does not come up under the Discover tab…

Perhaps the new Smart Lighting plugin will be available to more regions. Who knows! :man_shrugging:

I guess I should have mentioned that the current version is only available in certain regions. :frowning:

Thank you for the reply even though it wasn’t the answer to the question. Hopefully someday Smart Lighting will be available in Nordic countries too. Didn’t even know there is a such an application. Meanwhile I would like to have some deeper understanding about the ST routines and API rules. Is it possible to “flood” the system with poorly designed rules?

I can’t give any insight into the routine execution logic. That said, it is possible that your routines could cause an infinite loop. If that happens you try can adding stays for 1 or 2 second to the If condition and that seems to stop the loop. Depending on the devices and speed they register, you may have to play with the stays for timing.

It is certainly possible to create infinite loops using Routines and Rules and it famously happened to many users using virtual switches alongside the Security Mode.

The platform normally only propagates events where there is a state change, so an automation might only ever see on / off / on / off from a switch even if it is capable of sending e.g. on / on / on / off / off / on / off. However that behaviour is overridden by some devices. For example, with a button you need to be able to receive consecutive pushed events and if you have a device that reports at regular intervals you probably want those events to be seen even if the value hasn’t changed. Less obviously, the stock Virtual Switch device does it. So an automation can receive e.g. on / on / on / off / off / on / off.

So if you write ‘if dev1 is on then set dev2 on’ and
‘if dev2 is on then set dev1 on’ the potential for looping is there. That is essentially what happened in the case I referenced at the top. It worked right up unto the point where the implementation of Routineds was changed and the loop was no longer being broken somewhere.