Would help to some extend. But it still wouldn’t be displayed as a sensor would. Things like device class, unit of measurment etc would be nice to set.
Yes you can…
This is an input_select
Depends what kind of cards you are using.
Take an entities card and you get a drop down menu.
And as I mentioned before this also doesn’t solve the lack of configurability of input helpers.
You can fully replicate variables with a trigger template sensor. Posted here how:
1 Like
Well done. 
However the topic’s author appears to have set personal rules about what should/shouldn’t be used. 
Furthermore I’d like to keep complex rules in my automations and not in a template.
NOTE
In my opinion, your creative use a Trigger-based Template Sensor addresses the main requirements of a “global variables” feature; it’s a means of easily storing/retrieving data that’s read-only in the UI and survives a restart.
1 Like
I mean if they are completely opposed to trigger template entities then fine, guess there’s nothing I can do about that. But I think my suggest is pretty simple, all the complex logic is in the automation. Literally all the sensor does is map fields from the event data directly into state and/or attributes. The final result is really not far off from the var.set service the custom component they linked uses 
Personally I don’t understand this stance on complexity though. After trigger template entities came out the first thing I did was refactor my automations to remove complex logic used to set helpers into trigger template entities which manage their own state. I want to be able to go to any entity in states and be able to easily determine exactly how it got there from the integration and/or config of the entity. I want to avoid having to dig through automations to try and figure out how something got into the state it’s in.
But that’s a separate discussion I suppose.
1 Like
In summary: Ditto.
1 Like
Thank you for bringing this to my attention but this is yet anoter workaround additionally to those 2 I already posted.
You’re all hung up too much on my example.
I will try to make myself more clear what I’d like to see:
- A separate entity that I can easily create from the UI as a helper.
- This entity (and possibly attributes) can be easily set from the UI with a custom state
- The state survises a restart. Template sensors restore its state after the template renders which takes some time so their state is inconsistent in the recorder
- The entity behaves in dashboards like a sensor (read only)
- The entity can be customized like a sensor (e.g. unit of measurment)
- I want a streamline of the experience and am perfectly aware that there are workarounds to partially achieve this
1 Like
Sure ok, can’t do this with trigger template entities right now. Although technically this solution @TheFes made qualifies. No yaml changes are required to add new variables.
see my solution or fes’s, both do this.
As has been said multiple times in this thread trigger template entities absolutely survive a restart. Template entities without a trigger work as you describe, trigger template entities do not. Directly from the doc:
The state, including attributes, of trigger-based sensors and binary sensors is restored when Home Assistant is restarted. The state of other trigger-based template entities is not restored.
(for both mine and fes’s)
(for mine, fes’s would have an issue with this since it’s actually using attributes)
ok. Well I mostly wanted to make sure everyone was aware that all the technical requirements can be satisfied currently. Including the restore state one that keeps getting incorrectly assumed to be unsatisfiable.
2 Likes
The state and attributes of a Trigger-based Template Sensor is automatically restored on startup. Can you show an example of the inconsistency that allegedly exists in its state history?
FWIW, there’s talk of implementing a “read-only” option for some helpers (input_number, input_text, etc) which would satisfy most of your requirements (except for setting attributes).
.
I am aware that this is technically achievable. The whole solution is not streamlined, especially for beginners. I don’t want to solve a specific problem but want to make suggestions how to make life in HA easier.
The last time I used a trigger sensor I used a webhook as a trigger and used the webhook JSON in the template. The sensor didn’t restore its state until the webhook was fired again. But maybe I am mistaken, then scratch this point from the list.
I feel that, for beginners, the complexity isn’t in creating the variable, it’s in knowing how to store/retrieve the variable’s value. What you’re proposing doesn’t simplify those steps for beginners; they will still need to learn how to use a service call, in order to store the value, and the states() or state_attr() function to retrieve it.
Must have been a long time ago.
As I said: “This entity can be easily set from the UI with a custom state”. Although I would be satisfied with a service call, one could make a specific action for that, then there is no need for a service call.
You only need states() in templates. In the automation UI there’s no need for that.
Yes, I stopped using those sensors after that experience. Scratch that point.
In Home Assistant, setting an entity’s state value is performed by a service call. It’s highly unlikely some new way of programmatically setting the state would be invented exclusively for a proposed Variable entity.
The Automation UI has little to do with it. If an option supports a template, then it can be used to retrieve the Variable entity’s value using states(). If the option doesn’t support templates then it typically supports only specific entity domains. What the option supports is governed by its underlying integration.
For example, the Numeric State Trigger’s above and below options support a numeric constant or an entity from the sensor, number and input_number domains. It doesn’t support templates so that means it would have to be enhanced to support the proposed variable entity.
Basically, the options of all triggers, conditions, and actions (that don’t support templates) would need to be enhanced to support the proposed Variable entity. That’s a non-trivial undertaking and a disincentive for developers (especially in light of the fact that there are existing ways of storing a value without creating a new domain type).
If you have a better and user friendly solution, I’m happy to hear about it 
See CentralCommand’s method posted above. Or the method by TheFes which offers the additional advantage of programmatically adding/removing variables on the fly. Both employ a Trigger-based Template Sensor and simply require the user to copy-paste the examples (the same level of skill and user-friendliness as sharing an automation).
1 Like
For a HA integration, I also wonder how you can write a variable and retrieve it again when a user restarts HA. I need it within an integration to be able to perform calculations correctly within every hour. I don’t want to create a dependency with another integration, templates, helpers or anything similar.
Then your only option is to fork the integration itself and add your functionality into it.