Can Hubitat set lights to the correct color temperature/brightness as they turn on, or is high-to-low flicker unavoidable?

🛎️ Get Help
1

Hi, I'm a long time Hubitat user who is trying to get automated color temperature and brightness (adaptive lighting) working throughout my home.

As I've been working through this problem I've found that no matter how I automate it, I cannot avoid a flicker of the "old" lighting state before my "current" lighting state is applied. This is largely invisible when dimming from low to high states, however when waking up in the morning and prompting "hey siri turn on my bedside lamp", the lamp turning on at 100% brightness, 5000k momentarily before dimming to 20% 2000k is extremely jarring.

I am using Hue bulbs in this configuration that I've confirmed when setting their color temp (with optional level) directly from the device driver (or hue app) they transition to that desired color/brightness from off, rather than turning on at the previous state.

The core issue appears to be that Hubitat will always honor a command to turn on a light before doing anything else. There is no ability to supersede that intent and rather than just turning on the light, initialize the light to a desired color temperature / brightness. A command to turn on the light will always turn on the light. Then later, after some event dispatch and processing (and after you've been blinded) some automations can set the color temp and brightness that should've delivered to the light as part of the intent to turn on.

I have tried my own automations & apps as well as using the Room Lighting app with variables derived from the Day Lights app. All exhibit the same behavior.

This feature appears to have been implemented as part of the Home Assistant adaptive lighting feature for more than 2 years: https://www.reddit.com/r/homeassistant/comments/15cyf3c/adaptive_lighting_v1180_immediate_light/

Adaptive Lighting will now intercept any light.turn_on call, adjusting the service data before it reaches your lights. This ensures your lights immediately display the correct color, temperature, and brightness.

Are there any plans for a solution to this shortcoming?

2

So you can do what you want from the device detail page of Hubitat? If so, what you're seeing must be an oddity of whatever app you're using to perform your automations on Hubitat -- not the driver. Can you share more information about what that is and the specific configuration where you see this behavior, as well as what specific sequence of commands on the device detail page does what you want?

(Although that does sound surprising, since I'm not sure I've ever gotten it to work that way. The new Hue API does support "prestaging" colors when off, so this might work around that if implemented in the driver, though not many Hubitat apps will know about that so you'd need a rule or custom app to do much; the API apparently just responds as you describe normally, not under control of API consumers without extra commands. But another workaround that does work now is to activate a scene, say one that just contains your light with its desired state, instead of turning on/setting color/etc. the device directly.)

Also, it sounds like you're using the Hue Bridge Integration, presumably the built-in one, but that would be good to confirm as well, as that would certainly make a difference.

1 Like
3

The issue is not strictly with the apps. The problem is that the command to turn the light on is always delivered long (comparatively) before the app processing to set the correct color temp and brightness level. From what I currently understand about the Hubitat system it is impossible to make an app that can solve this problem.

When I prompt "hey siri turn on my bedside lamp", Hubitat will always immediately turn on that light. There is no possible way to intercept that intent to turn on the light and instead send a setColorTemp command that will turn on the light while also using the time-appropriate brightness and color.

This is not using Hue-specific pre-staging. All I'm desiring is substituting the "on" command with a "setColorTemp" command (this also happens to set level and turn on the light). This, like would work with any light that obeys the color temp and brightness provided at the same time the on command.

I am using the built-in Hue Bridge integration.

Using a scenes is not a great workaround at all. It's onerous to either maintain a scene for each device, or to have to group the lights, and to use alternative phrasing with voice assistants.

4

But you made it sound like you could do this from the device detail page:

If you can do it from there, an app could, too. Apps just run the same commands you can run yourself. One of my questions:

was an attempt to figure out what that was for you on the device detail page, and another:

was an attempt to figure out what the app you're using might be doing.

Knowing these answers would still be helpful. I just thought of the fact that it may also be helpful to know if you have the V2 API enabled in the Hue Bridge Integration app, as behavior may differ in the new API.

As for what Hubitat is sending, unless your app is explicitly sending an "on" before the "set color temperature" command (why knowing the above would be helpful), this is likely just an artifact of how the Hue API works, as I mentioned above. Hubitat is just sending something like this over the API, and that is apparently how Hue interprets it if that's what you're seeing and that's all the app is telling the driver to do (this is a "Set Color Temperature" example, assuming V2 API is enabled):

{"on": {"on": true}, "color_temperature": {"mirek": (1000000/your new color temperature)}}

This is all as a single command, sent at once, to Hue. It seems you are making the assumption that this is not how things are already happening, but it certainly is at the driver level. Again, the app you're using would matter, hence my wondering.

The "prestaging" thing I also mentioned above might help with the rest of this, but you'd still need some care with how your app handles it, since this is not standardized (and the "how" could very well be "not at all," so you'd need a rule or other approach as I also mentioned). That sounds like what Home Assistant offers, and there are plans to look at this in the future. However, in the meantime, I'd look at the alternative I offered that already works:

In my experience, Hue does respond by immediately recalling the set state with no visible transition, though it's possible this could vary by device (none of my Hue bulbs do it, though, FWIW).

2 Likes
5

Sorry I should have clarified -

What I can do on the device driver page is, choose, that because this is a light that I want to be "adaptive", that instead of clicking "On" I will use the "Set Color Temperature" widget to define set the desired time-appropriate color temperature and brightness level, and then click "Set". This turns on the light while correctly transitioning to the correct color temp and brightness.

This is what should happen when I say "hey siri turn on my bedside lamp". What an app cannot do is choose what should happen instead of an event being delivered to a device. Apps in Hubitat are only reactive to events (e.g turning on the light), they can't modify an event before it has already been delivered (setting color temp as the substitute to turning on instead of simply turning on as was asked).

I am only running a single command from the device detail page "Set Color Temperature".

I am using the Day Lights and Room Lighting apps as stated in my OP. They subscribe to the "on" event of the lights and then react to it to set the desired color temp & brightness, but by the time they react the light has already been turned on. They would need to be able to run before the "on" event is delivered to the light. If some other app is able to do this somehow, please let me know.

The app sending the "on" event to the device is the Homekit integration, but for the purpose of this discussion it could be any voice assistant or integration that should still follow adaptive lighting rules when turning on a light.

6

OK, thanks, that is helpful!

You'll have a bit of trouble with this with Siri (or any voice assistant), but with an app on the hub, you could just have the app do a "Set Color Temperature" -- instead of an "on" or whatnot (how will depend on your specific app) -- and that would avoid your problem, assuming your lights behave like mine. (I tested this and at least with the V2 API don't see any remnants of previous states.)

