New Hue delay

[RLDreams (Really Living the Dream)]

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

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

[a4refillpad (Wayne)]

@2l82try1

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.

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

[a4refillpad (Wayne)]

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

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.

[JDRoberts]

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

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.

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.

[Jonny_Wilson]

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!!

[JDRoberts]

@Jonny_Wilson

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.

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.

Hue Motion Sensors FCC-approved; coming October 2, 2016 (US), October 4, 2016 (UK)

This one is really interesting. As we mentioned before, anything in the US which uses radiofrequency has to have an FCC license. And those licenses typically are granted several months before the company even acknowledges that it’s working on a device. Time to market can vary a lot after the FCC license is granted. The Logitech Harmony hub extender, for example, had its license about a year before it finally got to market. Sometimes the FCC license is the very last thing needed, and the device shows up about a month later. So that part you can’t predict until The manufacturer actually starts talking about the device, and not always then. ( The FCC license materials for the smartthings V2 hub included the Bluetooth antenna which has yet to be turned on almost a year after the product star…

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.

[posborne (Paul Osborne)]

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.

[Zoey (Ben)]

Glad to hear that ST is working on it!

[JDRoberts]

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).

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.

[posborne (Paul Osborne)]

@JDRoberts

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.

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.

[Chris_Nelson]

Thanks for the update paul

[SLKDK]

I really appreciate that SmartThings is acknowledge the problem and is working on a solution. Still scary though, that this hasn’t been caught in some QA.

Could we get some kind of timeline on this?

[a4refillpad (Wayne)]

Great news that you’ve been able to recreate. If the fix is challenging, could some if us get on a firmware with reduced polling or an adjustable value? I’m really getting serious flack from the WAF especially as we had guests round and the whole lighting system was going crazy. Seriously embarrassing.

It’s so bad that my smartthings experiment might have to come to an abrupt end if I cannot stabilise this.

[a4refillpad (Wayne)]

@JDRoberts

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.

You’re right again, of course.
Just a thought, if it’s all local then do we know what’s preventing rules in smart lighting app using hue lights from running locally?

[Rich_Byett]

First post in the forums and I’m glad i’m not the only one experiencing problems with the ST / Hue integration. I have had issues over the past couple of weeks where the Hue Hub appears offline in the ST app, but i can control lights through the Hue app. Only way to correct was to reboot the ST hub. Since the latest updates there has been a noticeable delay in the lights responding to commands from ST, whether through a routine or smartapp. I have 1 Tap connected, and a total of 11 bulbs / lightstrips. Glad to hear a fix might be on the way

[Jonny_Wilson]

I’ve killed ST, removed my Smart Apps and the link to Hue and the lights are now instant! When can we expect a fix for this?

I’ve preordered my hue PIR sensors for 4th October 2016. I can’t have this happening when I have young kids relying on auto-sensing lights at night.

[Chris_Nelson]

It’s just a waiting game now and hope they fix it.

[JDRoberts]

@a4refillpad

@JDRoberts

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.

You’re right again, of course.
Just a thought, if it’s all local then do we know what’s preventing rules in smart lighting app using hue lights from running locally?

It’s not all local, but it’s local messaging to the hue bridge and code running in the SmartThings cloud. Nothing running in the Phillips cloud.

I don’t know why a SmartLights automation that includes a Phillips hue bulb has to run in the SmartThings cloud rather than local in the current architecture. But it seems like that’s true for anything which isn’t a zwave or zigbee device. Maybe the message management is just too complex for the hub software as currently designed?

[a4refillpad (Wayne)]

It’s a shame, if it were all local maybe we’d see faster responses even when it’s working normally.

[2l82try1 (Jay)]

How does harmony to hue achieve an almost instant status then? Also without effecting the user experience? I just did another test, I unplugged my ST hub from my network, opened the hue app on my wifes phone and the harmony app on mine. Turnng on a light on either results in a status update of 1-2 sec from either app. Now throw ST back on the network doing the same test and the status update is taking 10-12 sec. This is very annoying that its effecting my direct harmony to hue integration. I specifically set those two up together to get instant control of my living room lamps with my harmony remote. Now that is all lost and my WAF is going down. My wife absolutely loves using the remote to set the lamps when she watching tv, reading, using the computer, etc. Hope you guys get this resolved ASAP.