Hypfer / hass-scene_presets

Hue-like scene presets for lights in home assistant
Apache License 2.0
128 stars 9 forks source link

Disable brightness on scene #21

Closed Patrick1610 closed 6 months ago

Patrick1610 commented 6 months ago

What is happening?

It is amazing how fluent this works! I really missed the hue scenes since letting go the bridge s few years ago.

I want to stay in charge of the brightness of each light, so I would like to have the option to disable the adjustment of brightness completely. Would it be possible to implement that? I want to combine this with smart light groups (Lightener integration) and this is not possible in the scene because for the colors, groups are expanded.

(another solution would be to expand the groups for the colors, but apply the set brightness to the group without expanding, but I’m not sure if that is easy to implement).

Kind regards, Patrick

What should be happening?

I expected the brightness to apply to the group, and not the individual lights within the group.

Reflection 1

Balanced View

Is this issue tracker the right place for this topic?

Yes, the expansion of groups is not per se expected behavior, and the suggestions might benefit other use cases as well.

Please enter the scene_preset version you're using

Multiple scenes

Please enter the Home Assistant version you're using

2024.4

Details about your setup

Zigbee, ZHA, mostly hue

Reflection 2

Yes, I use lightener

Time and Effort

Hypfer commented 6 months ago

I expected the brightness to apply to the group, and not the individual lights within the group.

That's possible. For that, you need to enable the "Hide members" option of the group. Though, looking at that Lightener thingy, I suppose the main effects of activating "Hide members" aren't desirable in your setup

Hypfer commented 6 months ago

Having spent another 10 minutes thinking about this, I think the issue here isn't necessarily group expansion but rather that lightener entities appear as groups including the entity_id attribute that is used by the resolver.

