Yes, I’m currently exploring the use of an input_select to store timer information. Each option in the input_select stores one timer’s information. An input_select has a set_options
service but, for this application, an automation cannot be used and it will have to be a python_script.
The reason is because we have to dynamically build a list for set_options
. A Jinja2 template cannot generate a list, it always generates a string. A python_script doesn’t have this limitation.
Unfortunately, there is no service call to retrieve an input_select’s options as a list UPDATE:
There’s no service call but all the options are indeed available as a list in the input_select’s attributes!
That makes it very easy to iterate through all the options and requires none of the techniques I mentioned below.
(which would make it easy to iterate through its options). In addition, there’s no way to request the number of options. The best that it offers is a next_option
service to step through the options. However, without knowing how many options exist, we can step through all of them over and over.
The simplest trick is to have the last option serve as a marker. In other words, the last option is never timer information but something like '###'
. If one encounters it while stepping through the options, it indicates we have finished iterating through all available options.
I’m currently experimenting with this approach. I can easily create an input_select with 50 options. That means it is capable of storing the information for 50 timers (and up to 255 characters for each one). There may be an upper limit on the number of options supported by an input_select but I doubt anyone will ever encounter it.