Hi All, did some searching but cannot find the answer. I’m using SmartThing and wanted to know If I have multiple rules that trigger at the same time, how does SharpTools handle the request? Meaning which rule goes first or do they rune at the same time. Can SmartThings handle multiple request at the same time or is it best to stagger the rules?
@Robert_Bourne, rules are triggered by the order of event received, and each triggered rule is processed asynchronously if the triggering events are different but came at the same time. But rules triggered by the same event are executed sequentially which we have discussed internally if it should be changed to asynchronously though. We rarely see SmartThings having issue handling multiple devices requests sent by multiple rules, but of course you don’t want to maliciously send loads of requests.
Is there a particular scenario or use case that you are working on? Maybe I can better help/answer the question if you can provide more details.
@James thanks for the response. As an example: I have a goodnight rule that turns off interior lights and turn on exterior lights but also have another rule to turn down the volume of echo speakers at night. I’ve notice that some echo device would work but some wont. If I stagger the rule a minute before or after then it works fine. That’s how it’s currently set, was just wondering the sequence when multiple rules fire at the same time.
Also, on a separate note - when troubleshooting, is there anyway to know which rules trigger a certain device? Example: Family room lights, kitchen lights, bedroom lights, etc are in different rules and they turn on or off unexpectedly. SmartThings classic app says the command was sent from SharpTools but no way to know which rule to look at. Hopefully my explanation is clear.
Thanks,
Thanks for the details. I cannot think of a reason why the echo speaker rule needs to be staggered for a minute. 
You can pm me with the rule details, and I’d be happy to help look into it.
For troubleshooting the unexpected light on/off, you may want to add an email notification temporary for those rule turning light on/off, so you can check what rule was just executed when the unexpected lights on/off. This suggestion is apparently not ideal, but probably the easiest way I can think of, and allow you to trace the email history to know the order of rules executed. The other idea I had is to set the rule name to a Text variable in each of those lighting automation rule, so you can the variable value to know what was the last executed rule. While this doesn’t bother you with multiple emails, you won’t be able to trace the variable history to know the previous two or three rules executed. Feel free to let me know if you need more guidance or any questions.
Just corrected my answer about the rule execution question that I forgot the case of the rules triggered by the exact same event. See below.
I use Pushover to allow debugging of rules in situations such as this. This allows me to set notification “levels” which are handled differently on the receiving devices. Example, low pushover alerts are have a temporary pop up and no audible sound, Normal alerts have a pop up and a designated sound, high level alerts have a pop up with designated sound and need to be acknowledged but will conform with mute settings on the device, and Critical alerts have sound and pop up and repeat until acknowledged regardless of device mute settings.
This allows me to embed notifications in my various routines that allow varied levels of notifications. For debug, I can then choose the priority of the notifications, allowing key processes to get immediate attention.
Really facilitates debugging from Sharptools, WebCore, or automations, or on other apps such as IFTTT.
2 Likes
@Alan_Izat, thanks for sharing the Pushover tips. It’s really a great idea to leverage the priority of the notification with different sound and display settings. 
1 Like