"Context" references for selectors

[karwosts]

Was thinking about adding the concept of "context" to some selector definitions. This is already used in some places in the frontend, but it isn't exposed to the backend as a valid selector definition.

This could be a key in a selector definition, that could be a reference to another selector in the same form (another input in a blueprint, or another field in a service call).

Then the selector could be passed the value of the field that was listed as the context, and use that information to refine how it behaves.

Some ideas for what this could achieve:

• select.select service currently just offers a freeform text field for the option to select. If it had support for context, it could reference the target selector in the same form, and then we could get a list of selectable options based on the entities that are selected, and display them in a dropdown, instead of requiring user to remember and type it out manually. Perhaps it might look like this:

select_option:
  target:
    entity:
      domain: select
  fields:
    option:
      required: true
      example: '"Item A"'
      selector:
        select:
          context:
            field: target
            attribute: option

This is telling the select selector: look at the current value of the target selector, and from the entities in that field, get the value of their option attribute, and use this as the valid list of options for the dropdown. (we could choose to use either the union or intersection of options if multiple entities are defined, but I guess probably that won't be a case that comes up that often)

• Similarly, set_hvac_mode/set_preset_mode/set_fan_mode actions in the UI could suggest modes/presets supported by the selected target entities.

• blueprints or config flows could use a state selector, but reference an entity_id from another input to populate the list of possible states. Currently the state selector requires a hardcoded entity id, which I can't really imagine ever being useful.

• color temperature selector in light service calls could align with the min/max color temperature of the selected light entities

Maybe more possibilities, but that's just what I thought of so far.

[HarvsG]

I have a use case in trying to make the "Bayesian" helper Config Flow. The Bayesian integration needs to know both the entity and the state of interest, very similar to the 'trigger entity state' UI in automations.

In the meantime I'll have to use an input field and check that it's a valid state type before allowing progression.

        vol.Required(CONF_ENTITY_ID): selector.EntitySelector(
            selector.EntitySelectorConfig(domain=[SENSOR_DOMAIN,BINARY_SENSOR_DOMAIN])
        ),
        vol.Required(CONF_STATE): selector.StateSelector(
            selector.StateSelectorConfig(entity_id="***THAT_ENTITY_ABOVE_DYNAMICALLY***")