Room Lighting can send different color temperatures at different times of day using mode, in-app time periods, or really whatever else you configure however you configure it, if you're using that to turn on the lights. So could a Rule 5.1 rule or custom app, again assuming that is how you're turning them on in the first place. But again, if that's only the voice assistant, you'll probably have problems...

For Siri specifically, since you're using a Hue Bridge, you could integrate it directly to Apple Home that way instead of using Hue to Hubitat to Siri. This is possible via either HomeKit (Bridge V2 only) or Matter (Bridge V2 or Bridge Pro). Both should now support Adaptive Lighting, which I think will do what you want, though I have never played around with this feature myself and can't speak to experience. It would not work well with Hubitat-integrated Hue devices coming from Hubitat but shouldn't have any other effect (and possibly none at all -- I'm not sure if the smarts all live in Home or get sent to Hue) on devices shared to Hubitat as you have them also set up now.

Scenes are still an alternative, as Siri should be able to activate them by voice (easiest with the native Hue/Home integration, but technically possible from Hubitat...), but that might be more awkward than just saying the light name and "on."

Otherwise, it sounds like a "Prestage Color Temperature" (or color, level, etc.) command might help you in the future. Again, that would require something custom but would be pretty easy to do with a rule a few times a day or whatever you had in mind. There's nothing quite like that now, but there are plans to look at this (again -- now that the API supports it, which I think is pretty new) in the future!

2 Likes
7

Another option with more control might be creating virtual lights for siri and then create rules off of the events to change the state of the hue lights.

4 Likes
8

Workarounds like creating a virtual device (or scene) for every light and maintaining individual automations for each are simply not respectful of user time. Carefully naming all those and including the correct devices in integrations is a very notable amount of work for something that Home Assistant had solved transparently to the user two years ago.

The platform is fundamentally unable to man-in-the-middle an event coming out of one app (voice assistant) before it is delivered to a device (the light) without onerous user level indirection workarounds.

