Accessing group within a SmartApp

Can anyone tell me how to access the group of a SmartThings device when an event is triggered? It doesn’t seem to be a property of an event (it’s just coming back with NULL instead of the actual group name).

I’m also interested in the answer to this. I’d like to be able to set the group for the child devices I create if the group was preconfigured from my mac client.

The groups are just that. “Groups”

they are not actionable or managable by a smart app.

I would also like to be able to access this.
In the device listing on the website it looks like a property of a device - so why isn’t it available in a smartapp?


Groups it seems were designed to designate rooms associated with devices (kitchen, bedroom etc.)

It would be great to use groups for rooms.
Groups in the mobile app can not only be by room but also by type (lighting, motion etc.)

To designate rooms it would be great to be able to define a group with one device.
For example if there is only one motion sensor in the master bedroom.

It would also be great to have a way to access a devices group via the api for example


Totally agree. I cannot see a reason why groups can not be child objects under “location”. At very least, an API should exist to enumerate groups and to query if a device belongs to a group.


Discussed already in many variations…
Just a few examples…

NB: Like Windows and Linux, the latter discussions mention that Thing should have the ability to appear in multiple places via Shortcuts (soft tiles), with a view selectable for each shortcut. This is but only one possible way to implement the ability for a Thing to be in more than one Group. Meanwhile I also discussed the functionality that Group Tiles could provide, especially if they contain Things of all the same type, like the current half-hearted implementation of Dashboard Shortcuts.

Does the Solution Module app type describe this?

From Types of SmartApps

These apps exist within the dashboard of the SmartThings app interface, and are containers for other SmartApps. The idea behind Solution Module SmartApps is to combine SmartApps that, in the real world, intuitively go together. One example of this would be the “Home & Family” section of the dashboard which allows you to see the comings and goings of your family.

Solution Module SmartApps have traditionally been built by our internal team, but we will be opening them up for external development in the near future.

Of course, this seems a little at odds with the SmartApps as connecting objects with UI focused on configuration rather than data presentation and control of state.

I’m not sure I understand your question…

Many home automation protocols often several different types of 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.


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.


Good answer… Can we put it in a FAQ?

The quoted portion wasn’t a question, but an observation that the described grouping of SmartApps via Solution Module SmartApps would not accomplish the goal of presenting information and controls if SmartApps are about configured relationships, not control or UI.

Ah, so when you say “group”, you’re talking about group, not a group. :smile:

I was wondering something similar this morning; not so much about grouping but using SmartThings to designate/manage direct associations between devices to create simple conditional relationships that don’t require the logic in a SmartApp or device type, saving the round-trip time to the servers and getting rid of the internet dependency for that one particular relationship. Different topic for a different time.


I totally agree with your observation.
Bluntly – “Solution SmartApps” (and the various UI Groups that are related to them) seem like a bit of a band-aid that was added to simplify access to basic functionality expected of typical devices – i.e., Turn on or off all the lights in a room; Turn on a light when a motion sensor triggers; etc.

Except for the production of and access to the UI Groups/Shortcuts, the Solution SmartApps are no different from regular SmartApps.

So… The UI Groups/Shortcuts are a good clue as to what should be a fundamental functionality in SmartThings.

I’ve discussed true Groups in many, many threads, and so has @JDRoberts.

Hence my references in the above Post:

I wonder if there is a way to focus this discussion.

Or, to put it even more bluntly, it’s a symptom of a Multiple Personality Disorder. :smile:

There’re many different ways to do “basic” things - “Solution Apps”, “Dashboard”, “Hello, Home” but none of them does it well. It looks like different people had entirely different (and mutually exclusive) ideas how things should work, but decided for whatever reason to implement all of them in a single app anyway. I think it has something to do with the fact that SmartThings had seven founders. Reminds me of an old Russian proverb: Seven nannies make a one-eyed kid. :smile:


So, one year later…

Is there a way for a SmartApp to determine the room a device belongs to? (My SmartApp subscribes to lots of devices, and I want it to know what room a device is in when it handles an event).

1 Like

You can access a device’s groupid at device.device.groupId but I haven’t found an easy way to get the group name from there.
You could use while logged into the ide and map each groupId to the group name and store it in your smartapp manually if you really want this functionality.


Thanks @AndyRawson. I’ve got that working, so the next challenge is finding a way to enumerate groups in order to get their names. I’ve tried getting groups, location.groups, location.hubs[0].groups,, device.groupName but none of them exist!! :rage: So I guess this simply hasn’t been implemented or is blocked due to the security context of SmartApps.

Anyone have any idea what the most effective way raise a feature request is? (SmartThings don’t seem to have taken any notice of this thread in over a year… )

As Andy says, the best work-around right now is to manually encode the mapping between group Ids and their names within my SmartApp. Kinda sucky, but at least I don’t have to manually encode each device–groupName mapping manually!!

1 Like

Just for reference, here’s how I do just that my InfluxDB Logger app:

 *  getGroupName()
 *  Get the name of a 'Group' (i.e. Room) from its ID.
 *  This is done manually as there does not appear to be a way to enumerate
 *  groups from a SmartApp currently.
 *  GroupIds can be obtained from the SmartThings IDE under 'My Locations'.
 *  See:
private getGroupName(id) {

	if (id == null) {return 'Home'}
	else if (id == 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX') {return 'Kitchen'}
	else if (id == 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX') {return 'Lounge'}
	else if (id == 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX') {return 'Office'}
	else {return 'Unknown'}    
1 Like

@Aaron, I’m still really keen for there to be an officially supported way of enumerating group names from within a SmartApp. This has been a glaring omission for so long now! Is this on the development roadmap?

1 Like