WTH are there no Variable Entities in HA?

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

Would a number helper do the job for you? Or do you need it to be like a constant (not user-changeable)?

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. :man_shrugging:

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 :wink:

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.