Unify inconsistent logic between light.turn_on and scene.turn_on

Feature Requests
1

Current State

action: "light.turn_on"
data: "{{ var_data }}"
target:
    entity_id: "{{ var_area }}"

action: "scene.turn_on"
data: {}
target:
    entity_id: "{{ var_data_and_area }}"

Proposed Change

action: "scene.turn_on"
data: "{{ var_data }}"
target:
    entity_id: "{{ var_area }}"

Description
To set the lights on, the logic is nicelly splitted between data field (lights setting) and entity_id that allows target specific group of lights. This is very useful as it allows large variability in the user code with ease.

For setting the scene on, the data (settings) and target are merged together. This force users to create a custom implempetation to make their code work instead of just allowing them to reuse previous logic.

Unifying logic would be beneficial as it would allow users to reuse their code between these two actions.

Possible issues

  • Backward Compatibility - When data field is empty, use as currently implemented. When data field is not empty, use the new logic as for light.turn_on.
  • What happens to the ligths specified in the target when missing in the data variable? I would suggest to filter out these ligths so they stay switched off.

Motivation
I have rooms A, B and C. Based on the door sensors, I sometimes want to set the same light settings to all three rooms at once while sometime control just room A, AC and so on. This is currently implemented and works. I also want my scene to work the sameway. This however turned to be quite hard to achieve as I would have to create all scene combinations for all rooms that would pretty much all hold the same data (just different lamps).

2

I don’t follow…

This is how I see the action for applying a scene right now in my setup

action: scene.turn_on
target:
  entity_id: scene.back_office_vacant
data:
  transition: 5

I don’t see this ‘mix’ you describe - that’s not how it works?

3

If I am not wrong, the transition is the only data field that is currently supported. All your lamp settings (colors, brightness etc.) are set in the scene.back_office_vacant which also holds the information about what lights should be controlled.

One variable for controlling which lights are used together with their settings is in my opinion not as flexible as two variables independent of each other. While this works perfectly fine for a simple logic, it hinders complex functionalities.

4

Yes transition is the only entry supported. Thats because that’s how scenes work. Scenes aren’t supposed to be used the way I THINK you’re asking about.

They are just a collection of settings that are fired together. That’s it - no more no less. If you want to control lights like I THINK you’re saying (be able to dim etc.) make a light group.

Your choice on scenes is should I make a scene or should I make a script.

5

I understand and I would likely implement them the same way as they are now until I faced my current problem. This should be just a discussion whether the current implementation is the most optiomal (maybe it is).

I just want that collection of settings to be defined once per scene for all lights in my home (e.g. for Romance, Relax, Party) and have a flexible way to control in which rooms these scenes should be used (each light has different color and brightness setting in this case so I can’t use ligth.turn_on for group of ligths).

Currently I have to make e.g. the Romance scene for room A, B and C. If I want to use them in all rooms, it’s three actions calls. Other less elegant option would be to have the scene for room A,B,C, AB, AC, BC and ABC but that would hold lot of duplicit content.

So my suggestion was pretty much one scene setting holding data for rooms ABC and then just using target to decide which of these lights will go on. This is pretty much how it is used in ligth.turn_on so I saw a potential in implementing it the same way that would benefit more complex logic

6

That would deviate from how scenes work on pretty much every platform. It’s only a stateless collection of settings. Period.

I understand what you’re saying but that’s simply not what they’re for.

7

Yes, therefore scene.turn_on should be preserved as it is. There could be an additional function e.g. scene.turn_on_specific that would be more align with light.turn_on.

It’s common to have e.g. conference rooms that can convert from one big room to several small ones. The light.turn_on action elegantly supports this through target variable. You can sneak through different target lights and the global data settings for those lights stay the same. For scene.turn_on you are in trouble because data and target are not separated. (I admit there is a difference: it’s not a global data (common settings for all lights) rather than local data (collection of individual settings per light)).

But I will respect the ha architects decition. The most flexible solution is not always the best and there are many factors that has to be taken to consideration.