Friendly name for input_select options

Feature Requests
1

Hi there,

I was wondering why there is no easy way to set a friendly name for the options of a input_select.

Example:

input_select:
  fan_speed_room_fabian:
    name: Fan speed room Fabian
    icon: mdi:speedometer
    options:
      - level1
      - level2
      - level3

Now here’s what it could look like:

input_select:
  fan_speed_room_fabian:
    name: Fan speed room Fabian
    icon: mdi:speedometer
    options:
      - level1
        name: low
      - level2
        name: medium
      - level3
        name: high

For my use-case, the name would only be used for the UI and be completely optional.

Now to why this might be a good feature imo:

Let’s say I’ve got a fan with the above mentioned speed levels, a lovelace entitiy_card would show me the options level1, level2 and level3. But if I would be able to set friendly names for the actual values, so my lovelace card would say low, medium and high.

Of course there are workarounds for this, like setting up a second input_select with your display values which an automation then would catch the event and set the real input_select with the corresponding value. Or setting up a script which would be called by the changing state of the input_select which then would set the corresponding fan speed.

All in all, such a feature which shouldn’t have much effects on the back end (if any?) could help tidying up the UI with cryptic values.

2

In the example you’ve provided, I’m curious to know why you don’t define the input_select’s options with the names you wish to have displayed in the UI?

input_select:
  fan_speed_room_fabian:
    name: Fan speed room Fabian
    icon: mdi:speedometer
    options:
      - low
      - medium
      - high

What is the purpose of defining an option name the user won’t see? What are you doing (in an automation?) with level1, level2, level3 that you can’t do with low, medium, high?

BTW, there’s an existing, similar Feature Request for input_selects. The difference is that it proposes that each option can be assigned a value (as opposed to a friendly_name). This is for use in automations where you wish to present the user with text-based choices (low, medium, high) but need numeric values within the automation’s template (35, 65, 100).

This is currently achieved by creating a map within the automation. However, from a design perspective, the map doesn’t belong in the automation (and must be duplicated if there’s another automation using the same input_select), the map belongs with the input_select.

3

I’ve seen that feature request as well, but that would (probably) be a breaking change as it would need a separate (and required) value as well.

I can’t specify the options as low, medium and high, as my fan doesn’t accecpt those values. I would have to make some sort of mapping for the values via a script, as you said. So my input_select would trigger a script, which then would set level1 speed, when the value is low, level2 fan speed, when the value is medium, … In my opinion it would be better, If I would be able to specify a name (which again would ONLY be displayed in the Lovelance UI) where the option level1 would not display as “level1” but rather as “low”. The triggered script would still get the right value (level1 instead of low) and I wouldn’t need any value mapping in the script.

Your linked feature request would trigger a breaking change, whereas my feature request only adds the option to specify another name for displaying purposes which wouldn’t break any configurations. Furthermore, with my feature request you can do all the things which your linked feature request wants to do (if I read it correctly) but doen’t need a breaking change.

I hope I described it better now.

4

You can create template_sensors to effectively dynamically change the name of an entity

5

What would I need that for? I want to change the name of the options of an inpt_select variable, not of a sensor value. Sorry, but I don’t get what you want me to tell.

6

How doest the input select communicate with your example-fan at the moment?

I like the idea of having friendly names in input select, but I’m unsure of the reason if it still uses an automation to fire the activity (as to why You want to avoid mapping it).

7

It doesn’t communicate at all at the moment. It would use an automation, which would get triggered by the state of the input_select changing. and then set the fans peed of the input_select state directly instead of mapping the values around. Of course I would still need an automation, but that automation would look a lot cleaner.

8

I was just offering a solution to you wanting items in your input_select that differ (but are mapped to) those used to action your fan.

I’m confused by your dilemma… I have “friendly” names in input_selects and manage to use them in automations. Why do you need different names? It seems you need to explain what you are trying to achieve better

9

In the other proposal, the additional value is optional.

So your fan can only accept the literal words level1, level2, level3? Or do you mean it only accepts numeric levels?

Using the other proposal, it would look like this:

input_select:
  my_selector:
    name: My Selector
    options:
    - option: Low
      value: level1
    - option: Medium
      value: level2
    - option: High
      value: level3

The proposed data-structure, namely a dictionary (key-value pairs), is just that, a proposal. It could also be a list which makes the YAML form of it more compact:

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

I assume you’re mappig your friendly option-names in your automations then right?

11

nope, using them directly

12

an example of one of my input_selects:

input_select:
  radio_station:
    name: 'Select Radio Station:'
    options:
      - Hit 92-9
      - Nova 93-7
      - Mix 94-5
      - 96FM
      - 80's

and associated automation:

automation:
  - alias: 'Listen Radio'
    hide_entity: true
    trigger:
      - platform: state
        entity_id: input_select.radio_station
    action: 
      - service: script.radio

with the script:

script:
  radio:
    alias: Play Radio on Chromecast Audio
    sequence:
    - service: media_player.volume_set
      data_template:
        entity_id: >
          {% if is_state("input_select.chromecast_radio", "Lounge") %} media_player.lounge_speakers
          {% elif is_state("input_select.chromecast_radio", "Bedroom") %} media_player.bedroom
          {% elif is_state("input_select.chromecast_radio", "Office") %} media_player.chromecastaudio3249
          {% elif is_state("input_select.chromecast_radio", "Lounge and Office") %} media_player.lounge_and_office
          {% elif is_state("input_select.chromecast_radio", "House") %} media_player.house
          {% elif is_state("input_select.chromecast_radio", "Everywhere") %} media_player.everywhere
          {% endif %}
        volume_level: '{{  states.input_number.volume_radio.state  }}' 
    - service: media_player.play_media
      data_template:
        entity_id: >
          {% if is_state("input_select.chromecast_radio", "Lounge") %} media_player.lounge_speakers
          {% elif is_state("input_select.chromecast_radio", "Bedroom") %} media_player.bedroom
          {% elif is_state("input_select.chromecast_radio", "Office") %} media_player.chromecastaudio3249
          {% elif is_state("input_select.chromecast_radio", "Lounge and Office") %} media_player.lounge_and_office
          {% elif is_state("input_select.chromecast_radio", "House") %} media_player.house
          {% elif is_state("input_select.chromecast_radio", "Everywhere") %} media_player.everywhere
          {% endif %}
        media_content_id: >
          {% if is_state("input_select.radio_station", "Hit 92-9") %} http://ic6ti.scahw.com.au/6ppm_128
          {% elif is_state("input_select.radio_station", "Nova 93-7") %} http://streaming.novaentertainment.com.au/nova937
          {% elif is_state("input_select.radio_station", "Mix 94-5") %} http://sc01.scahw.com.au/6mix_32
          {% elif is_state("input_select.radio_station", "96FM") %} https://icy.ihrcast.arn.com.au/au_012_icy
          {% elif is_state("input_select.radio_station", "80's") %} http://19173.live.streamtheworld.com/T_RAD_80S_S01AAC_SC
          {% elif is_state("input_select.radio_station", "OldSkool Hits") %} http://sc01.scahw.com.au/loveland_32
          {% elif is_state("input_select.radio_station", "Old Skool Anthems") %} http://nebula.shoutca.st:8075/stream
          {% elif is_state("input_select.radio_station", "Raw FM (dance)") %} http://stream.rawfm.com.au:8004/;stream/1
          {% elif is_state("input_select.radio_station", "181FM Power (Todays Hits)") %} http://listen.181fm.com/181-power_128k.mp3?
          {% elif is_state("input_select.radio_station", "181FM 90's Dance") %} http://listen.181fm.com/181-90sdance_128k.mp3
          {% elif is_state("input_select.radio_station", "181FM Star 90's") %} http://listen.181fm.com/181-star90s_128k.mp3
          {% elif is_state("input_select.radio_station", "181FM The Breeze") %} http://listen.181fm.com/181-breeze_128k.mp3
          {% elif is_state("input_select.radio_station", "Heat Radio (RnB)") %} http://174.37.159.206:8106/stream
          {% elif is_state("input_select.radio_station", "Fresh 92-7") %} http://live.fresh927.com.au:80/freshaac
          {% elif is_state("input_select.radio_station", "DI Chill & Tropical House") %} http://pub1.diforfree.org:8000/di_chillntropicalhouse_hi
          {% elif is_state("input_select.radio_station", "DI Disco House") %} http://pub1.diforfree.org:8000/di_discohouse_hi
          {% elif is_state("input_select.radio_station", "DI Funky House") %} http://pub1.diforfree.org:8000/di_funkyhouse_hi
          {% elif is_state("input_select.radio_station", "DI Liquid D&B") %} http://pub1.diforfree.org:8000/di_liquiddnb_hi
          {% elif is_state("input_select.radio_station", "Aloha Joe's Relaxation Island") %} http://s2.voscast.com:7932/
          {% elif is_state("input_select.radio_station", "Spectrum Fit") %} http://51.255.235.165:5292/
          {% elif is_state("input_select.radio_station", "Energy FM Australia") %} http://s3.viastreaming.net:8502/
          {% elif is_state("input_select.radio_station", "Jazz Relax") %} http://199.195.194.94:8036/stream
          {% elif is_state("input_select.radio_station", "Australian Country") %} https://streaming.radio.co/s5ea3fdd1c/listen
          {% elif is_state("input_select.radio_station", "Rebel FM") %} https://au1.fastcast4u.com/proxy/rblgc?mp=/stream
          {% endif %}
        media_content_type: 'audio/mp4'

