I need this use case all the time and see it often in the community: Sensors with custom states that stay persistent during a restart.
What I see most often is that people use a text input to store a state and then derive a template sensor for that to display it or use it in automations. What I do is to use variables.
WTH is this not a thing in HA core? Call it variables, custom sensors or whatever, the use case is there.
Update as it is unclear for some what I want to propose:
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 and stays consistent 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
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.
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.
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:
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.
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).
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.
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.
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ā¦?
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.
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.