Hi, How can I populate an input select list dynamically?
For example, I want my input select list to show all switches as the options (or their friendly name)
2 Likes
I am looking for the same thing. I am trying to populate an input_select with all available DLNA players.
I can get these into an HTTP sensor, but I think I need a foreach function within HASS, to take that list/array and use it to populate the input_select.
I know it’s many years on and I may have come to this late in the day but I have still not found a simple method of programmatically maintaining dynamic dropdown lists within HA.
I resorted to using the HA rest api in python.
assuming a valid long lived token this works for me.
from requests import get,post
apitoken = 'xxxxx'
apiheaders = {"Authorization": "Bearer {0}".format(apitoken), "content-type": "application/json",}
entity = 'input_select.myselect'
ENDPOINT = 'api/services/input_select/set_options'
optionlist = ["option1","option2"]
DATA = {"entity_id": entity, "options": optionlist}
response = post('http://homeassistanturl:port/' + ENDPOINT, json = DATA, headers=apiheaders)
which I use encapsulated in a python library to be called by functions that need to dynamically update a dropdown in the ui.
It is very fast to update.
One of the ways I use this is to populate dropdowns of remote controls and associated keys (from a database) to allow manual sending of IR and RF codes (via tasmota bridges) by selecting their function rather than hex code.
I know it isn’t HA-native but gets around a very poor implementation of these UI elements.
You’re only making it hard for yourself. You can simply just use a service call in an automation…
- service: input_select.set_options
data:
entity_id: input_select.myselect
options:
- option1
- option2
2 Likes
not really, your example does not solve dynamically populated lists. If you follow other threads you will see many monstrous templating efforts, none of which resolve a simple load from a dynamic list.
Your example isn’t dynamic either… the 4 lines I provided is identical to your script
Also, I noticed that your importing which isn’t available in python_scripts. So your example doesn’t really help the thread or hassos users.
FWIW, while attempting to use an input_select as a global list variable, I learned you can dynamically assign whatever options you want but they are all lost after a restart.
Upon startup, an input_select is not initialized with its last-assigned options (because those options are not saved to storage) but will be reset to its default options. In addition, you can’t define an input_select without at least one default option.
1 Like
Yes but the idea is that you’re solving this with an automation. So you just need to add a home assistant startup trigger that performs the same calculation.
For the application I was working on, the input_select’s options are not known in advance (they become known later, if ever). Therefore one would not be able to assign them to an input_select on startup.
Seems like a feature request then! Now that they are helpers, I don’t see why it couldn’t update the config_entry
Not so, Your example sets static values in configuration. Mine interacts programmatically, and changes options dynamically - in my case against a mysql database.
I apologise for being unhelpful to hassos users. I’ll delete myself from the forum, saving you the effort
I see you’re upset, but I’m just pointing out that verbaitum the example you posted can be done without a script. This is what you’re passing to the service:
optionlist = ["option1","option2"]
which is a static list.
No where in your example is it dynamic, which is why we are having this conversation…
The point is that the option list can be the result of a mysql query or a TSDB query or any other data source which can feed the list dynamically. A click on an item in one dropdown can be made to cause an update in another one.
I have tried your suggested method to do this without success.
I made a mistake by putting my musings in a post. No worries.
1 Like
I don’t think you did, but I do think it would be better as a stand alone thread with a detailed explanation. The users that find your code helpful aren’t going to be looking for a revived 3 year old configuration thread. They’ll be cruising the share your projects or developers.
1 Like
I’ve been searching for time to figure out how to dynamically set the input_select option list. In my case the values come from MQTT as a rtl_433 process finds new tire sensors. My goal is for the user to be able to select which sensor is the front left tire, etc.
Can you expand (ie example) on how you defined the global list variable and how the input_select used it?
I have nothing to share because what I had created, three years ago, couldn’t survive a restart.
Nowadays you can explore using MQTT Select to meet your needs.
I don’t know your exact requirements but the following post contains examples for Template Select which might also meet your needs.
Standard sensor attributes survive restart, so in theory you can get this done with a template entity. IIRC @TheFes created some hacked away template entity that stores global variables in a WTH a number of years ago.
I actually wrote a post about that sensor yesterday
1 Like
I’m not sure the original question was answered so here is what I just came up with:
script:
populate_input_select:
mode: queued
alias: "Populate the Input Select TEST"
sequence:
- service: input_select.set_options
target:
entity_id: input_select.ma_players
data:
options: |
[
{% for entity_id in states.media_player | map(attribute='entity_id') if 'ma_' in entity_id %}
"{{ states[entity_id].attributes.friendly_name }}"{% if not loop.last %}, {% endif %}
{% endfor %}
]