Lighting groups with actiontiles

The lighting groups I setup on the new app aren’t showing up on actiontiles. Any reason for this?

I doubt the lighting groups would work. Many of the newer features in the new app are not built on groovy. You may want to contact ActionTiles support directly and ask. Tagging @625alex

1 Like

The API for the lighting groups is not published, yet. Maybe one day this feature could be offered.


I still rely on trend setter for my lighting groups. Mirroring is just too slow and unreliable.

1 Like

Agreed, that is why the new lighting groups are build on top of protocol specific groups :wink:

1 Like

Suddenly it is not visible in the new app. It not allows to add remotes to the Lighting group, but any bulb, switch or dimmer wifi, zigbee or zwave (any).

I am still seeing it show in the new app on iOS. if on the home screen pressing the + in the top right corner will bring up a list, one of which is “Lighting group”

Note that yes, it is limited to adding only lights (and the hub). The group is made available within automations as a single device which will send commands as multicast to all lights within said group.

Would you mind briefly explaining “protocol specific groups”?


Most wireless protocols are built on the idea of a specific device sending another specific device a message, or 1-to-1 message transfer. This works great and is how nearly all communication is done on the SmartThings Zigbee and Z-Wave networks. But a lot of wireless protocols also have the concept of a specific device sending a message to many devices, or 1-to-many message transfer. This can be incredibly useful for times when you want to send the same message to a bunch of different devices (such as when wanting to send an on or off command to a bunch of lights!).

Up until recently we did not expose a way for users to send these 1-to-many messages (aka group commands). The primary benefit of these, aside from reduced network traffic, is that the devices will respond much more in-sync with each other, so lights in a group will all appear to turn on/off in-sync with each other :slight_smile:


Now that’s what I’m talking about! Question… I’m assuming this message can all be executed locally then, correct?

I should have phrase my sentence better.
Yes, the Lighting Group functionality is in the new app. I can add lights to the group. But I couldn’t add the IKEA 5 button remote to that group in the same selection to utilize what you have suggested in the other topic.

But I think I have misunderstood it.

What I meant is having the remote assigned to the same group as the lights and let the remote to sent a group broadcast directly to the lights without the Hub’s intervention. (Defining the same group for all devices.)
Or do I misunderstand the whole concept?

The reaction time and everything else what you wrote in the other topic that is clear and sounds like a partial solution for the so called popcorn effect.

I should have been a bit more clear in my phrasing. We restrict groups through SmartThings as only being able to be comprised of lights with the intention that controlling the group is going to be done through automations or one of the clients. On the surface this might seem like a limitation to the utility of groups, but this actually allows us to provide a more flexible, configurable, and reliable experience.

The issue with allowing users to add remotes directly to groups is that group support in remotes is lackluster at best. Lets make an example of the EcoSmart remote which has recently became popular. This remote communicates exclusively through multi-cast (group) commands but there is no way to change what group the remote is a part of (it appears they hard code this). So if a user were to create 2 separate groups and want each to contain a different EcoSmart remote there is no way to actually support this without spinning up a whole second Zigbee mesh (no, just… no). The solution here is to instead not allow users to add non-lighting products to groups but rather to have the hub act as an intermediary through the use of automations. The EcoSmart remote isn’t the exception here either when it comes to how it handles group commands.

Also yes, I realize device groups can’t be controlled through automations just yet but it is coming :slight_smile:


So if I understand correctly, if the device (remote) will be assigned through an automation to a Lighting Group, the Hub will behave as a group broadcast device and if it receives a group broadcast from the remote it will broadcast it to the actual group in the automation. Am I right?
Or just the Hub will group broadcast any message what the remote button press has been defined in anywhere. Ie.: Even the button belongs to a LEVEL CLUSTER it will broadcast power on/off as it might have been set in the automation?

I think I just realized that you might really meant the second one. And I have just confused.
I am really looking for the functionality of the LEVEL CLUSTER being able control brightness without multiple button press and without delay.

Exactly. But…

Not exactly.

SmartThings is built on the idea of Capabilities and DTHs exist to convert messages/communication on a protocol into/from a SmartThings capability event. All inter-device communication exists at the SmartThing’s capability level, never the protocol specific level. Lighting Groups will not change this. The reason for this is to maintain the interoperability between devices.

As I’ve mentioned, Lighting Groups are backed by protocol specific groups but groups themselves are protocol agnostic. For example, there is nothing stopping you from creating a Lighting Group in the app that is comprised of 2x Zigbee devices, 1x Z-Wave device, and 1x C2C device. In this case, a Zigbee group would be formed with the 2 Zigbee devices but the group as a whole, as it exists within SmartThings, must be interfaced with through Capabilities.

So, if you have a Zigbee remote and want to control a Lighting Group comprised solely of Zigbee bulbs you still must convert the button presses from the remote into SmartThings capabilities which through standard automations can be used to generate capability events, which would in turn be translated as a group command sent to the Zigbee group. This model allows you to later add a Z-Wave bulb to the group and everything would continue to “just work”.

The 2 things groups really give you are:

  • Eliminate “popcorning” if attempting to control multiple bulbs simultaneously (popcorning can still occur if using different model bulbs or bulbs that use different wireless protocols)
  • Convenience for setting up automations where you have a set of bulbs you always want to control in sync

I really appreciate the detailed answer. I misunderstood you previous but now it is clear. Thanks!


You explain this really well - thank you!

Hi all,

New here. But if I understand what your trying to do I created a virtual device with the lights from the lighting group and am able to control them with Sharptools.

1 Like

Hey everyone! A known issue with Smartthings and ActionTiles is the ability to create lighting groups.
I created a video and step by step guide on my Youtube Channel and website for everyone who is looking to accomplish this. The links will be down below. You will learn how to create lighting groups in action tiles and control them with a responsive switch by creating a virtual switch. ActionTiles is a great program to use alongside your smart things set up but not being able to create and use lighting groups in action tiles was a real bummer until now! Learn how to create custom lighting groups in ActionTiles with a responsive virtual switch. Also, learn how to create virtual switches, scenes, lighting groups, automations, and smart apps in Samsung Smartthings!

Hi Broderick,

I realise this thread is a year old. Is there any update to when we’ll be able to control lighting groups from Automations?

I see there is also no ability to set the lights to the same colour? Is this a limitation due to the problem mixing different bulbs and colour dynamics?