I have used the Apple Adaptive Lighting and it worked correctly. However I have non-Hue dimmers and RGB lights (but do not support the new Apple adaptive lighting API) that I also want to participate in my lighting automation. That could not be done in the Homekit domain so I had been doing this within Hubitat.

"Prestage Color Temperature" would be a solution, but even that would only help for lights that will support "Prestage CT" at the device driver level. The current solution within Home Assistant works for devices that will never be updated to support that.

If there are no plans to solve this comprehensively in a manner similar to Home Assistant I will begin planning my move to that platform.

9

So you have more than Hue lights? I am only talking about Hue above, as in, my description is applicable only to them, and even then specifically over the Hue Bridge Integration. Any other kind of device is going to depend on the protocol, driver, and specific quirks of the device.

I read more at the link in your first post, and that's not Home Assistant -- that's a custom integration/component, i.e., user code that is not developed or supported by Home Assistant (in the same way as built-in integrations). This is most analagous to custom code on Hubitat. You could do something similar by re-writing any driver for your devices to "intercept" an "On" command or whatever and do what you want instead (or use a workaround with virtual devices or similar as suggested above without needing to write code), but, like Home Assistant, I'd say this is unlikely to happen on a built-in, platform-wide level in the foreseeable future.

However, I do think a "prestage" command on devices you care about would get you there and not be that much more difficult -- you have to tell the hub what you want somehow, and doing it in a rule action that sends this hypotehtical staging command to the particular devices you care about isn't much harder (just selecting the devices) than what it sounds like any alternative (blindly doing it for all devices that look like lights?) would be, IMHO. But, again, this isn't standardized here (just like it isn't there), and the built-in driver currently does not support this over the Hue Bridge Integration. Some Zigbee lights actually might with the "Advanced..." drivers, at least for certain attributes...

3 Likes
10

Yes it is a custom integration. I mentioned that I was using the custom / community Hubitat Day Lights app in my OP. The topic of this thread has been if it's even possible to write a custom Hubitat app that functions similarly on the topic on power on behavior to the linked Home Assistant equivalent to Day Lights.

You can't surely be saying the "supported" solution would be to write custom drivers for each of your light types? No better than creating scenes for each light, or create virtual devices for each light. The linked Home Assistant component is just a community lighting automation app. It doesn't require custom device drivers.

I am already telling the hub what I want by having the devices configured in Room Lighting / Day Lights with the time-appropriate color temp / brightness. That is why they immediately turn to those values after flashing the wrong state. These values are also exposed in Hub Variables, not that it makes a difference. The problem is Hubitat does not have a mechanism for consulting that configuration before turning on the light.

Unless prestaging was going to be supported on every driver (which it sounds like it won't) it doesn't sound like Hubitat's current architecture will allow for an equivalently robust solution to this problem.

11

With the above being clearer, yes, you don't have a way to listen for commands to devices, just react to events from them (I believe this is what you meant to say before; I'm using Hubitat terminology here to be clear about specifics) in an app. So, a custom driver or an intermediary virtual device plus app where you do have control over the real behavior are two options. A platform-level feature would be an interesting request and probably the way to do this with the least user effort but not one I'd expect soon. I'm struggling to think of any "unofficial" (HACS-esque) way for even a user app to do this right now, but perhaps someone can think of something I'm missing.

But again, any device with the right pre-staging commands could already do this. This will likely come for Hue at some point; I can't speak to whatever other devices you may have. With this feature, you'd just sent the "prestage" to the device throughout the day or whenver you had in mind, and that would affect the behavior of the next "on" (or, usually, change the device if it's already on, device/protocol/driver quirks again making for possible exceptions) -- in your case, it sounds like doing it here instead of your custom app, which I am not familiar with but sounds like it has similar setups. Devices/drivers can't really "read" anything from arbitrary apps, but the "prestaging" approach is more in line with how Hubitat apps and devices normally work.

Hopefully you find something that works for you, no matter what platform (or combination) you land on!

3 Likes
12

I'll ask a seemly obvious question, but when you state this command, what device is Siri acting on? Is the voice assistant acting directly on the Bulbs connected into Apple Home (from Hue Bridge, Matter via Wifi/Thread)? Is Siri acting on a Room Lighting Activator Device or Hue bulb/group that was sent from Hubitat to Apple Home? These answers actually matter quite a bit.

1 Like
13

The bulb is a hue bulb connect to Hubitat through the Hue integration. The bulb is visible to Siri through the Hubitat integration.

The issue is with Hubitat as when the bulb is using Apple Adaptive Lighting it works correctly.

14

Since you are using Day Lights and Room Lighting, do not send the bulb to Apple Home. Try sending a Room Lighting Activator Switch (make sure it is just on/off and not a bulb) to Apple Home. Configure Room Lighting to set the brightness and CT based on Hub Variables that are set by Day Lights (sounds like you are already doing this). Have Siri control the switch that will turn on and off the bulbs. When the switch turns on, the devices in the table should be sent a setColorTemperature/Brightness command with Day Lights taking over.

The other way to try it is via Rule Machine and a Virtual Switch. The Virtual Switch gets sent to Apple Home. Rule is straightforward. When Switch is turned on, your actions can be setColorTemperature (which includes level) and be based on the Hub Variables.

The final Hue specific way would require creating a Hubitat app. Basically, you would create a dummy scene in Hue and bring that into Hubitat via the Built-in integration. This user created app would then update the scene every time your Hub Variables update. You would just turn on the scene (which can be sent into Apple Home as a switch). This would completely eliminate any flash behavior for the Hue bulbs in that scene.

15

As stated earlier in the thread I do not want to solve this by creating virtual devices for every light, or by grouping the lights into scenes.

I don't want my wife and kids to have to learn additional command vocabulary, memorize additional device names, or to understand the scene layout of the house (and that it prevents individual light activation). I want the ability to instruct individual lights to turn on/off, and still have those lights obey the time-appropriate brightness & color temperature.

At the platform level Hubitat cannot resolve this comprehensively (only approximate it with the workarounds described) so I will be planning a move to Home Assistant in the not too distant future. I'm glad I didn't purchase a C8.

16

If this is the case, good luck with Home Assistant. It's important that everyone find an automation system that fits their needs.

Note, you should heed the warning earlier in the thread about their implementation. It comes from the community and is not part of Home Assistant's core. While unlikely, it takes one platform update to break your desired behavior.

1 Like
17

Surely the same could be said of the Hubitat non-core Day Lights app. Granted Hubitat has a very good track record of backwards compatibility, but it's not like Home Assistant's is particularly bad either.

18

That's a weird thing to say.

Obviously, I don't mean rules for each bulb. You have a lot of control. One virtual and then you can use hue zones etc. Set a scene like natural light.

A lot of us male adults are solution focused. A lot of women are also, but let's just say maybe at least a touch over 50% of the people here are going to take a problem and offer solutions. They are not going to primarily consider the emotional weight of the components to get to the solution. It's more of the ends justify the means kind of thing. Not everyone thinks this way.

I have three control systems plus hue. One of them is Josh.ai. I like to be in a room and say turn on the lights. That works for Josh.ai, Control4 and Hubitat controlling hue because I made it do that through configurations. It wasn't hard and I didn't have to write a program. Grouping lights with zones and rooms gets you to the point where you can use simple voice commands. I happen to use control4 adaptive lighting, but hue has scene control that does it as well.

Hubitat and Ha are fun because they give us a lot of creative control. You can also write your own apps etc.

I admit, just like you I am super fussy about my lighting having the transitions I want that please my sensibilities. I totally empathize on your objective. I might suggest it could be worth being open to solutions you might have regected prior. Any of them.

19

Sort of. One thing to remember is the largest difference between the two systems…Home Assistant being open source allows for Adaptive Lighting to serve as a Man in the Middle. Hubitat is paid for product and intentionally sandboxes some stuff. Day Light would never be able to do this unless the developers of Hubitat allow it.

If you are comfortable with this ability, the Home Assistant might be right the product fo you. Not all of us are interested in that. Personally, I use Hue Smart Scenes for this rather than Day Lights, which I used to use extensively.

20

One thing i observed with aotec nano dimmer is, when i read the manual i think it mentioned 10a rated, i had to swap out my LED dimmable downlight for higher power W version to mostly avoid the light flickering during transition. Not sure if this is relevant in your case but though i would mention it