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