Issue with hue lights turning off and mysteriously coming back on again using ST Mobile App

Anybody else facing this issue when the hue lights are turning on back again after an off command is sent to them?

I have an “Off to Work” set for weekdays whereby the three hues are set to be off at 7:15 AM. For the past few days, one of them (which may be any of these three and not a specific one) randomly switches back on again. Checked the log too. Weird? This has been working forever.

We so need a full integration with hues (or to that matter any light) because everybody uses them on a daily basis and it is the most basic functionality.

Log shows:

2014-11-18 7:15:22.802 AM EST 1 hour ago DEVICE switch on Living Room 3 switch is on
2014-11-18 7:15:01.770 AM EST 1 hour ago DEVICE switch off Living Room 3 switch is off
2014-11-18 7:15:01.583 AM EST 1 hour ago APP_COMMAND off Off To Work sent off command to Living Room 3

Not exactly the same but I have TCP bulbs that were doing this for about 2 weeks. I have one set to come on at Sunset which it would, but then it would randomly turn off. In mine I would turn it back on again then it would turn back off after a random amount of time. I could never find a pattern. I tried uninstalling all the lights and reinstalling and configuring again and it kept happening. I contacted support and they said they couldn’t see anything wrong. About 2 days after working with support it stopped happening.

Not sure if it could be the same type of issue.



Are the lights really turning off, and not just the command posting. I had lights and switches do this in the past it turns out they lost their connection to the hub. The hub remembers the last command successfully sent and not just the last command.

k. I am at work now. Will try to simulate this but not sure if this will be reproducible as no guarantees if connection gets dropped.

Also pretty much every time the All Lights on, All lights off, All Lights on at Sunset and Good Night Hello Home Actions work with zero issue with 7 hues, 2 lightstrips and 1 LivingColors either triggered manually or scheduled.

The lights in question are three hues, a subset of the hues in other actions that I mentioned above. These three get triggered on by GoodMorning automatically based on motion sensor in the morning during a specific time frame (never fails) and it used to go off based on “Off To Work” at a specific time till 2-3 days back. They are pretty near to the ST hub and also has a powered ST 1st gen. motion sensor near it and all the bulbs are in a very close proximity. So, I doubt it is a weak mesh. Anyways, will keep a watch.

Thanks again!

I’ve seen the same thing a couple mornings. I’ll hit the off switch in the app and it’ll pop the lights back on after a couple minutes.

I’ve also seen similar at night, but I think I know the reason for that. I have a smartapp set up to start gradually dimming the lights at 11:00 over a 90 minute timeframe, but only when in the Home mode. If that sequence starts, and then anytime between 11:00 and 12:30 I try to switch to Night mode (all off) or manually turn the lights off, they’ll pop back on when the next timer for dimming triggers. So if you have any dimming done or anything that might be something to check too.

Oh yeah! I have the level to go up to 100% with the good morning action! Let me give it a shot. Thanks!

@jhoff80 Once again I have no explanation for this. I did remove all the dimmer/level settings from hello home actions related to Hues. And strange enough, my GoodMorning which triggers 3 hues in living and one in the family room turned on as expected (which always worked). Then exactly at 7:10 AM, my “Off to Work” action triggered once my wife left for work and well, yeah all the lights turned off as expected and not a single one turned back on.

Coincidence or not, I am thankful to you for the tip. If it works, it “works”. Another change that I made was changed the time from 7:15 AM to 7:10 AM. I have typically noticed when the poll command (?) collides with the Off command, I have seen this weird behavior which may be just a coincidence and well, support explained that to me that it is not related.

The poll request just reaching out to the device for status update a regular interval (depending on the device type) and shouldn’t interfere with any commands. But question here for ST folks then, I do see polling on the hues at regular interval, then how come the status does not get updated if turned on/off from outside of ST.

i am having the exact same issue, however, to narrow down the problem…i only have a hue bloom & a hue lightstrip setup on the hue bridge.

on the st bridge (2nd gen) i am connected to the hue bridge (most recent update) and added the bloom and lightstrip within the st mobile app.

i do not have any rules or processes set within the st app. everything is set to default other than having added the two hue devices.

i am able to control everything on the devices themselves just fine, but if i turn them off…after a few minutes (no set time period…it is random) the devices turn themselves back on.

i also checked out the hue app and see the devices turning themselves back on.

i am at a loss.

i stripped down my whole system trying to find out the problem…and i am not able to figure out what the hell is going on.

either the hue bridge (or app) is telling the devices to turn themselves back on to the last state, or the st bridge (or app) is not communicating properly to tell the hue bridge that the devices are off.

like i said, i am at a loss.

any ideas, anyone?

Do you by chance have any IFTTT recipes that use the Hue channel?

The Hue channel was down for maintenance this week for about two days while they added the ability to control scenes. It’s the first time I can remember the channel being unavailable.

Towards the end of the maintenance period Some of my IFTTT recipes which had been issued but not done anything were apparently still in queue and they fired unexpectedly.

So if you do you have any IFTTT recipes, check their site to see if it shows recipes firing while you were seeing strange things.

Of course if you don’t have IFTTT recipes, the timing is just a coincidence and you need to look for another costs.

zero IFTTT recipes set up are setup.

i have noticed that the devices come back on two minutes after i have turned them off through the ST app.

if i turn off the hue devices from the HUE app…they do NOT come back on.

so something is not telling the hue bridge that the devices are indeed being turned off, and it looks like the hue bridge/app turns them back on to the last state two minutes later (there or there abouts)

That sequence doesn’t really fit the Hue architecture, as requests are always made to the bridge and then the bridge makes the request to the bulbs. So the bridge always knows that the bulbs were turned off. Something has to be asking the bridge to turn them on again. For example, neither echo nor smart things can talk directly to a bulb which is attached to a Hue bridge – – they both have to make the request of the hue bridge.

You can check the recent activity for a bulb on the SmartThings side by doing the following:

  1. Open the SmartThings app

Two) tap on the “my home” icon at the bottom of the page

Three) tap on “things” near the top of the page

  1. scroll down until you see the individual bulb. Now tap on its name (not the icons on each side of the name, just the name itself) and that will open the details page for that bulb.

  2. what’s the details page is open, tap on “recently” at the top of the page and that will show you the individual device log. In the screen capture below, “guestroom SL” is a guestroom smart lighting automation.

  1. you can also tap on “smart apps” at the top of the details page and you will see all of the smart apps that are associated with this particular device.