WTH isn't there a "except..." for turn off/on ?

Month of "What the heck?!"
1

I have a few automations that turn on / off all lights except a few specific ones.
It would be great to be able to just add that list to the turn on/off service as a parameter instead of using a template.

2

Isn’t that what scenes are for?

3

Can you provide a more specific example?

If you’re asking for a way to run a scene, but exclude some devices, check out this WTH: WTH - Why can't we apply a scene to an area?

If you’re asking to call light.turn_on on an area minus a device, that doesn’t exist yet. While it is a good WTH, I would recommend against using this feature(if it existed) because of the potential headache it could cause.

For example, imagine you target the lights in your living room minus the side table lamps. What happens when you add a new lamp to the room? It won’t be excluded and you’ll have to update every automation with the exclusion. As @sandman98321 mentioned, a scene is more suitable because you update new devices in one spot.

1 Like
5

This ^ (side note I love @potelux they’ve been a ride or die)

I feel like this actually also ties to a separate post I made WTH - Why isn't there a NOT operator for conditional cards?

I think having more NOT operators/except in home assistant would be cool in general. Sometimes it’s way easier to list everything you don’t want then what you do.

1 Like
6

You could easily turn all lights except a subset on/off by leveraging labels. E.g. give all lights you won‘t like to turn off by a specific action (button press, automation….) a label „dont-turn-off“.

Then you can use a template like this:

{{
  states.light 
  | map(attribute="entity_id")
  | reject("in", label_entities("dont-turn-off"))
  | list
}}

Use this template directly in the service call or wrap it in a helper sensor if you like.

This can also be extended to filter areas, floors, other domains etc. These are all accessable in templates.

3 Likes
7

Yes, I’m asking about a light.turn_on (or switch.turn_on) on an area minus x devices. Or a light.turn_off all the lights in the house except a few I want to keep on.
Right now I can do it with a template, but it would be cleaner if it would be possible to do in the light.turn_on / off call

1 Like
8

Yes, I’m using a template similar to that one now. Just would like if it were possible to do directly in the service call. :slightly_smiling_face:

1 Like
9

You can always do that when you use an automation or script. If you like do to so via UI using e.g. button card you simple can wrap this in a script and call the script instead of light.turn_on

10

That’s pretty much what I do now. Could be better

1 Like
11

I (respectfully) disagree. The new lamp would be tagged with the ‘lamps’ label, and the exclusion rule could target labels (or areas, floors, etc) in the exact same way that the light.off function can.

So it would look like: automation action = light.turn off in area ‘living room’ EXCEPT label = ‘lamps’

I think it would work really well, especially for smart plugs which may change regularly.

2 Likes
12

The problem is that one set of logic isn’t any more desirable than any other. l don’t think this would ever be implemented unless it encompasses the other commonly-requested logic options. Which I think would be:

  • The UNION of Selection X and Selection Y (everything matching either set)
  • The INTERSECTION of Selection X and Selection Y (only the things matching both sets simultaneously)
  • Selection X EXCLUDING Selection Y (only the things that match the first set but don’t match the second set)

Similar requests for reference:
https://community.home-assistant.io/t/allow-selectable-and-or-logic-when-targeting-entities-in-automation-gui/731958
https://community.home-assistant.io/t/and-not-or-for-labels/713412

Non-UI:
https://community.home-assistant.io/t/select-match-all-any-when-multiple-labels-selected-in-call-service/738160
https://community.home-assistant.io/t/label-entities-allow-multiple-labels-selection-intersection/715659

13

But you can have this today! You can specify more than one target for an action, and you can mix and match different target types. I can’t see how the union would be the same priority as what OP is requesting or needed at all - as it’s already cleanly implemented in the UI.

Since we can pick area/device/entity/label, and a device can only belong to one area, and it’s redundant to intersect an area with just a specific device or entity in that area (just specify the thing as the target), in this case of yours we’d be intersecting only an area and a set of labeled elements. Or several of each. Ok this is a cool edge case but an edge case nonetheless.

