Hello! I have a basic automation set up for a Lifx 15" Ceiling Light, which adjusts the brightness when a motion sensor detects I’m in the room or not. Below is the “fade out” version, which lowers brightness when I leave the room. I have an otherwise identical, but inverted “fade in”.
alias: Kitchen Light Fade Out
description: ""
triggers:
- trigger: state
entity_id:
- binary_sensor.casa_de_bun_weather_control_motion
from: "on"
to: "off"
conditions: []
actions:
- action: light.turn_on
metadata: {}
data:
brightness_pct: 10
transition: 5
target:
device_id: 49eabf9d5db581667dc24c7b4b9bcaf0
mode: single
So far, this is working great, however I have the idle mode of the light to be an effect_morph with a custom palette. When the automation runs, it snaps to the closest solid color and disables the effect. I can only seem to be able to set the palette via the Lifx app. In the HA Automation UI at least, I see an option for effect, which lets me specify effect_morph, which works but uses the default rainbow colors. I don’t quite understand the formatting required to add my custom color palette to it. I’ve read the documentation for the Lifx integration and it seems like this should be possible, but I’m still relatively new to HA and the examples are pretty barebones for Lifx integration, and assume quite lot of prior knowledge on how to manually write HA-compatible YAML.
Any assistance or examples would be greatly appreciated!
Thanks! That helped get me a little bit closer, I see now that there’s an explicit “LIFX: Morph Effect” action which gives me some parameters to adjust that the normal light.turn_on didn’t, but that formatting from the documentation doesn’t seem to be working. It just kinda botches the formatting and doesn’t work, resulting in the palette entered in as:
No errors in logs, manually running the action claims “Action run successfully” but there is no change on the device. I can still control the device from basic controls on a dashboard (i.e. brightness and turning it on/off), so it’s still active and responding fine in that sense.
Yes, 100% sure that’s the correct light. Other automations target that entity ID and work just fine, such as simply turning it on/off or adjusting the brightness. The brightness is the only parameter that I want to adjust, but if you send only a brightness change, it cancels the current effect on the device, which I don’t want.
Providing the full automation just in case something looks off there, but it all looks fine and I see the event firing when it should be based on the conditions, it just doesn’t actually do anything to the light.
Unsure if it’s helpful, but here’s the UI for the automation page on the action details. Even if I build from scratch, using only the UI, selecting a theme, it doesn’t do anything on the light. The resulting YAML letting the UI build it matches exactly to what’s already been posted, so I’ll save the characters in the post.
Ok, I’ve been doing some experimenting, and I think I might have stumbled on a clue. It seems that once an effect is applied, you seemingly cannot change or modify that effect. You have to call effect_stop first, and then apply the new effect. If I manually set the light to just a solid color, and then invoke the automation, the palette seems to work partially. The colors are being set correctly, but the brightness part of the palette does not seem to do anything.
Seems like there’s something a bit more complicated going on than it first seemed.
Ultimately, the goal here is simply to fade the brightness up and down without canceling the effect. I can do this manually without any issues from the light entity card, but trying to do it with an automation piece is being very finnicky
EDIT: On a whim, I decided to just add both the light.turn_on action and the lifx.morph_effect as part of the automation. It seems having both in the same automation lets the brightness adjust properly without resetting the effect.
Still very, very odd what was going on, but at least I have a workaround in the meantime.
@tom_l happy to be pinged, so no apologies necessary.
@Fenrirthviti as you’ve discovered, you can’t adjust the effect settings mid-effect: the firmware ignores any attempt to “start” an effect if that effect is already running. You have to stop the effect first, then restart it with a different palette or theme.
I just tested the lifx.effect_morph action locally using the following YAML and it does seem to be applying the appropriate brightness for each colour:
The only advice I can provide is to change your kelvin value to 3500 which is the default white LED color and acts as a “neutral” value when saturation is greater than zero. I tried your palette with that value and it worked for me.
Finally, Home Assistant will provide a single brightness value that is probably a hallucination (my new favourite euphemism for “lie”) when there are multiple actual brightness values applied across multiple zones.
I’ve experimented with several different ways surface individual zone colors via the Home Assistant UI and none of them are practical given the current core integration constraints and the zone counts in modern LIFX multizone and matrix lights.
Having said that, it just occurred to me while writing this reply that I could leverage the fact that actions can now provide feedback and create a lifx.get_state action that provides the current state of each zone as a response when called. If that’s something you’d find useful, it would be super peachy keen if you’d open a feature request on GitHub for it: home-assistant · Discussions · GitHub
Thank you for the additional context! I tested calling an effect_stop before applying the new morph_effect, but that lead to flickering in the light. What ultimately ended up working with the desired end result for me was this:
For whatever reason, the light.turn_on action by itself would always reset the effect back to none/solid color. Pairing both in the same automation seems to be working perfectly as I expect it to, and several triggers of both the fade up/fade down automation I have are continuing to work correctly. Why calling the action that is not expected to work first is required is anyone’s guess at this point.
As for the lifx.get_state request, I think having some tangible feedback when an action is run that isn’t expected to actually work (i.e. calling a morph_effect when one already exists) would have saved quite a bit of confusion in this case, so I definitely see the value even though my specific use case is solved for the moment. I’ll leave the tab open and try to get around to posting that with context on why it’s useful as soon as I have time to put those thoughts down.
I’d be curious to know if changing that light.turn_on action to a lifx.set_state action would achieve the same result or not. Either way, I’m glad you have something working for you.
Looks like it does. I wasn’t aware that brightness_pct was a valid option, and the UI for the set_state action doesn’t imply it accepts additional parameters, so I hadn’t looked further. I did see in the documentation it claimed to support all the normal light_on parameters, but since the UI didn’t provide a place to put them I just trusted that the integration knew better than I did, heh. For reference:
The UI provides a bunch of targeting options, but doesn’t really offer or show any options to do something. I had written this off because of that, and didn’t bother to look further. Once I manually edit the YAML file to include brightness_pct, the entire “template” UI just goes away and it shows me the raw YAML, but seems to work fine.
Since this approach is likely to be more reliable than the hacky way I had it set before, I’ll just use this going forward.
Should I make a second request for the LIFX integration regarding the UI for set_state to be updated to show the parameters it can handle, or would this be considered a bug as it doesn’t match the docs?
You can, sure. I suspect it may have been either a limitation or an efficiency when the integration was first developed to just use the existing light.turn_on fields but perhaps they couldn’t surface them. I think we can now, but I won’t know until I try and having a bug report ia good motivation to do so.
