Add ancillary data parameters to the light.turn_off service

Feature Requests
1

Hi there,

The light.turn_on service takes parameters that the light.turn_off service does not take. One example is “color_name”.

Put simply, my intention behind this feature request is to advocate for the addition of those parameters in the light.turn_off service for parity.

My use case is below. I should also note that it is entirely possible I am missing something incredibly basic, and if that is the case, I apologize for wasting the community’s time.

  • I have a light blueprint that I wrote for myself that controls all the lights in the house, used by 20 or so automation.
  • The blueprint binds a binary template sensor, a light entity, and a timer.
  • There are custom attributes defined on the binary sensor that indicate color value and brightness. The state of the template sensor is used to determine if the light should be on or off.

So, here’s the use case I am struggling with. The blueprint has triggers for both attribute changes as well as state changes, and operates in a “single” mode.

I have lights behind my bed’s headboard that are on at 100% brightness in a warm-ish color tone. When we start going to sleep, the goal is for the lights to fade down from 100% brightness to 0, as well as the color to change to red, simultaneously - simulating a sunset. I am using a transition value of 600 (10 minutes) for this operation today.

However, since the light.turn_off service doesn’t support a color parameter, the only way to implement this (I think) would be to call light.turn_on with a brightness value of 1, transition of 600, and color of red. Once complete, turn the light off.

That’s a bit hacky and it’d be cleaner if I could pass a color in the light.turn_off service.

I am not sure whether different light firmware’s support this or not, so that might be a good reason not to do this FR.

I know that some lights support the “transition” field and some don’t, so obviously if we did do this it might be the case that only some lights support it.

The key here IMHO is that because the “transition” property can be passed to the light.turn_off service, it implies it’s possible it is not necessarily an immediate turn off, but rather a mutation of the light’s state over a period of time, defined by the value of the transition field.

You can mutate the brightness in this way, so why not the color, as well?

From a semantics perspective, I am struggling with the mode of the blueprint. I believe once the light receives the first command, it effectively ignores subsequent commands during the transition period, so it’s a bit challenging.

Again I could be missing something very basic here!

Please let me know if anyone needs the blueprint code or template sensor code, but hopefully it’s clear.

Thanks!
Matt

2

I think you might be over complicating this. If you pass a brightness of 0 to the light, that is the exact same as calling the light.turn_off service.

Some lights do ignore commands during transition and that’s usually baked into the firmware of the light.

1 Like
3

Add code that once the light gets to 10% it interrupts whatever and shuts off. It’s basically off anyway, but just fire the off service at 10%. You could pick a different percent if that don’t work. Bake it into your BP.
It’s a {FR} I guess but not something that is likely to change, adding parameters to the off service. Just being honest. There is very limited use and for the limited use a template similar to what you have would be the answer.

2 Likes
4

@code-in-progress thank you Bill, I appreciate your reply and I will admit that what you wrote is indeed similar to what I suspected the answer would be. I figured I’d raise the ticket to discuss it.

I’ll try that now, modifying the blueprint to do that and report back here. If that works successfully (which I suspect it will) I’ll close this FR as NTBI.

@Sir_Goodenough thank you for the answer, appreciate the reply. I concur it is not likely.

Part of me feels that adding them would be an elegant way to handle it, and bring parity, but I do concede the use of “transition” when turning off is probably not very common.

Thanks so much both of you! I’ll report results back tomorrow.

Matt

2 Likes
5

Unfortunately this is not possible. Only a few lights support changing these parameters when they are off or turning off and so they have dedicated services for this e.g. https://www.home-assistant.io/integrations/lifx/#set-state

It is a limitation of the hardware.

1 Like
6

@tom_l thank you kindly sir for the information and for educating me on the reasons why. I appreciate the reply.

Matt

1 Like
7

Hmm, this isn’t working for me. Maybe the light’s firmware doesn’t support the acceptance of a “color” parameter, when setting the brightness to 0?

This is the command I"m using:

          - service: light.turn_on
            target:
              entity_id: !input target_lights
            data:
              brightness_pct: 0
              color_name: "{{ x }}"
              transition: "{{ y }}"
8

Does it work if you use actual values rather than templates?

9

@tom_l, after some further testing, my conclusion is that it works as expected if you are setting the brightness to something low like 1%. Setting the brightness to 0% seems to ignore all of the other fields, including the color, that one might pass to the “light.turn_on” service.

I am not sure if internally, HA is converting that call into a light.turn_off service call, since the brightness is 0, or if it’s something in the light’s firmware.

I am also not sure how I would go about figuring out which it is.

Either way, it does seem desirable to me for this to work - either by adding parameters to the light.turn_off service, or making it work with the light.turn_on service.

The reason is, the only other way to accomplish this behavior is to:

  1. Call light.turn_on to 1% with the new desired color
  2. Sleep/delay/set a timer for the value of “transition” used in (1)
  3. Turn the light off

This is highly undesirable, since it makes the blueprint a lot more complicated, and to do it properly and survive restarts you’d need to use an actual timer entity.

Of course, anyone please let me know if I’m missing something obvious, which is possible.

I also wanted to thank everyone for their time on this thread thus far. I know this is a bit contrived, but I figure doing something like emulating sunset (by fading down in brightness and to a red color simultaneously) is somewhat of a desired feature!

Cheers
Matt

10

If you change to using brightness instead of brightness_pct you can get it to below 1% (in case your bulbs actually emit light at 1%).

Simply put, brightness ranges from 0-255, while brightness_pct ranges from 0-100.
Sending brightness: 1 would be the equivalent of sending brightness_pct: 0.4.

11

@ShadowFist thank you for the reply! The desired end state of the light would be “off”. So unless I’m misinterpreting what you said, I don’t think it would work. I have a lot of dashboards, automations, etc etc that trigger / report if lights are on vs. off. So if it is on, even at 1/255 brightness, that won’t work. The desired end state of the light after the “transition” period would be “off”.

Thanks for the idea though, I totally agree about the brightness granularity you mentioned, it would be more dim, just won’t work for me.

Matt

12

Indeed. You’d still have to eventually send a light turn off command right after the brightness command is sent.

My point was that if you ever run into a light which actually dims down to 1% and still emits some light (most don’t, so my point is moot), sending brightness: 1 would get it low enough for you not to notice it going from brightness: 1 to off.

13

Thanks, @ShadowFist , makes sense! On the Hue light strip that I tested @tom_l 's request on this morning (not using variables, but rather integer and string literals), it was indeed visible even at 1%.

But anyways it’s a moot point. I really do feel that it would be great to have it work, either with the turn_off or turn_on command.

Matt

14

See the brightness parameter here: Light - Home Assistant

So specifying brightness: 0 is the same as light.turn_off, where you can not specify the other parameters.

And as I said before, this is a limitation of the hardware. Nothing HA can do about it.

1 Like
15

Thanks @tom_l I appreciate the quick reply.

Let me know if you can think of anything that I am not being creative enough for. If not, I think the consensus is that what I’m trying to do isn’t possible, and I’d have to do the delay/timer and then turn it off.

Matt