New Hue delay

I have this exact same problem. The last 2 years have been fantastic however in the last 2 days I’m seeing a delay of up to 5-6 seconds before the lights turn on. I haven’t changed a thing so I reckon it’s to do with the latest firmware update to smartthings hub. Is there a fix?

2 Likes

No fix right now, I would encourage as many people as possible raise tickets to help prioritise the engineers so they put some focus on this.

1 Like

So it’s not just me then…my lights have been acting up as well. Is there a specific place that we notify ST, or is it just the “Support” email from the main page of ST?

The delay through Alexa is horrible, and the app is the same way.

In the US:

In the U.K.:

Sent…Cheers mate!

1 Like

The status page has been updated as well.
http://status.smartthings.com

I also got a support email back asking to me reboot all hubs and check that the firmware is up to date. If all else fails to remove and readd the hue connect app. I’ve already done the first before I contacted support and the latter Id rather not, thx but no thx.

Might be able to blame this one on Hue not entirely on ST. Seeing a major delay controlling Hue bulbs with even the Hue native app.

You never know for sure. There could be a lot of things involved. But there have definitely been community members posting who find if they take their smartthings hub off power the delay for the Hues goes away. Put the hub back on power, the delay comes back.

That’s not to say you aren’t seeing something different which is affecting your Hues independently. Just to say that there is a problem with the SmartThings/hue integration for some accounts.

1 Like

Oh I completely agree on a definite issue between ST & Hue. Just noting that this current delay , might not be entirely on ST. :wink:

I just got another Hue update today, and since then Hue have been slow, both the ones triggered from ST & the ones I controlled directly from Hue

1 Like

You’re right don’t do it!!! I have already and firstly it was a world of pain and secondly made no flipping difference.

2 Likes

Could be Philips not liking the massive increase in polling frequency from smartthings. I hope smartthings made the changes with their blessing and what we’re seeing isn’t Philips protecting their service.

2 Likes

Philips shouldn’t see it at all. It’s not a cloud to cloud integration. It’s just the ST hub knocking on the door of the hue bridge locally. It’s the local device being tied up, not a cloud service.

1 Like

I’ve been going nuts with hue, what I’m experiencing is what others here are seeing. This is unacceptable for ST. I’ll be glad when the hue motion sensors arrive next month.

Sort your sh*t out SmartThings. This is appalling!!

Hue motion sensors now up for pre-order on Amazon.com for the US and Amazon.co.UK for the UK, both say release the first week of October. :sunglasses:

edited for clarity: we still don’t know whether the new Hue motion sensors will be visible to SmartThings or not. It could end up being a parallel means of control, like the Hue dimmer switch or the Hue tap. That is, SmartThings would know if a bulb attached to the bridge came on that had been triggered by the motion sensor, but it wouldn’t know anything about the motion sensor itself. That will still work for my purposes, but it’s just not yet clear whether the Hue motion sensors could be used to trigger other SmartThings events. We’all just have to wait-and-see.

Hey all, we’re investigating this now and have been able to reproduce the issue. We are definitely polling more frequently with the 0.15.x firmware (local polling not driven directly by the cloud) and that does seem like a promising theory for part of what might be causing the increased latency. Polling is the only option currently available for determining that there has been a change to the state of devices connected to the Hue bridge (we would love if there were a more efficient mechanism available).

This feature was primarily developed/tested prior to the latest Hue firmware release (released late July according to notes), so we are also investigating whether this issue might be partially related to that update. I have been able to test on one bridge with the older firmware and the latency does not appear to be present.

4 Likes

Glad to hear that ST is working on it!

Paul, you’re doing a heartbeat check with the bridge, right? Not individual polling? I was a little surprised to read earlier that that was set at five second intervals, as I thought Phillips was recommending a minimum of 15, but maybe that’s changed.

3 Likes

The poll queries the state of all bulbs (single HTTP request for all lights) and does a hash comparison to determine if the returned state has changed since the last poll. If it has, we bubble that up to the cloud so the updated state is accurately reflected in the ST system. Although there is a moderate amount of traffic (up to ~20K bytes depending on how many bulbs), I would not expect this to tax the bridge terribly (the state should be cached); it has not for previous firmwares. The issue appears to be independent of the number of bulbs (I have reproduced the problem on a bridge with as few as 3 lights).

I’ve got a few more theories to test out. We’ll try to keep you all appraised as we learn more. Obviously, we all want this integration to work well.

5 Likes

Thanks for the update paul