Closed thomasloven closed 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.
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_boolean
s:
- 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 🤷 )
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
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.
That translation could easily be done with variables. I think the select selector should be as similar to input_select
as possible.
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?
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.
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.
Oh. My mistake. The fourth one had not... @EPMatt would you mind transfering your suggestion for a service selector to Discussions?
Don't worry @thomasloven. Yeah I'm moving the proposal there. Thank you!
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:
is perfectly valid, opening this in the frontend automation editor and saving it will turn it into
Proposal
I propose two new selectors are added for the benefit of the frontend.
text
for long strings of text, potentially including one more newlinesobject
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