Scene activation turns on lights with attributes NOT SPECIFIED in scene

I was previously using custom scenes and my own handler to save/restore them and finally made the switch to HA scenes.

Here’s a major problem I have, and I’m pretty confused about why it’s implemented this way: When turning on a scene, often a light state is set to “on” and then the attributes are applied. This happens, at the very least, for mqtt devices (zigbee2mqtt) and for some Nanoleaf devices. In both cases, the devices themselves support attributes passed in the “turn on” command.

The result is that lights get turned on at their previous brightness before the brightness transition kicks in. So, for instance, motion-activated night lights will turn on very bright before fading down to match the scene values. If if the transition time is set to 0, they will flash into their bright state before transitioning.

It’s possible that I’m missing some functionality or I’m confused about some subtle aspect of scenes written in YAML, but this ends up looking really unpolished. Note that my own scene handler (from the same YAML description) is able to turn on scenes without this issue.

This is done since some attributes (e.g. brightness) do not exist unless the light is on.

This is a limitation of the light hardware, or its API at least.

Some lights, like Lifx do not have this limitation but a special service is required to set the attributes when the light is off (lifx.set_state).

If your lights support changing the required attributes when off you will need to use scripts instead of scenes.

Complain to the light manufacturer. There’s nothing HA can do about it unless they update their API.

This explanation doesn’t make much sense to me. Both the Nanoleaf REST API and the zigbee2mqtt API (as well as the standardized zigbee lightbulb semantics) support a turn_on command accompanied by attributes. As I said, my own scene parser handled this with no problem.

I understand the desire to make scenes as uniform across devices as possible (literally an unordered list of states), but many devices operate in a mode where certain attributes can be specified at turn_on and are applied before the light begins its transition, so this seems like an important enough abstraction.

There is a way to do it without breaking the list-of-device-states abstraction, which is simply to allow the scene.turn_on service an extra flag that specifies that when a device is transitioning from ‘off’ to ‘on’, the attributes should be specified via turn_on instead of set_state. This applies, for instance, to some televisions which do not support setting the input when the TV is off, but do support a “TV ON” command with an input specified.

You can open a feature request to have the behaviour changed here:

Or as it sounds like you may be conversant with development, you could propose your own PR to implement the changes. Pull requests · home-assistant/core · GitHub

Thanks! I initiated a feature request.

It is safer for someone else to do the dev work since I’m only loosely familiar with the HA code base. In the mean time, I’m going to create template lights for each device that implement these semantics.

Can you explain how a Template Light can be used to set the device’s attributes prior to actually turning it on? What service call will it use to perform that specific order of operations?