Maintain hue color after switch powercycle

Just wondering if anybody know how to keep Philips hue bulb color after physically switch off and back on?

I know the hue color will revert back to factory color after switch off and back on. Does ST have a way to have the bulb go back to its last saved or set color?



Don’t think so, buddy! Once you physically turn it on and off, it will reset to the standard color. Some genius may write a custom app, may be! :slight_smile:

1 Like

A brute force approach is keep sending a color change command frequently, regardless whether the bulb is powered or not. When a bulb finally gets the power back, it will eventually receive the command and chance the color.

Is there a better way?

@scottinpollock had a power restoration app that turned hues back on. I don’t remember if it restored color and I can’t seem to find the app in the search

errr - sorry missed the part that this was a physical power off, instead of electrical power off

I see, hopefully they can have a second version with a built in memory of the last saved color.

1 Like

A less “brute-force” approach is to max out your lights in your code at 99% and then periodically (say, every 5 mins or so) check for any hue light that is at 100% – which would indicate a physical off/on – and then adjust the lighting accordingly.

1 Like

How is it less brute force? You are still polling periodically.

Are these Hue bulbs via the hue hub or directly paired to ST?

In theory, on power on, there is a ping to the hub to indicate a re-joining the mesh. Ala how the presence sensors work. This “could” be used to issue a restore last known state, but this probably requires a platform change and if I even suggest it to support, I’m sure they’ll tell me wait till hub v2…

Anyway, if it is the hue hub, then it would be up to polling or something hue could fix with firmware in the hub.

1 Like

The hue bulbs are connected to hue hub then ST. I didn’t know you can connect to ST without the hub hub.

SmartThings advises against connecting Philips Hues without the bridge.

The reason has to do with zigbee profiles and zigbee channels.

Hues are sold as ZLL (zigbee light link) profile. SmartThings uses the
ZHA (Zigbee Home Automation) profile. ZHA can use more channels than ZLL.

To connect a zigbee bulb directly to ST, you have to treat it as a ZHA device. If you are unlucky and your ST hub happens to operate on channel 14 or another nonZLL channel, the Hue bulbs will work without the bridge, but it will be very difficult, perhaps impossible, to get them back on a ZLL channel again. So you may lose any future ability to pair them to a Hue bridge.

Since SmartThings support doesn’t want to damage the compatibility of one hue bulb with another, they just suggest always using the bridge.

You don’t need the bridge for bulbs like the GE link that operate as ZHA devices anyway.

That would only be true for Hue bulbs paired directly to the ST hub, which ST says “is not supported at this time.”

There’s no zigbee connection between the ST hub and the bulb when the connection is via the Hue bridge.

Moreover, ZLL is a hubless mesh. No controller required. So it’s actually technically really different than how the ST zigbee presence sensor communicates with the ST hub. The ZLL devices form their own mini network.

ST doesn’t support ZLL, so pairing a bulb to ST hub is using the HA profile which all ZLL bulbs also support. This is why hue bulbs will pair with the hub. I agree it isn’t supported, but it can be done.

During the HA profile join and all re-joining processes there is an announcement packet that the device sends and is logged by ST.

Watch the live logging, turn off a bulb paired to ST via a power switch and then turn it back on. You will see a JOIN announcement which is acknowledged but unavailable in the device parse to handle. This is exactly how the presence sensors work.

Technically any battery powered zigbee device could be used as a presence sensor IF ST made that announcement code-able / parse-able.

In the live logging, you will see it in the main feed, but it will not get routed to any specific devicetype. It is a hub announcement. Same thing happens when pairing a device as well.

Ideally, hue bulbs and frankly all bulbs should use ZLL and not fall back to HA profile, but until ST supports ZLL officially and has a ton of other zigbee feature sets, we are at the mercy of what is there.

Bottom line, don’t pair your hue bulb to ST. (if you do, you are on your own. Mine are, it works, but I’m one of the lucky ones that has a hub with zigbee channel 20)

1 Like

Eventually we’ll get Zigbee 3.0 and all the profiles will be folded into one. Someday.

Meanwhile, sorry if I was unclear. Absolutely if you’re pairing the bulb as a
ZHA device directly to the hub you’ll see the JOIN packet. I just meant if you were using it as a ZLL device and accessing via the Hue bridge things work a lot differently.

The real issue is that ST doesn’t let us change the zigbee channel. Even the
Hue bridge can do that (although only to ZLL channels). Someday, some generation. :wink:

I wonder if there is a back alley somewhere someone is selling ZLL harcoded zigbee channel ST hubs.


Hey, want an ST hub zigbee channel 20?

Come on, I know you want to connect your ZLL bulbs directly via HA, I know you do.

Just do it, take the leap.

What could go wrong…


I am trying to address a similar problem with a Smartapp I am writing.

In my case, I don’t care about the last color, but I care that when I turn the switch and my Hue comes on, comes at the same color every time.

My configuration is:
Z-Wave Switch (Controls 3 lamps in the circuit)
- One Hue BR30 (stairs)
- Two Ceiling Lamps with regular bulbs (upstairs hallway)

My Scenario:
I have a motion sensor that when it sees motion turn the Z-wave Switch. When the smartapps detects that the Z-wave Switch turned on, it waits a few milliseconds to send the color/intensity/etc settings to the Hue bulb. That way, every time I turn the Z-wave Switch On, I get the desired color.

It’s quite unlikely that you could schedule to the level of “a few milliseconds” in a zwave or zigbee install, let alone a mesh to mesh execution, mesh just doesn’t allow that kind of precise timing. Maybe, if you’re lucky, it will work, but the results may not be quite what you expect.

It’s more likely that the bulb will first do whatever the manufacturer default is, and then shift to the color you instruct.


How would I go about finding what zigbee channel my hub is on? In the ide?

Yes under Hubs

FYI you are responding to people’s post more than 2 1/2 years old btw.

Start a new topic when you have a new question or in a current topic that people are still posting to. :slight_smile: