Different types of Groups


(April Wong) #1

Many home automation protocols often several different types of groups.

@JDRoberts writes a comprehensive guide on Groups.

  1. Rooms. Useful for both the network itself and the people. The people find it a logical grouping. For the network, the group members are almost always line of sight to each other, which in turn makes possible some delegation to local controllers and some other traffic balancing. Some home automation controllers do behind the scenes stuff that allows groupcasting to a room.

These days, several protocols group rooms into zones, like “First Floor.” HomeKit does this.

A device can only belong to one room.

  1. local association groups. Allows a local controller to communicate directly to a few specific devices. Typically this is a handheld remote and an entertainment center or a wall switch and a group of lights. From a person’s point of view, used to match a controller button with a group of nearby devices. From the network point of view, delegates message control (often with complications to status reporting.)

This type of group is usually limited to a much smaller number of devices than a room.

An end device, like a light, can sometimes only be directly associated with one controller, but a controller can associate each button with a different local group. And some standards do let an end device associate with more than one local group. So one button on the remote might turn off 2 overhead lights while another button turns off the 2 overhead lights plus a table lamp. The overhead lights are associated to both groups. so it just depends on the exact standard in use.

  1. services groups (zigbee term). Basically free form group that can associate any devices anywhere in the home to simplify EITHER rule setting OR traffic load.

For example, you might group a pathway of lights from the kitchen upstairs to the bedroom. Multiple rooms, not all line of sight, but commonly turned on or off at the same time.

Or you might group all the bedroom fans together except the guest room so you could turn them all on or off together. This might be done through groupcasting to reduce message load, serving a technical purpose, not just UI.

A device can belong to as many services groups as you want. Some may be added invisibly by the traffic scheduler to accommodate groupcasting while others are for human convenience.

  1. separate from device groups such as the 3 above are Scenes. Scenes do not group devices–they group action requests for specific devices. Most notably a scene lets you send DIFFERENT action requests to different devices at about the same time. So you can open the garage door, turn on the garage and kitchen lights, turn on the coffeemaker, and play some music all with one button press. Or some other trigger.

Groupcasting for device groups sends the SAME action request to all the devices in a group. Typically on/off, although “on” may mean different things to different devices.

Scenes lets you send a bunch of action requests at about the same time, but with different parameters for each if you want, whether it’s different dim levels for different bulbs, or just different types of actions like disarming a siren while turning on music.

Ideally scenes lets you send action requests for multile device groups, for both UI and technical reasons.

And again ideally secondary controllers can also be set up to tell the hub to trigger a global scene. So a button press on the handheld remote triggers a scene with different devices doing different things in different rooms.

So…

Different kinds of groups serve different uses. Some are based on physical location, some are based on association to a local controller, some are based on groupcasting even if the devices are in different places. Or just UI simplification.

Some types of groups only allow a device to be in one group of that type at a time. Other types of groups, particularly services groups, let a device in multiple groups of that type.

And scenes let you tie together disparate action requests based on a common trigger set. Ideally, for both technical and UI reasons, scenes should be able to include groups of any type supported. But that can get really messy. Suppose your scene says “turn group A off” and “set group B at 50%” and the hall light is in both groups? Or maybe when you defined the scene the hall light was only in group A, but later you also add it to group B?

Device groups have pretty simple grouping rules, most UIs can handle them. As soon as you let Scenes include device groups, though, the UI has to get a whole lot smarter and more complicated. Or you get “unexpected results.”

All of the above applies to Home Automation in general, not specifically SmartThings, but may be helpful to consider.


#2

Thanks for the mention. I just wanted to make very clear that the above describes how groups MIGHT be handled in home automation systems, but not that SmartThings handles groups that way.

As of this date, for example, ST offers limited option scenes, but I don’t believe you can apply them to device groups.

If anyone reading this is looking for specific information on using shortcut groups in SmartThings, see that FAQ instead: