One option to adjust temp and color would be to create a rule that runs before your wake time that sets those presets to the values you want on power up.
I have a rule that resets all bulbs to 100% brightness at 10am daily but the lights do not power on at that point.
Unfortunately, it is not possible to preset brightness or color temperature on a Hue bulb without it also turning on.
So I'd need to have all my hue bulbs flash on at once to do the update like you're described.
This is an approach I use for our Hue vanity lights on a Hue Hub. The Picos are not an The Hue hub. The results are quite satisfying.
You can set color and set level with Hubitat without turning on the bulbs.
Level preset and color preset. My recollection is that was not available for all bulbs from all manufacturers. It's been a while since I've set up any new ones so that may have changed.
This is for Hue as Hue is the scope of the thread.
how so? when setting color temperature or level from the bulb driver page in Hubitat the device always turns on.
I checked the relevant Hue documentation for the underlying event in the Hue Hub API and it indeed mentions that any adjustment of CT or Level implicitly has a "on" event attached as well.
Just thinking out loud here but have you tried pairing a Hue Bulb directly to the HE hub instead of the Hue Hub and using the Hue integration? I used to have a couple of Hue Color Bulbs directly paired to HE and if I remember right, I could pre stage the color before turning it on but not 100% sure about this.
Would not hurt to try because this might just be an API limitation and not a buld limitation.
This isn't completely correct. If you send the command via APIv2, you can send the color temperature with the command off. @bertabcd1234 actually posted earlier how it works with on command:
You would just tweak the command to be off instead of on.
With the above said, for Hue bulbs on a Hue Bridge, the "better" way is to create a generic scene. Then use Hubitat to update that scene with CT/Brightness as Day Lights progresses. When you are ready to run your automations, you just turn on the scene. The bulbs all respond at the same time and then Day Lights takes over.
I know this isn't what you want since you want a Man-in-the-Middle approach that Hubitat does not provide, but these are both ways to make it work (at least in a Hubitat environment).
2 Likes
Interesting I will have to see if a Hue bulb integrated through Home Assistant or directly to Hubitat has prestaging. This would get me closer to my goal and may end up using it as a short term solution. Long-term I'm still pursuing a move to a HA based solution since I believe "command handling" to allow applications to customize incoming commands is a very desirable feature, particularly for device that behave differently than normal.
e.g all the weird LiFX behavior in DayLights could instead live in a custom LiFX command fixing app, and DayLights could focus on what it's good at instead of per-device fixes.
It's interesting since the SmartThings platform had command handling in some form based on a thread I found here: subscribeToCommand? Listening for deviceNotification() on a childDevice Can't confidently say that the SmartThings implementation would have allowed a fix, but it's disappointing that Hubitat opted not to included it when forking ST APIs.
There are always unspoken caveats with these workarounds like scenes.
If I have Day Lights (or whatever automation) controlling a Hue Scene, it will always be controlling all the lights in that scene. I wouldn't have the ability to override the dimming on a handful of the lights within the scene, as soon as Day Lights ran next, those lights would snap back to the Day Lights controlled state. If I could use scenes without losing granularity of control I would.
