I’ll give you an example:
I have an energy monitor for my washing machine. Based on that I derive a state: Standby, Running, Finished or Off.
I need something to store, display and use those values. Currently you need workarounds to achieve this.
2 Likes
What kind of sensors?
For example, the state of a Trigger-based Template Sensor is restored on startup.
For that exact use-case I use an input_select and automations to choose each option based on the power consumption. I also have another one that uses a combination of a vibration sensor and door sensor to make the selection.
1 Like
See my example in the post above.
The last time I checked this was not the case.
1 Like
Yes, but this is a workaround.
Every other integration uses sensors for that.
If you want to display that nicely in your dashboard you’d need to derive a template sensor from your input select. And now you have to maintain 2 entities.
I don’t know when was the last time you checked but it’s documented:
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.
I have confirmed it’s true.
I also use a Template Sensor to report the current operating phase of a washing machine cycle. It reports the correct state on startup. 
If you’re interested, refer to the “Washer Monitor” section in the following post:
Is that because you want a read-only entity to show in your dashboard?
In order to do that you need to render a template. I don’t have a template to render so there’s nothing to restore.
What you are doing here is exactly what I want to avoid: use 2 entities for something I could solve with just one.
3 Likes
BTW, I didn’t mean to detail your topic for the addition of “variables entities”. In fact, I had posted essentially the same thing 2 years ago, for the first WTH event. It collected many votes but, unfortunately , it didn’t attract the attention of any developers willing to implement it.
3 Likes
Exactly - this is the essence.
1 Like
So you are using an automation to set a Helper (like input_select or input_text) to one of the four states (Standby, Running, Finished, Off)? Or are you doing it some other way?
Actually the reason I am using two entities is explained in the linked post (it’s due to the complexity/ambiguity of my washing machine’s reported power values); it could be done using a single Template Sensor.
FWIW, all sensors are displayed as read-only entities (Template, MQTT, REST, etc).
1 Like
No I am using a variable: GitHub - snarky-snark/home-assistant-variables: A custom Home Assistant component for declaring and setting generic variable entities dynamically.
The concept exists, I would just like to see it in core.
With my concept you just need one entity 
But I don’t want to get hung up on my washing machine automation. This is for everything where you need to store something that keeps persistent. Input helpers are not a clean way to do that in my opinion.
1 Like
If you’re using an automation to store values in a variable entity, based on home-assistant-variables, it’s highly likely it can be done with a single Trigger-based Template Sensor.
FWIW, home-assistant-variables has been around for awhile and is predated by the (no longer supported) hass-variables. Both store data using the same entity model all other entities in Home Assistant (state stores a 255 character string; attributes stores a variety of data types; everything is in Home Assistant’s state-machine). Neither was ever incorporated as an official integration. If there was ever a PR submitted, but rejected, it would be interesting to learn why. I’ll hazard a guess that there never was a PR submitted.
There are also changes coming to the input select helper that may be of use. Select helper with label and values
What is the difference between using an Automation to change the value of an input_select or using ‘something’ to change the value of a Variable…?
2 Likes
You might be right in the specific use case I posted but not in general. Furthermore I’d like to keep complex rules in my automations and not in a template. I know you want to solve the specific example I posted but there are many other use cases for me and possibly others.
That’s not the point. The point is in what kind of entity the information is stored in. You can’t cleanly display a input select in a dashboard the way you would with a sensor.
You may be able to if this gets attention:
2 Likes
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.