It will: variables are saved to disk.
Yes 
values are restored after restart of HA
1 Like
Erm !
I use an input select for my waste collection cycle, i had to modify it ‘once’ because there are 4 states in the cycle and one of them repeats so on a restart it didn’t know which option was selected so the following one was not always correct.
I made them unique and have never had a problem since.
Not sure if this is an exception but it works for me in my use case.
Maybe I’m missing your point ?
## bins for collection
is_bin_day_bins:
name: Bins For Collection
options:
- Blue & Green
- Grey & Green
- Black & Green
- Green & Grey
icon: mdi:trash-can-outline
In fact I also use them for storing the alert “Day Of The Week” (DOW) the collection DOW and the reset DOW, they all work fine in surviving restarts.
Maybe you mean using them to store non-predefined values (on the fly ???)
Yes, that’s the deficiency I described in greater detail in my 3rd post:
In a subsequent post, I elaborated that it’s not even possible to truly set the options dynamically. The set_options service expects a list but you can’t generate a variable-length list with a template. The workaround is to use a python_script to do it.
So how would people want to see this work ? It’s important to know that we cannot have functions available in templates to store variables because rendering a template cannot have a side effect. They obviously would be able to access it.
Have a script action:
action:
- variables.store:
key: my_var
type: datetime
value: >
{% if is_state("sun.sun", "above_horizon") %}
{{ states.input_datetime.something_1.state }}
{% else %}
{{ states.input_datetime.something_2.state }}
{% endif %}
If the value does not match the type, it would stop the script there with a fatal error.
And then in a template you can use:
{{ variables.my_var }} (this would be datetime object)
While it might be slightly easier to have real defined data types I don’t see why that would be important since we already have the availability to convert between different data types. Just keep everything as a string and do the conversions in the templates just as we do now.
When you currently access an entity’s attributes, its values can be stored as either string, list, dict, integer, or float. No conversion is currently needed to access them and that’s an advantage because it simplifies access.
It’s only values in state that are exclusively strings. So if you want them to hold an integer, float, list, or dict in it, conversion will be required. Why would the overhead of performing type conversions, for global variables, be an advantage?
I thought he was suggesting giving the state of the variable a specified data type to head off data type mismatch errors in templates. At least that’s what it looked like in the code example. If I misread it then never mind.
but yes I really don’t care what data types the attributes are. Or even the states for that matter.
My understanding is that the example is demonstrating how to save a datetime object to a global variable. Currently, there’s no way to do that with a template because they always produce strings.
The example does use a template, which gets the input_datetime’s state (a string) and reports it as a string. However, the storage process converts the string to a datetime object (or fails if the supplied string is not in any valid date and time format).
After saving it, you can use the value as a datetime object, without the need for the usual gymnastics for handling date-and-time-as-a-string.
It will let you dynamically create and store lists and dicts. That’s not something you can do now unless you use python_script.
Yea that looks great to me. Would you have to declare variables in advance as part of config or can you define them on the fly with actions?
Also as stated persistence over a restart is a key requirement. Not that your suggestion prevents that just wanted to make sure that was captured as a requirement since it’s key.
Just define on the fly is fine. Can be persisted yeah.
3 Likes
I’ve been thinking about this one for last two weeks and I think I’ve actually have come across use cases for myself (where I now use input_* entities).
However, I’m starting to get the feeling that what is more needed is a bit of an overhaul of the input helpers. Their name suggests tight integration with the interface, which is of course also how they started. However, these two have grown apart (with good reason).
In essence, these global variables would replace input helpers and I think it makes more sense to view it from that angle, would it not? I think my confusion at least originated from there, since we are essentially implementing the same features (from a usability perspective).
To put it differently, if this is implemented, why would you ever use input helpers?
Your confusion if caused by the assumption the two have the “same features”. They don’t.
Global variables are not limited to having a string value and can be a list, dictionary, datetime object, float, boolean, or integer and don’t have a 255-character limit. They have no need to be displayed in the Lovelace UI (input helpers serve that purpose).
1 Like
That depends on what you expect from them I guess. I explicitly wrote that I don’t think they are that ‘attached’ to the interface anymore, only their name really harks back to the old days.
I’m trying to look at this from the perspective of an average user and my guess is that for them the distinction isn’t very meaningful.
All we really want to do is easily store custom, user defined data. We need several data types to effectively use it. Showing (and controlling) it in the interface is just one of the usecases, but there’s multiple. The fact that the input helpers can be used already, but that there’s a few issues and gotchas is pretty telling imho.
I just think you should be careful when there appears to be such a significant overlap. I’m not saying they are currently a good solution, I’m proposing to merge the two, since I think in the end there’s no difference. The bonus is that you can implement a few quick wins right away for instance (say extend the input_text beyond 255 characters) and that you have an easy integration with lovelace already if you want/need it.
Your comment reads like you haven’t read this entire thread.
I’m not sure why you are so abrasive and defensive, but that really doesn’t add anything but to unnecessarily insult me.
1 Like
You’re insulted because I believe your commentary suggests you didn’t read the entire thread?
1 Like
I have a few automations/scripts where some fairly complex code is done in a template. It would be nice to be able to store the output from the first code block instead of having to repeat the process if needed later, but that doesn’t seem possible from earlier posts (to set a variable from within a template).
Agreed input_text/input_number/input_boolean can be used, but I would like to see variables that are persistent through the same script/automation at the very least - even if not truly global to all of HA.
I should have just read the release notes for 0.115.
Just add them via customize as I did here: home-assistant-config/config/customize.yaml at acb58a2b9d6cec24d2c5f2e88548df155ed43352 · pedrolamas/home-assistant-config · GitHub