so you can see that the input_select ‘friendly’ name is used in the service call data_template

3 Likes
13

Yes, it only accepts level1, level2 and level3 as a valid fan speed. Displaying those values in the UI as an input_select to change the speed is not very pretty, therefore the friendly_name.

Mine was a proposal as well. It didn’t get the other feature requests “desire” in having a option (which already shoudld be the “value”) and then having a seperate value again. Which one would then be used as the input_select’s actual state?

So your entity accepts those firendly names, that’s the difference to my dilemma.
My fan doesn’t accept the friendly names. Therefore I want to display them differently in the UI. I really can’t describe the problem much better, I’ve written it down in several ways above.

But here again:

I’ve got a fan, which accepts the speeds “level1”, “level2” and “level3”. I want to change those speeds in my UI. Therefore I want an input_select, with my 3 different speeds. I don’t like them displayed as “level1”, “level2” and “level3” but rather as “low”, “medium” and “high”.

I would then have an automation which would set the fan speed depending on the input_select’s state. Currently I’d have to map those “low”, “medium” and “high” values to “level1”, “level2” and “level3” respectively inside the automation before I’d be able to set the fan speed.

Therefore, if it would be possible to set a different display_name/firendly_name for an input_select option, I would have a friendly name being displayed in the UI and the correct value/state being set inside my automation without to manually map the values around.
And all of that (probably) without causing a breaking change.
.

14

thats why I’m saying to use template sensors to create ‘friendly’ names that will be accepted by the fan. template sensors ‘follow’ the state of another sensor. did you read the doc I linked to earlier? it literally tells you how to do exactly what you need

15

it’s getting late here so i’m off to sleep but i can write the code for you in the morning if you post your entities, the names you want are already in the first post so it shouldn’t be too hard

16

Now I get you. I have plenty of template sensors, so I didn’t read it as I already know them. Your solution would be a workaround, just like mapping the values in the automation. There are lot’s of ways to do this, but I think the best/cleanest way would be to be able to set those firendly_names for input_select options.

1 Like
17

If expressed as a list, the following in YAML

Low, level1

is equivalent to this in JSON:

["Low", "level1"]

Therefore the source code would use the list’s first item (actually it’s the zeroth) for display in the UI. The optional second item would be for use in automations, etc.

The use of a list to represent the name and (optional) value allows it to retain the current familiar appearance when no value is supplied.

With values:

- Low, 35
- Medium, 65
- High, 100

Without values:

- Low
- Medium
- High
18

a work-around only because your particular hardware is not allowing the use of other names. I get your point, but i guess it’s something that very few people would ever need, since in almost all situations we can use whatever item names we want in our input_selects

19

Yes, that solution would aslo be feasable I guess. Nevertheless I think having a seperate “name” looks cleaner.

20

Yes, sure. I don’t say it’s a must have feature