Does the saved data survive restarts?
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.