Input_select enhancement. Support mapping

Feature Requests
1

An input_select currently allows you to specify a selection list:

input_select:
  my_selector:
    name: My Selector
    options:
    - Kitchen
    - Garage
    - Bedroom
    - Office

The options (Kitchen, Garage, Bedroom, Office) will appear as choices in the selector’s list. However there are situations where the chosen option is not the value we wish to use (in an automation).

For example, “Garage” may represent the temperature value to set for the garage. However, input_select only allows you to define “Garage” but not its associated value. The way to achieve this now is to use a map (key-value pairs) in the automation’s template.

  {% set temp_map =
     { 'Kitchen':'20',
       'Garage':'10',
       'Bedroom':'22',
       'Office':'23' } %}
  {% set state = states('input_select.my_selector') %}
  {% set temp = temp_map[state] if state in temp_map %}
     {{temp}}

Ideally, the mapping should reside with the selector. Automations can refer to the selector and use either the chosen option’s key (Kitchen) or its value (20). Here’s an example of how it would appear:

input_select:
  my_selector:
    name: My Selector
    options:
    - option: Kitchen
      value: '20'
    - option: Garage
      value: '10'
    - option: Bedroom
      value: '22'
    - option: Office
      value: '23'

For reference, this feature was discussed in this thread.

EDIT

Based on discussions in this thread, instead of using key-value pairs, which make the input_select verbose, the neater solution is a list.

input_select:
  my_selector:
    name: My Selector
    options:
    - Kitchen, 20
    - Garage, 10
    - Bedroom, 22
    - Office, 23

input_select:
  my_selector:
    name: My Selector
    options:
    - Low, level1
    - Medium, level2
    - High, level3
2

I was following the original thread. Great idea because I need to do something similar to pair up some input_booleans with zwave nodes.

How would this look when consuming the key value pairs? How would you know there even was option/value pairs if its a simple input_select? Perhaps HA would need a input_dictionary type?

states('input_dictionary.my_dictionary') would yield {option: "longname", value: 1}?
or what would it look like when setting the value?

Also, I apolgize if the feature requests forum isn’t the right format for me thinking out loud about it. :wink:

2 Likes
3

Iv voted +1 under the premise that the mapping would remain in the backend , while the frontend would only show the options (of the example)

I use mappings allover, and would very welcome this feature!

4

great idea
would love to have this

5

All good questions … that I’m not smart enough to answer! I guess the biggest challenge is to maintain compatibility with how input_select currently works. Unless I’m mistaken, the proposed way to define the key-value pairs isn’t backward-compatible. I converted the YAML into JSON and it produced this:

{
  "options": [
    {
      "option": "Kitchen",
      "value": "20"
    },
    {
      "option": "Garage",
      "value": "10"
    },
    {
      "option": "Bedroom",
      "value": "22"
    },
    {
      "option": "Office",
      "value": "23"
    }
  ]
}

That’s not as straightforward as the current form:

{
  "options": [
    "Kitchen",
    "Garage",
    "Bedroom",
    "Office"
  ]
}

Implementing this feature request might be a breaking change.

6

Unless it’s ok to introduce a new data-type to the mix. That wouldn’t break, it would just be a new feature.

1 Like
7

please also consider creating the possibility for value_templates:

input_select:
  my_selector:
  name: My Selector
  options:
    - option: Kitchen
      value_template: >
        {{states('sensor.kitchen_temperature')}}
8

+1 for this. I want to have an input select with all my speakers, and a list of buttons with playlists and stations I want to play from spotify. I click the playlist, and it plays on whichever speaker group is selected in the input select. I can do it right now with the entity id, but it looks ugly. A mapping would make this SO much better looking.

9

is this already implemented now?

10

The answer is in the documentation for Input Select.

(No.)

11

But there were indications in the 2022 WTH month that this is coming.

1 Like
12

I could use that really well. Like for example for a list of ip adresses, where the friendly name is the name of the device and the value the ip.

1 Like
13

I have numerous instances of both things mentioned. I can see some issues with the second one (template-based population). What I have done in the past is I create an input_select with only one option and then use an automation at start that populates those options.

The downside you have to consider is what happens if you have an automation that triggers when the value changes.

Take for example my TV remotes. I designed them with input_select’s that allow quick access to all the frequent apps (HDMI-1/DirectTV, Netflix, Hulu, etc.) and that list is by TV. Kids TVs have some, other TVs different lists. To save space I added “Power off” as one of them. I create an input_select and there is a JSON file with all the TVs information including this list (and many other things). There is only oine option in the input_select which is “Power off” as it is common among all TVs. The whole remote is populated including the input_select when HA starts.

And there is the issue. At start, the list gets “rebuilt” and the “Power off” option is first. BOOM. All TVs turn off as it fires the automation that the input_select value changed. I am not sure there is a fix to this, I do not see how you could build an input_select dynamically without causing this to happen.

14

Did anyone figure out a workaround for this or are we still hoping for the feature to be implemented 4 years later? I do have a workaround but it is limited to MQTT.
Would also be great to have the option to always reset to the first option or some type of “please select:” default upon selection. This would ensure it is possible to select the same option multiple times.
Fingers crossed this will make it for an upcoming release.
cheers,

15

They’re not an exact answer to the original request, but have you looked at Template selects?

1 Like
16

I’m also looking for a table, or even better somthing like an array, to store values.

My actual usecase would be the target-pressure for the tires of my car. By now I have for each target-value one input_number-helper and select the right one in dependance of an input_boolean-helper / input_select-helper. For example:

  • targetpressure-winter-front-lowload,
  • targetpressure-winter-front-highload,
  • targetpressure-winter-rear-lowload,
  • targetpressure-winter-rear-highload
  • etc.

That’s in my case 8 number-helper (summer / winter, front / rear, lowload / highload), which makes it really confusing.
If there where an array, I could store it (in pseudo-code):

- targetpressure[winter][front][lowload]
  .value = 2.6 
  .unit_of_measurement = bar
- targetpressure[winter][front][highload] 
  .value = 3.0 
  .unit_of_measurement = bar

unit_of_measurement is not really needed, but would be a goody. Storing pure value would help already. If you cold use the array-member (ie. winter / summer) to fill an input_selector would be also quite nice.

There are a lot more usecases, to store values in an array. For example

  • target-temperature of a room, depending on
    • summer / winter,
    • day-of-week,
    • workingday / weekend / vacation
    • user present / away
  • turn on heater/target-temperature of aircondition, depending on
    • actual temperature
    • forecast temperature
    • day / night
    • user present / away
    • power of PV-system

The HA-community will find many more usecases.

17

Example:
I would like to set inverter discharge power based on the state of charge of the battery. I’m searching easy way to maintain a 2 dimensions table like:

SOC | Power
45% | 1000W
60% | 2000W
etc

In a helper, that would be great.

Vote +1

1 Like
18

Added a link from 2024 WTH