How are multiple "devices" handled in rules?

In conditional operations (e.g. equals, …) and commands (e.g. switch on), devices are expressed as arrays but, in all the documentation that I have seen, only one deviceId is ever given. In such cases, the implication is clear: act on the single device.

What happens when multiple devices are given?

Say, for many devices in a switch equals “on” condition?
Do all of them have to be “on” for this expression evaluate to true (an implicit and operation), do just any of them have to be on (an implicit or operation), or is it some other behavior?

What happens in commands (all, any, other)?

This behavior should be documented.

The short answer is that for a conditional operation like equals each of the devices on the left (or right) side is compared to the operand on the right (or left) side and the default aggregation (set at the equals level) is any, but can be set to all.

You might wonder what the aggregation (defaulting to none) in the devices operand does. You may also wonder what on earth happens if both the left and right side are arrays of devices. I am also wondering this but have never got around to finding out.

With the command action, all the commands are applied to all the devices. Well at least I assume they are. It isn’t terribly clear.

Hopefully when the Recipe Creator (?) comes along it might make it more obvious what the API reference is trying to say.

1 Like


How did/do you “find out”?
Documentation (where)?
I worry about depending on empirical behavior, especially when things (AFAIK) are not final.

What about commands?

As far as I can tell, the API reference …

… doesn’t try to say anything at all regarding this.
In any case, it should.

API | SmartThings Developers has a lot more of the raw detail if you drill down into it. If you look closely you will discover that its idea of what Rules are available is more comprehensive than that in Rules | SmartThings Developers but not actually a superset of it. Also they use different terminology.

Neither reflects what is actually live, they are just two different versions of what they are prepared to acknowledge overtly. You won’t find any mention of toggle, fade or limit for example but I know they exist (that doesn’t mean they are ready for public consumption).

1 Like

We have updated our documentation regarding this issue. We try to be more explicit on the behaviour of a command applied to several devices and the aggregation operand.


AFAICT, the only documentation change is addressing multiple device behavior with respect to the equals operation in an if condition. What about everywhere else?

Hello, @rossetyler
The behaviour regarding a command with several devices has been documented as well. We already had an example here and we complement it with a disclaimer.

You have? All I see is an invitation to visit the aggregation operand in the Rules API reference where it apparently remains as minimally documented as ever. In particular it is unclear as to the effect of aggregation at the operation/condition level (the developer docs and the API reference disagree on the terminology) e.g. equals, as against in the devices operand.

1 Like

Was this ever clarified? Or an example provided? I’ve been down the documentation rathole on this, and either I’m in the wrong place (as I often am) or the documentation is still incomplete.

I haven’t noticed that it has been. I still don’t understand how the vague explanations in the API Reference were thought to have been in any way improved by adding a link from the developer documentation to said explanations.

Certainly the following statement I made a year ago still applies.

I also remain mystified by the operand available under changes. I have seen it used for detecting changes in temperature from devices which is great, but it makes no sense when changes is supposed to act on boolean values.

1 Like

So if I want to change aggregation to ‘all,’ the correct rules syntax is … ?

It just shouldn’t be this hard.

Here is part of my ‘away’ Rule in YAML.

        - equals:
                  - &a_presence xxxx
                  - &b_presence yyyy
                  - &c_presence zzzz
                component: main
                capability: presenceSensor
                attribute: presence
              string: not present
            aggregation: All
1 Like