The current polling rate is set internally, there's a few tweaks we want to make in discovery, so we can look at providing a user option in the app/driver (where ever it makes sense) to allow some user configurable options.
Ah, it does appear that refreshing a single Hue bulb updates the status of all of them, so that will work for now.
Are bulbs faster through the bridge? I have delays between bulbs, say I have a lamp with 3 bulbs, well I have 2 lamps in particular with 3 bulbs a piece, when I turn on the lights, 1 bulb at a time comes on, it takes a good 5-6 second for them all to register. When I use the osram hub its completely instant for everything everywhere. But I cannot use osram. So if I pick up a hue bridge, will it be faster?
if you setup the three bulbs in a group on Hue, then manage the group in HE, then yes.
2 Likes
It should be fast even if you don't manage them via Hue Groups. I have button controller setup to each bulb in a three bulb fixture, rather than a group and it still controls them all at once, very smoothly.
@mike.maxwell are you aware if any more progress has been made with regards "scenes" being added to the HE integration?
There has not been any work done on that.
Bummer, I use hue lighting in my Home Theater and love to use slower transition times which using scenes allows me to do. I believe there was also a possibility that adjusting transition time in the hue integration driver might be added as it is supported by the API?
I know it's not what you're asking for, but Hue Scenes are natively supported by Google Assistant. So you could use Assistant Relay to get what you want.
Hadn't thought of that, might give it a try to see how it works out.
1 Like
When I first tested the feature, I used Hue as my benchmark. It was about a 2 second delay to turn a light on or off. Acceptable for a slow scene change I think.
Indeed I think it would be acceptable. I just created a custom scene using all-4-hue (Android app), but I don't see it reflecting in the assistant home-control section. I'm assuming the scene must be created using the stock hue app to show up in assistant? If so, I don't believe the stock app allows for transition time modifications?
Hmmm, so you're not able to normally activate that scene by voice? I would have thought anything you can activate by voice would work with the [CC] option as well. 
You can do it with the Hue Labs "Scene playlist"
Does ST really use polling? This thread, including a comment by @JDRoberts, suggests otherwise: Hue Lights Refresh/Status - Do you schedule poll under 5 minutes? - #2 by JDRoberts - Devices & Integrations - SmartThings Community
Speficially:
JDRoberts:
The official integration already gets the heartbeat status from the hue bridge about every five seconds. That change was put into effect a few months ago [note: written in January 2017]. So you should no longer need to do any individual polling [...]
Heartbeat status is a special option available through the Hue API which doesn’t require individual polling of the hue bulbs and so is intended to allow for smooth operation. What happens is that the bridge writes a copy of every command that it sends to the bulbs into the heartbeat log and then that’s what is sent in response to the SmartThings’ request for status.
Would the same option be available to Hubitat? I notice refreshes seemed to be a bit faster in ST. I tried a third-party Hue integration and noticed an unfortunate delay--noticeable for me because most of my lights are Hue and lights are my favorite automations, and my custom (Smart)app that saves and restores light states did not work as reliably with that integration. (Hue didn't run locally on ST until the last few months, and I can't imagine they'd voluntarily ask their servers to command the hubs to poll so frequently.) I'm noticing some issues on Hubitat now too, though I don't recall them existing before and I haven't seen any notes about the Hue integration changing, so I'll check for bugs before blaming my problems in slow refreshes. 
But it still might be worth looking into this possibility.
Based on behavior I've observed, I believe Hubitat is already using the heartbeat endpoint, just not very frequently. Say you have 2 bulbs, A and B. When you change A's state outside of Hubitat (e.g., with the Hue app) and refresh B in Hubitat, you'll see that A's state updates in Hubitat immediately. That indicates that Hubitat is using the heartbeat endpoint to refresh a Hue bulb's status rather than requesting the status for just a single bulb.
Given that refreshing one bulb refreshes all of them, I had been dealing with the slow status updates with a periodic RM trigger that refreshed a single one of my Hue's every 5 seconds. However, since second-level periodic triggers have been removed, we'll need to do something else.
Oh, never mind, with the latest Hubitat update it looks like my 5 second rule (haha) works again.
There is no heartbeat endpoint in the REST API. The Hue SDK just creates a cache and updates the backend via polling to the bridge on a regular frequency.
And yes, because of the way the API works, we get all bulb statuses on poll, so no need to poll or refresh more than one bulb.
Ah. I consider the /lights resource (in more recent versions of the API) to be the "heartbeat endpoint" since that's what the Hue apps hit every couple of seconds to get the status of all the lights. Once upon a time there was no aggregate endpoint; the /lights endpoint only returned the light names and IDs, which was rather less useful.
Request: Enable Hue Groups to work in the Alexa skill. Currently one has to create a Hubitat Group that includes the Hue Group to get the grouped lights to Alexa. Thanks