This last case, to me, is where it’s at. I.e. by no means are the three use cases equal in priority, but I’d be OK with an “And” vs “Except” selector for the second target. I’m currently managing this via groups, but past a couple hundred devices, manually maintaining device lists in multiple groups, multiple scenes, etc gets old fast. There’s a lot of value in being able to apply an action to an entire room, where the room knows what devices it has. And being able to have an exception can take that much further.

14

To be clear, my opinion doesn’t mean anything around here in regards to what the dev team decides to implement. It’s simply my take on what I’d expect to happen.

I do spend a fair amount of time on here and discord, and my experience is that “intersection” is the logic that is most often requested. And many users are adopting labels for everything, so it’s often an intersection between two labels. The intersection of “holiday” and “lighting” labels, for example. Certainly not an edge case. Take a look at the links in my post for more examples.

The reason I listed “union” is not because it doesn’t already exist, but because it needs to continue to exist with any implementation of any other logic. My point was that I don’t expect any change to be accepted unless it allows the user to choose from the three logic options I listed.

But again, that’s just my opinion.

15

Accepted. Maybe “holiday” and “outdoor” (a light would know it’s light and have a light.* action while I wouldn’t have a non-“lighting” light - but that’s semantics; good argument).

16

This is exactly what many of us want. Because in the current situation that doesn’t allow exclude, every time you add a new light to the room you have to go and add it to every group and label that you’re currently using to exclude the side table lamp. Both are annoying, but if you had many automations with the same exclusions, I also imagine you’d exclude a label (and then just add the new side table to the side table label)

The intent could be more clear and maintainability would be significantly better if you had an automation that turned off all lights except those labeled “side table” or “night light”.

Instead right now you create a group or label that is something like “turnoffable lights” or “day lights” or “living room lights except side tables”. Sometimes those might be better options, but there are many situations they are not.

Or maybe I want to instead turn on all lights labeled “holiday” except those in the babies bedroom because I don’t want an automation to accidentally wake up the baby. Ideally there’d even be a simple way to say “turn on all lights both labeled holiday and in the living room”, but not holding out hopes for anything like that if exclude is off the table.

Being able to combine include and exclude would be really powerful and could make managing these systems a lot less frustrating.

17

Just pointing out that all the functionality you want already exists today; the problem is that it is not available through the UI. You have to use templates (as mentioned earlier in the thread)

On the bright side, Frenck recently added a few new template filters to help with managing lists, like union, intersect, and difference. And, if you use an action that is domain-specific (e.g. light.turn_on rather than homeassistant.turn_on) you don’t need to filter down to only that domain because all entities not in that domain will be ignored.

So, the action for this:

target the lights in your living room minus the side table lamps

is simply:

action: light.turn_off
target:
  entity_id: >
    {{ area_entities('Living Room') | difference(label_entities('Side Lamps')) }}

Or, if you prefer:

action: light.turn_off
target:
  entity_id: >
    {{ difference(area_entities('Living Room'), label_entities('Side Lamps')) }}

And, as a final bonus, the HA release coming out in less than 24 hours will have some UI improvements for templates, so that you can now just apply a template to a single field (e.g. the entity_id field in the above examples) and you can still use the UI for everything else! (So again for the example above, you wouldn’t have to write out the YAML for the action)

So we’re not quite there for solving this WTH but it’s pretty darn close!

3 Likes
18

I would love if this were in the UI, but I wasn’t aware of those newest template filters. That helps a lot. There’s often a way to do almost anything if desired, but the more convoluted the approach is, the harder it is to deal with maintaining automations or trying to understand WTH you were trying to do when you come back to the automation 18 months later. Also, having to drop into templates often means you lose autocomplete or dropdown support (e.g. What exactly was the exact label, did it have an underscore or a space?) so it just adds more work to deal with.

That’s a big usability upgrade for more complex actions!

19

Here’s the direct link to that announcement of the UI improvements for templates: