Surely this pre-staging / transition issue could be resolved using service calls that include the colour and brightness data…? I’m not good with template stuff and haven’t played with variables yet but I’m thinking something along these lines:
You are assuming that turn on command is sent from HA.
This approach cannot be applied if light is being turned on with use of external switch (hue switch, smart wall-switch etc).
I’d suggest solving this with a dummy light entity that is always keeping track of CL and only forwarding payload to real light once it turns on. However, when turning on a light that was previously using some different settings than CL, a flickering would occur regardless of the settings (this might be reduced by turning light off from brightness level set at 1 as it would turn on at the same brightness level, as I suggested, but flickering won’t go away).
OP suggests changing light properties offline, so that light.turn_on command would already turn the light to the desired values without any of the brightness, xy_color or color_temp commands in service calls. Sending any light property alongside with light.turn_on would first make the light to turn on, then change to the desired property. which doesn’t work.
@Petrica Sorry I don’t understand much of what you are saying…I’ve only started with home assistant.
I just had a different thought, though: what about using scenes somehow? Scenes within the hue app seem to have the ability to turn on a light with the desired value without transition/flickering.
So adaptive lighting would somehow need the ability to write the constant changes into a scene…
I haven’t played with Hue scenes much thus I couldn’t say if it would work. However, since it would require communication back and forth between HA and Hue hub (in order to dynamically change scene based on the CL values) I guess it would be easier to just setup sensors with CL values or a dummy light (ie. MQTT light is very easy to set) for which CL would always apply and then turn the real light on with the properties of the dummy light (this dummy light would not be used in frontend in order to prevent it from turning on).
In this way an automation could link a PIR motion sensor to the real light and turn it on using the brightness and CT of the dummy light/CT sensor values however when using wall switch/handheld remote/HA frontend to turn the light on there would be a different automation that would turn the light normally, without affecting CL or the dummy light.
Use case scenario 1: both motion sensor and switch (or switches) in the room control the same light. If motion sensor is triggered, light turns on and CL is applied with the correct values. If switch is pressed the light turns on without CL. Or, if multiple switches in the room: one switch (ie. on the coffee table) would apply CL to lights if pressed but the wall switch would not, etc.
Use case scenario 2: both motion sensor and switch control the same light with CL independent of trigger;
Use case scenario 3: both motion sensor and switch control the same light with CL independent of trigger; however, using Google Home/Alexa/HA frontend would result in full manual control of lights and CL would not be used.
Any chance you might share your work/achievement with us? I would really love to use adaptive lighting without the transition effect. Almost all the lights I use are philips hue lights…
I have plans to, but it’s a bit of work to write-up. It’s really easy if you’re familiar with the Hue API, but to write it for anyone to be able to get it working it’s going to take a while and I don’t have a lot of free time right now.
When using light_ct:
for all my lights , will circadian use rgb , brightness, colortemp etc to change lighting , or do i need to add Lights_rgb,lights_brightness for them all ?
Ikea Trådfri (non-rgb) bulb brightness values 1 - 100 corresponds to 50% - 100% actual brightness. You can’t dim them down to 10% or 1%. So at bedtime the bulbs are at 75% brightness, and at midnight at 50%.
What can I do to make them follow the proper brightness curve as far down as it goes, then remain there until it picks up again in the morning?
I think this isn’t a problem of CL, but that of the bulbs API - but this seems like the right place to ask.
@claytonjn would be possible to implement a dynamic sunset/sunrise time, based on a sensor state, so I could set the sunrise to 10 minutes (for exemple) before of my alarm (each day I set it to a diferent time)?
Is there any option/way to extend a time of minimum brightness?
I mean, lights nicely dimms during evening but then immediately after midnight they starting to brighten up. So for example at 3am those are significantly brighter. At moment of sunrise brightness is on 100%
I would like to start the brightness transition around sunrise.
Does it make sense?
Unfortunately you are not right. See the second post of this thread or any other with graphs representing colour and brightness change.
But indeed it is good question. Why lighs are not starting to brighten when sunrise is starting?
I’ve seen the same in adaptive lighting HA component. So obviously there must be reasons for that. But it seems to be different to what Internet says
Intensity tuning is the most familiar and cost-effective solution to circadian lighting. Fixtures maintain a fixed correlated color temperature (CCT) while the intensity (brightness) of the fixture is adjusted, through a controlled dimming system, to correlate with time of day. Light fixtures are set to a lower intensity in the early morning, transition to a higher intensity as the day progresses, and reduce to a lower intensity in the evening
From graphs presented on this component page, it seems its behaviour is exactly the same. So at sunrise, light intensity reaches maximum.
I’m not trying to argue about interpretation.
But it is not comfortable to have lights set to very bright (more than 50%) at 3 am. Personally I found it invalid. And seems I’m not alone judging after your the first response.
One would suggest to use sleep mode, but… afaik it uses lamps built-in transition feature for smooth alteration between it and light generated by circadian sensor. It causes a lot of issues, not supporting long time periods, resetting by turning on/off the lights etc. Is it implemented the same way in adaptive light? Don’t know because no examples covering this feature. Maybe it’s rendered into the sensor. Maybe not.
Thank you. Just asking if am I missing something, or trying to get reasons or possible future features which could meet my requirements,
If found nothing I will write something fit my needs obviously.