Anyone know how long the polling interval is between Hue and ST. For example if the power is removed or restored to a set of Hue lights by turning off/on a physical switch, how long until the proper status of the lights is reflected in ST ?
Should be instant if you are using a Hue Bridge.
But you’d have to ask @JDRoberts…I’m not familiar with Hue.
If you check your user guide, you will see that the Hue bulbs are intended to always have power.
If you are regularly cutting power to them with a switch that cuts the current, then the inrush current each time the lights are turned back on can damage the radio inside the bulbs over time, making an expensive bulb that much more expensive. 
this isn’t a problem if there’s just an emergency power outage once or twice a year, but you definitely should not use them with a physical switch that cuts the current on a regular basis.
As you noticed, the bulbs also can’t report their status when the power is cut. You have to wait until hue bridge notices that they are “unavailable“ (again, because it expects them to always be on power) and then eventually for that to be made available to other integrations. And even then, it will report them as “unavailable“ rather than as “off,“ because the power cut is not the same thing as the bulb turning itself off.
The method that is used for the official smartthings/hue bridge integration is very different. It checks the “heartbeat log” that the hue bridge keeps for itself, rather than polling the individual bulbs, And it gets the on/off status from there. Which is a good thing because it reduces traffic on the network and it’s also very fast: as noted in the previous post linked to, it’s about every five seconds.
So as long as you are using the bulbs with hue bridge and you are not physically cutting the current to them, but just using normal recommended switches, either the switches from the Hue system like the Hue dimmer switch or perhaps another battery-operated switch or a mains powered accessory switch which is sending a signal to the smartthings hub which then sends the request to the hue bridge, the status should update in just a few seconds.
If you are using a switch, either smart or dumb, which physically cuts current to the bulbs, all bets are off, both as to when the status will be updated and how long the bulb itself will last. 
Didn’t think he meant physical as in wall switch…I assume he meant like a Hue dimmer switch paired to the Hue hub and not to ST. But if you meant like a physical wall switch @gfbuyer, then yeah…that’s a no-no. But if he meant a hue dimmer switch, that would be basically instant (5 seconds) because of heartbeat…correct?
Yes, good point, thanks. 
. If it’s a switch that doesn’t cut the current, then the switch action will be reported to either the hue bridge or the smartthings hub (depending on the specific switch model and network setup), And if it’s to the hue bridge, the status should be updated to smartthings in about five seconds.
2 Likes
This topic is really helpful - thanks!
One more question though…
I’m writing an integration using a WebCore piston that synchronises my Hue lights with some LightwaveRF switches. The piston checks the level of a Hue bulb and switches the Lightwave switch on if the hue level goes above 95% and off if it drops below 95%.
This isn’t really a WebCore question, but here’s the Piston logic for info.
We sometimes use a Hue dimmer switch, which dims the lights gradually if the dim button is held down.
I’m trying to understand whether my Webcore integration will be flooded with events from the Hue dimmer to SmartThings. It appears to get a level every 1-3 seconds and sometimes out of order.
Here is a list of events from my WebCore piston log after holding down the dim button for about 10 seconds. Note that level 44 came in 2 seconds after level 88 and 2 seconds before level 50.
19/01/2021, 11:11:40 Received event [Lounge: Ball].level = 1 with a delay of 50ms
19/01/2021, 11:11:39 Received event [Lounge: Ball].level = 13 with a delay of 45ms
19/01/2021, 11:11:37 Received event [Lounge: Ball].level = 30 with a delay of 49ms
19/01/2021, 11:11:34 Received event [Lounge: Ball].level = 50 with a delay of 47ms
19/01/2021, 11:11:32 Received event [Lounge: Ball].level = 44 with a delay of 36ms
19/01/2021, 11:11:30 Received event [Lounge: Ball].level = 88 with a delay of 46ms
Does anyone know what’s going on here? Can the message frequency be controlled in any way?