Add (blueprint) selectors for text and arbitrary objects

thomasloven commented 3 years ago

Context

Blueprints can accept input in many forms, including arbitrary objects and long text strings. Currently the frontend cannot handle those formats, however.

While the following data in an automation specification:

use_blueprint:
  input:
    my_stuff:
      key: value

is perfectly valid, opening this in the frontend automation editor and saving it will turn it into

use_blueprint:
  input:
    my_stuff: "[object Object]"

Proposal

I propose two new selectors are added for the benefit of the frontend.

text for long strings of text, potentially including one more newlines
object for arbitrary objects (dictionaries or lists)

Consequences

Automations utilizing templates and using long string or arbitrary object in inputs become easier (or at all possible) to manage from the frontend.

Implementation

Backend: home-assistant/core#45112 Frontend: home-assistant/frontend#8152

balloob commented 3 years ago

I think both make sense. Initially we rejected the idea of a yaml selector but I can see how it sometime can be needed.

thomasloven commented 3 years ago

I have a use case in a xiaomi vacuum cleaner which can be told to clean certain rooms depending on the state of a number of input_booleans:

- id: '1610540569350'
  alias: Xiaomi - clean rooms
  description: ''
  use_blueprint:
    path: xiaomi_vacuum.yaml
    input:
      rooms:
        input_boolean.dammsug_hallen: 24
        input_boolean.dammsug_koket: 22
        input_boolean.dammsug_vardagsrummet: 23
        input_boolean.dammsug_sovrum: 17
        input_boolean.dammsug_kontoret: 16
        input_boolean.dammsug_barnrum: 1
      vacuum: vacuum.xiaomi_vacuum_cleaner

(incidentally this is also why I'd want to implement blueprinting for scripts, but then again with automation.trigger it's pretty much the same thing 🤷 )

thomasloven commented 3 years ago

Adding on to this discussion, I'd like to propose a third new selector.

select for picking one from a list of options.

my_input:
  selector:
    select:
      options:
        - foo
        - bar
        - baz

In the GUI this would take the form of a listbox, like an input_select.

In yaml, the syntax for using it could be either by value

use_blueprint:
  input:
    my_input: bar

or by index

use_blueprint:
  input:
    my_input: 2

I suppose the former would be both more user friendly and safer.

Use case:

inputs:
  media_url:
    name: URL
    description: URL for media stream
  media_type:
    name: Type
    description: Type of media stream
    selector:
      select:
        - image
        - music
        - tvshow
        - video
        - episode
        - channel
        - playlist

...

actions:
 - service: media_player.play_media
   data:
    media_content_id: !input media_url
    media_conten_type: !input media_type

ahknight commented 3 years ago

For the select style, it would be really nice to support a display name for each option as well. Say I'm picking sounds on a siren but the config option is numeric and I want to list the name of the sound.

thomasloven commented 3 years ago

That translation could easily be done with variables. I think the select selector should be as similar to input_select as possible.

EPMatt commented 3 years ago

Hi @thomasloven,

I was working on a blueprint which needed this feature. I've managed to implement the select selector in https://github.com/home-assistant/core/pull/45803 and https://github.com/home-assistant/frontend/pull/8297.

As you suggested, the provided implementation is fairly similar to input_select. 👍🏻

Is this similar to what you were thinking about?

EPMatt commented 3 years ago

I'd like to propose another new selector:

service for picking a service from a list of available ones.
```
my_input:
selector:
service:
  integration: deconz
```

In the UI the input could appear in the form of the system service picker found in Developer Tools -> Services. The integration option allows to filter services based on the integration which they are exposed by.

One use case of this input could be the user's need to specify a service to run inside the automation, but not an action.

For example, having the service selector would allow the user to select the desired notify.mobile_app_<your_device_id_here> when building a blueprint for sending notifications to devices. Users should not compile service data by themselves, since they can be provided by the blueprint (eg. when asking to pick a service from a known "family" of services which use the same data format).

I was working on a blueprint which could benefit from this feature, but I hope this could be helpful in general.

thomasloven commented 3 years ago

The original two selectors have been implemented in 2021.02.0b0. The third suggested one is complete and waiting to be merged. The fourth suggestion has been opened as a separate discussion.

I'm closing this issue.

thomasloven commented 3 years ago

Oh. My mistake. The fourth one had not... @EPMatt would you mind transfering your suggestion for a service selector to Discussions?

EPMatt commented 3 years ago

Don't worry @thomasloven. Yeah I'm moving the proposal there. Thank you!

home-assistant / architecture