I see what youâre saying. If I use a group, I have to wait 6 seconds before I can press a button again to level up/down, otherwise the next press does nothing and forces me to wait another 6 seconds.
However, when I select each of the individual lights in that same group and not the group itself, then I can rapid-fire click the button and the lights will level up/down with almost no pause between levels. This is so much faster than the Node.js setup was!
I have not seen this to be the case. I also have a circadian app running on ST that updates color temp throughout the day. I had to set it up to only adjust the color temp of lights that were already on, because updating attributes of lights that were off would turn them on.
I also just tried this out in the ST app; updating an attribute there will also cause a light to turn on.
We'd love to have near instant reporting as well. But hue bridge api doesn't support any change notification. So polling is the only option. You can create a rule to do a refresh more aggressively if you want to overcome our default refresh poll.
Itâs been requested literally hundreds of times over the last 4 years. Philips is completely uninterested in supporting push notifications. RaspBee is listed as an alternative though, here:. Reacting to tap switches | Page 3 | Philips Hue API
We could likely have a great debate on this, but yes changing a bulb attribute will turn it on.
I have not seen this to be the case. I also have a circadian app running on ST that updates color temp throughout the day. I had to set it up to only adjust the color temp of lights that were already on, because updating attributes of lights that were off would turn them on.
That's odd, let me investigate further then. Thanks for your responses.
Cause the same logic seems to work fine on ST and not on Hubitat. So I assumed this may have been the issue.
@jason0x43 Could you please confirm if you were using just the device screen or some app like webCoRE/grrovy code to change the bulb temperature?
That was my understanding as well, but I can't imagine ST is polling as fast as they'd need to for the app to update so quickly. I mean, I consistently see the ST app update light states within 1 second of changing them in the Hue app. It'd be interesting to know what they're doing.
Instant Hue state updates aren't (currently) a huge issue for me, I just noticed the discrepancy between the ST's Hue implementation and Hubitat's, and wondered if maybe I was missing something.
For my "just tried this out in the ST app" statement, I was using the ST device screen for a Hue light.
Yes, the group updates route through the bridge and therefore don't refresh until the next polling cycle, there maybe a way to change that.
I just tested it in my ST app and can confirm that the temperature or saturation changes does not turn on the light.
However, it may be worth noting that I am not using the default Hue Bulb Device Handler. I am using the one linked below.
However, as Mike suggested, the implementation is debatable and could have supporters for both approaches. I'll try to tweak my logic to work-around this at the moment.
Most likely the app is caching the changes and then sending them as commands when you do turn the light on. To test, change the color temp in the app, then shut down the hub and turn on the light manually. My bet is itâll still be the old temperature.
This is what HomeKit does. I can change the color of a light while itâs off, but when I turn it on, with HomeKit or with something else, the light is at whatever color it was the last time it was actually on.
Well, I guess thatâs not actually what you were describing, because HomeKit isnât sending along the color change command later. Itâs just lost.
You are right, I just tested as you suggested and also did some digging around in the handler.
The temperature changes are only applied when the lamp us turned on the next time.
Thanks! That clears my query and I expect Hubitat would continue with its current implementation too then.
You could try to adapt that app for use with Hubitat. What exactly that entails I really have no idea, but good luck anyway. 
Ok, now they're more of an issue. I wrote a simple "circadian" app to gradual shift the color temp of my Hue lights throughout the day. Not all my lights are on all the time, though, so I have it subscribe to 'switch.on' events from all the Hue's it's managing. When a light comes on, the app updates its color to the proper value for the current time. Generally I use Alexa when I need to turn lights on or off. With the slow refresh, I've seen it take from 5 to 30 seconds between when a light comes on and when it's color is updated.
Are you using Alexa directly with the lights or using Hubitat as the link? I suspect if you use Alexa -> Hubitat -> Hue then the commands will pass through when the lights turn on.
I wondered about that. HmmmâŚcan I force Alexa to ignore my Hue hub and only consider devices from Hubitat?
I could remove the Hue integration from Alexa, but I thought I saw something about Hubitatâs Alexa integration working by having it masquerade as a Hue hub, or something to that effect.
Sure. Youâll just have to delete the hub from its devices. Not exactly sure how, though. Iâm a Google assistant guy. (Love to see that integrated, personally)
I ended up having to use the Hue hubâs API to delete the Alexa user so the Echo would stop hitting the hub directly, but overall this seems to work well. Light control is just as snappy as before, and of course Hubitat sees the updates immediately. As is mentioned somewhere else, Alexa currently only sees lights shared by Hubitat as dimmable (rather than color or color temp controllable), but thatâs fine in this case since another app is managing the color setting.
Is there way to implement Colorloop on/off into DH?
Download the Hubitat app
