I agree with you that setting/getting values is equally important. For the moment, input_text works reasonably well:
states() to get and
set_value to set plus
reload to initialize. Life is good until one bumps into the 255 character ceiling. This can happen when you use an input_text to store comma-delimited lists. However, I do realize this ceiling isn’t likely to be raised any time soon because it has widespread implications.
If an input_text supported attributes and provided a service to set them, well, that would be very useful. However, I’m not sure how that fits into an input_text’s ‘job description’. For simply capturing a user’s input via the UI, you don’t need custom attributes. However, allowing for custom attributes would be a quick and dirty way to improve an input_text usefulness as a ‘global variable’.
As for the input_select, aside from the fact new options are discarded after a restart, it’s impossible to set new options dynamically. Yes, the documentation shows an example of how to set new options “dynamically” with a list but that’s hardly “dynamic”. The list is pre-defined in the automation. To be truly dynamic the list would need to be generated by a template … but Jinja2 can only crank out strings not lists. The workaround is to write a simple python_script that sets the new options … but that’s a step too far for many users.
Ideally, an input_select’s
set_options service would accept a comma-delimited string as an argument (and is converted to a list internally). At least then we would have a truly dynamic way of setting options using templates. Of course, this doesn’t address the issue of losing the new options after a restart.