Allow Selectable AND / OR Logic When Targeting Entities in Automation GUI

[yak27]

Up till now, when selecting a device or entity in a Target panel it didn’t make sense to provide logic-type filters. After all, you cannot have an intersection with devices and entities and an object can only ever belong to a single area.

As seen, in the above image, the logical action would be to select entities that are thermostats and are located in any bedroom. Now that we have labels, we can perform more powerful commands and it is imperative that the existing tools reflect the abilities that labels offer.

Therefore, there should be a selector that determines whether we want to perform an AND or an OR operation in the automation target selectors.

_{In this example, an argument can be made, that we will achieve the same results if we only include the “In Bedroom” label. I want to preemptively counter this by stating that this is an example, and this does not have to reflect any actual implementation. There will be instances that this will not be the case.}

[tom_l]

Don’t forget to vote for your own request.

[Didgeridrew]

@yak27

In this example, an argument can be made, that we will achieve the same results if we only include the “In Bedroom” label. I want to preemptively counter this by stating that this is an example, and this does not have to reflect any actual implementation. There will be instances that this will not be the case.

Can you provide an example of such an instance?

I can’t picture a case where an Or (without added conditional logic) makes sense in a target list…

[yak27]

A typical example for climate would be if there are separate systems for heating and air conditioning. This frequently happens with radiant heating powered by hot water. (You’ll also have instances where window AC units can be automated and are installed temporarily to augment an HVAC system.) In those cases, you may want to have a Thermostat - Cool and a Thermostat - Heat label. In those instances, it makes sense to have the intersection of thermostat-type and selected-areas.

The only reason why we have a scenario where the operation is redundant is because it is common to only have one climate per area which means that there is little reason for there to be a conflict. In effect, by choosing the climate service, we are implicitly creating a logical AND with climate and any other group of entities. It just so happens that one of the labels fits into one of those logical groups.

Perhaps I didn’t provide the best example (which is why I put in the disclaimer in the first place). Instead, imagine that we are dealing with the switch service. There are many devices that expose themselves as a switch. Therefore, if you call switch.turn_on for a set of locations you cannot assume that you will only target the entities you expect or want. Clearly, we require greater control when selecting with labels.

In the broader sense, the core functionality granted by labels or tags necessitates having advanced logical controls in every aspect where they are used. Without that, you will have to be strategic in how you create labels or you’ll have to create redundant labels that are task-specific for the goal at hand. Such a design negates the usefulness of labels and creates clutter - the very thing labels are meant to combat.

[DvdNwk]

@Didgeridrew

@yak27

In this example, an argument can be made, that we will achieve the same results if we only include the “In Bedroom” label. I want to preemptively counter this by stating that this is an example, and this does not have to reflect any actual implementation. There will be instances that this will not be the case.

Can you provide an example of such an instance?

This is a GUI issue similar to templates issue:

Label_entities(): allow multiple labels selection (intersection)

Proposition: allow getting entities having multiple labels on them (intersection). Example: {{ label_entities(['bedroom', 'evening_lights']) }} It should return entities that have BOTH the bedroom and evening_lights labels at the same time. some_light1 with a label bedroom – NO, would not match some_light2 with labels bedroom and daytime – NO, would not match some_light3 with labels bedroom, evening_lights - YES, would match In other worlds, it would be a logical AND of the passed in label…

The example I gave was: selecting an intersection of lights that have both bedroom label and evening_lights label at the same time.