If they were somehow more distinctive (or if they'd offer an option to hide the entity_id attribute) neither scene_presets nor adaptive-lighting (https://github.com/basnijholt/adaptive-lighting/issues/978) would require code changes.

Also, in the lightener component you actually know that you're a group that should never be resolved, whereas other components can only either guess or add clunky optional parameters. See also #16

Patrick1610 commented 6 months ago

So this would mean there is a change that could be done on the lightener integration that would allow AL and scene Presets to behave as expected?

Would that allow scene_presets to change the color for each member and the brightness for the complete lightener?

I don't understand it completely, so I'm not sure what to ask the lightener developer.

Hypfer commented 6 months ago

Sorry, I'm a bit too quick to reply today and don't take enough time to think before responding. Actually it is possible for scene_presets to distinguish a lightener entity and stop resolving of the members without any changes in lightener.

That is something I can do and that is also what makes sense IMO. The previous behavior there was somewhat incorrect as it assumed that everything that has an entity_id attribute must be a group.

I did change that right now and with that, lightener lights work as one would expect: A single light consisting of multiple lights with varying individual brightness. Commit: https://github.com/Hypfer/hass-scene_presets/commit/3b62b2701ce944a525e01cd50fc08dda4a99a9cc

This is only half of what you've requested though, however, the other half doesn't really make sense conceptually.

If you use a lightener entity with scene_presets, all the members will show the same color. It has to be like that, because by being part of a lightener light and being addressed through that, they don't have an individual identity anymore. Thus, they can't have different colors, because they're one large thing.

If you want them to display different colors, you'll have to address them as individuals and not by their lightener group identity.

Personally, I don't really see why one would want to do that anyway, because those are two very distinct use-cases that don't really overlap:

  1. Lightener being for white to orange lighting with the purpose of illuminating the room. The magic feature being to blend from indirect to direct light depending on brightness for a more natural feeling
  2. Colorful scenes being for indirect lighting with the purpose of providing an effect

By definition, colorful scenes won't ever be direct light, because you most likely don't want a lime green spotlight on you. You also won't dim them up or down with a dimmer but just apply them as they are to a bunch of lights. They're a scene. Multiple states that get re-applied. An inherently static thing.

Therefore, when applying a colorful scene preset, you don't require this blending between indirect and direct light sources, as in that use-case there are neither direct lights nor is there dynamic user input.

The good thing is that a light can both have an individual and a lightener group identity at the same time. And thus, you can address your commands to either the individual light or the lightener entity and get the correct behavior for that use case.

Patrick1610 commented 6 months ago

Thanks a lot for the extensive explanation. I understand how the usage of groups vs individual lights works a bit better now!

Nonetheless, I think I disagree with you whether the concept makes sense, and in what way the two scenarios overlap.

Lightener being for white to orange lighting with the purpose of illuminating the room. The magic feature being to blend from indirect to direct light depending on brightness for a more natural feeling

Lightener itself does not adjust the light color in any way, it is just a way to make brightness percentages in a group relative. I have a few cases in which this is very useful, and also in combination with a colored scene.

With Lightener my dining room lamps (which are very bright dumb lamps on a smart dimmer) are always at a much lower percentage than the surrounding Hue lights. When I want to set a colored scene for the entire room, I don't want these lights to have the same brightness as the other lights. So the 6 hue lights might be at 80-100% while these remain at 10-15%. In the evening when we would like some colored lighting scenes, we want to still have that relativity, while also giving the Hue lights all a different color.

Also in our backyard, where we have up-down spots in the Lounge, we have a similar situation. The lights are always at 25% for some ambient light, but when we sit there the down-lights are at 35%, but the up-lights are at 100%. This creates a beautiful indirect lighting which is very nice in combination with a colored scene.

Wouldn't there be the possibility to split the turn_on commands into seperates for brightness and the color? This is also implemented in Adaptive Lighting which you also refered to: image

In that scenario it may be possible to treat the brightness like you do now with the last change, and the color like you did previously. In that way the scene is completely adjustable.

I'm curious to hear what you think of my point of view.

Regards Patrick

Hypfer commented 6 months ago

Wouldn't there be the possibility to split the turn_on commands into seperates for brightness and the color?

Well it is code that can be edited by anyone so sure there would be a possibility to do that. However, I won't be maintaining that, because I don't see the point of it. Worse, I believe that it would make the code more complicated and would negatively affect the UX, because then there's one more toggle that does something weird.

Something weird that I couldn't even cover with a help text because I don't see the point.

I'm curious to hear what you think of my point of view.

Respectfully, I do not care the slightest about it. I'm sure it's valid and great and whatnot but it's also none of my business and entirely irrelevant to me.

I've already spent multiple hours on interacting with this issue and I'm honestly at the limit of what I'm willing to give of my own free time for some very niche use-case I don't understand of some random guy I don't know.

That said, please don't read this as hostility because it isn't. I'm just being very honest and open here.

Btw since this does happen sometimes: Please don't open any PRs for this. I won't be merging them, because it's not about writing the code but the added complexity and the reduced UX by adding some special niche toggles.

Thank you for your understanding and I wish you a lot of fun on your continuing smarthome journey :)

danishru commented 2 weeks ago

First of all, I want to thank you for the integration you created, the Home Asistant community really needs it.

Initially, I wanted to create a new Issue on disabling brightness control, and I came across this, so I'll write it here.

Something weird that I couldn't even cover with a help text because I don't see the point.

Disabling brightness control for a scene is not some very narrowly specialized case, but a popular function. And it definitely makes sense.

For example, I turn on the "Dreamy dusk" scene before going to bed, redefine the brightness to medium. Then another user tries to adjust the brightness to the one he needs via a dimmer linked directly to a group of lamps, or automation for sleep is launched, which should smoothly reduce the brightness and eventually turn off the light. And if I don't turn off the running scene, although I don't want to turn it off, because I like a smooth change of colors, then after a specified interval Scene Presets will return the specified initial brightness. This creates a bad user experience in such a scenario, and greatly limits the use of scenes.

Adding a "Disable dynamic brightness" checkbox in the "Dynamic" section for scenarios like mine or @Patrick1610 shouldn't create any problems for users.

It would be really cool if this feature would finally appear in this integration.

P.S. Sorry for my English, I use Google Translate.