WTH are there no Variable Entities in HA?

[123 (Taras)]

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.

Why the heck don't we have global variables?

Not the faux global variables implemented by various custom components but first-class citizens of Home Assistant. We should be able to define a global string, integer, float, list, dict. Even just a string that holds more than a mere 255 characters would be appreciated. The state of global variables would be saved on shutdown and restored on startup. That’s not asking for a lot considering what kind of global variables can be defined in another home automation system (that’s now 20 years old)…

[FPro (Florian)]

@farmio

Is that because you want a read-only entity to show in your dashboard?

Exactly - this is the essence.

[123 (Taras)]

@FPro

I don’t have a template to render so there’s nothing to restore.

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?

@FPro

what I want to avoid: use 2 entities for something I could solve with just one.

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).

[FPro (Florian)]

@123

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?

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.

@123

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.

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.

[123 (Taras)]

@FPro

With my concept you just need one entity

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.

[tom_l]

There are also changes coming to the input select helper that may be of use. Select helper with label and values

[sparkydave (🇦🇺 Dave)]

@FPro

Yes, but this is a workaround.

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…?

[FPro (Florian)]

@123

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.

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.

@sparkydave

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…?

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.

[tom_l]

@FPro

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:

WTH can't input helpers be read only in UI

This is old feature request but still very valid WTH. Using custom cards (often with YAML) to get similar UI graphics (calendar, slider, toggle etc) is not the most user friendly option

[FPro (Florian)]

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.

[sparkydave (🇦🇺 Dave)]

@FPro

You can’t cleanly display a input select in a dashboard the way you would with a sensor.

Yes you can…

This is an input_select

[FPro (Florian)]

Depends what kind of cards you are using.

[sparkydave (🇦🇺 Dave)]

That’s a standard core card. I literally just created for the sake of this thread.

[FPro (Florian)]

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.

[CentralCommand (Mike)]

You can fully replicate variables with a trigger template sensor. Posted here how:

WTH can't input helpers be read only in UI

Yes. I you can use a trigger template sensor like this: template: - trigger: - platform: event event_type: set_my_sensor sensor: - name: My sensor state: "{{ trigger.event.data.state }}" And then you can change it in a script or automation like this: action: - alias: Update my sensor event: set_my_sensor event_data: state: new_value Can even add attributes if you want, just pass more data in the event and use it in attributes in the sensor config. Plus trigger template …

[123 (Taras)]

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.

[CentralCommand (Mike)]

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.

[123 (Taras)]

In summary: Ditto.

[FPro (Florian)]

@CentralCommand

You can fully replicate variables with a trigger template sensor.

Thank you for bringing this to my attention but this is yet anoter workaround additionally to those 2 I already posted.

@CentralCommand

I want to avoid having to dig through automations to try and figure out how something got into the state it’s in.

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

[CentralCommand (Mike)]

@FPro

A separate entity that I can easily create from the UI as a helper.

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.

@FPro

This entity (and possibly attributes) can be easily set from the UI with a custom state

see my solution or fes’s, both do this.

@FPro

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

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.

@FPro

The entity behaves in dashboards like a sensor (read only)

(for both mine and fes’s)

@FPro

The entity can be customized like a sensor (e.g. unit of measurment)

(for mine, fes’s would have an issue with this since it’s actually using attributes)

@FPro

I want a streamline of the experience and am perfectly aware that there are workarounds to partially achieve this

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.