Activating Philips Hue scenes from the new SmartThings app?

Is there any way to activate Philips Hue scenes that are stored on the Hue bridge? I was a very happy fan of Hue B Smart, which worked fantastic on the SmartThings App. This is obviously no longer supported on the new SmartThings platform.

This seems like such a basic feature that should be part of SmartThings. Is there a way to activate a pre-existing Philips Hue scene from within SmartThings these days? My legacy scenes from Hue B Smart still work but I am setting up a friend’s home with a brand new hub and brand new Philips Hue lights. I’ve programmed a bunch of scenes, which of course reside on the Philips Hue hub. Is there any way to simply use SmartThings to activate one of those pre-existing scenes?

Setting the scenes up again manually in SmartThings is not a realistic option, and not just because it would take forever to individually configure each light in a SmartThings scene. On the Hue hub, I have a number of scenes with very long transition periods, such as a Movie Theater scene where the lights in the home slowly dim and change color over a 45 second period. I don’t know of any way to replicate that kind of long dimming time in SmartThings.

Again, this seems like such a basic piece of functionality that should be part of the SmartThings integration with Philips Hue. Any thoughts or suggestions here? Thanks in advance!!

You can do it by using either Alexa routines (not SmartThings routines) or IFTTT as an intermediary.

In the Alexa app, choose “control scene” to see a list of all the scenes you have available as an action when you are creating an Alexa routine.


IFTTT is easier to set up Because you have more trigger options, but they now require a paid subscription for more than three rules and there may be more lag. Also, to be honest I’m not 100% sure the company is going to survive since they’ve started charging. But it would probably be the fastest way to get the functionality back.

The Alexa app is free As long as you have an Amazon account, you don’t even have to have an echo device. But there’s a more limited set of triggers, so you might have to trick it by creating a virtual sensor and smartthings, which is the part that makes it set up more work.

So it really comes down to the details of exactly what you want to use for the trigger, but both of these options will work.

At one point I think you could also trigger Hue scenes from Webcore, but to be honest, I’m not sure if that still works. Hopefully someone else will know. :sunglasses:

Any updates for this?

I would really like scenes to work in smartthings.

Just ran through this myself and it looks like it still requires Alexa as an intermediary. Would love to see a dedicated smart app for this. Not sure what happens to “smart apps” in the groovy-less future though.

You have to host your own smartapp (in any language you like), then communicate with SmartThings either via LAN Edge drivers or cloud to cloud API. So very different than today since there’s no free cloud provided by SmartThings. But potentially much more flexibility for those with the appropriate technical expertise. Also more local options, but that doesn’t mean your smartapp runs on the ST hub: it means you provide a separate local server device to run your smartapp and it communicates locally via the LAN Edge driver on the hub.

That is actually great news for software engineers. A local device talking to the Hue would keep it nice and tidy. Been trying to avoid cloud integration. Have done it so far other than ST itself, which is moving more local everyday

Hue already has a local operation option with smartthings, it’s just that it doesn’t expose Hue scenes.

Correct. That’s what I meant. A local integration that exposes Hue Scenes, Rooms and Zones

Yes, why is this not possible! It is not as though it would be asking too much to have proper integration for something that is already a feature of Philips Hue.

I think it is because it is specific to Hue and can’t be applied to all lighting systems. ST wants to be agnostic

In this case, it’s an issue of the Hue architecture. They don’t expose their scenes to HomeKit or Home Assistant, either. Only a few integrations, like Alexa and IFTTT, can activate a Hue scene.

The issue appears to be a waterfall naming convention. Hue uses the same scene names in multiple rooms, which makes it complicated for third party integration.

Would be pretty awesome feature boosting smartthings a lot, so sad!

Either activating a Hue Scene or using multi-casting for groups. At least then, you could define your scenes in ST using lighting groups without any popcorn issues. Either way would be great.


and what is that exactly ‘multi-casting for groups’?

This is technically different from “groupcasting” in the Zigbee specification and is not available on all stacks.


Zigbee offers both “unicasts,” a message intended for a specific device and passed along a route to that device. And “broadcasts,” which are delivered to ALL devices in the network and it is up to each device to decide what to do with that message.

It should be obvious that a unicast uses many fewer network resources and generates less potential interference than a broadcast, so unicasts are generally preferred.


Zigbee does have the concept of groups, but to be honest they’re pretty primitive compared to some other protocols. Each device can only be in one group, which is just identified with a number. Some device manufacturers preassign a group at the time of manufacture, some let you change it later.


A “groupcast” is a type of broadcast in Zigbee. It is still sent to every device on the network, it just has a group number attached. Each device has to check and see if it is in that group. If it is, it acts on the message.

Again, a lot of resources are used. Still, this is popular in Zigbee lighting implementations. Only SmartThings has never used it much, preferring to send a series of unicast messages, which is why you can see a “popcorn effect” for ST scenes.

That decision isn’t uncommon in platforms that support the use of a lot of battery powered devices like sensors. Do you really want to use up battery life on every sensor in the network every time you utilize a lighting scene? On every Zigbee lock? Sometimes the answer is yes, sometimes the answer is no, but it’s understandable if a consumer system like ST decides no.


“Group multicasting” is something else again, and is NOT part of the Zigbee specification, but can be added to a specific platform in the application layer if desired. (I may be mistaken, but I believe Control 4 uses a version.)

In this, instead of sending your group message to every device on your network, you send it only along routes that have devices in that group. This is harder than it sounds. Essentially you have to keep a record of origin nodes to use for the broadcast route and assign them to specific groups. This is doable for a professionally installed system with meticulous device placement and limited device selection (so that every device handles group assignment the same way), but I’ll be honest, I don’t think it’s practical for a DIY home system with lots of devices from different brands.


So…personally, I would like to see ST improve the groupcasting options available to end users, particularly being able to see which group a Zigbee device is in, to change that group if possible on that device model, and to issue a groupcast if we desire, maybe specified at the scene level.

I don’t expect to ever see ST add group multicasting unless they add a commercial services division for hotels and office buildings, but you never know.

@garrett.kranz @posborne @blueyetisoftware

1 Like

Following up for anyone following this thread. I am currently looking for alpha testers that want to volunteer to test an Edge driver that gives you access to Hue Scenes and Lighting Groups that can be automated. Send me a note if you want to be added to the alpha


Further followup…

We are actually out of alpha testing and the driver is publicly available. You can find it in this thread here: