WTH are there no Variable Entities in HA?

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

[123 (Taras)]

@FPro

Template sensors restore its state after the template renders which takes some time so their state is inconsistent in the recorder

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

.

[FPro (Florian)]

@CentralCommand

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.

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.

[123 (Taras)]

@FPro

The whole solution is not streamlined, especially for beginners

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.

@FPro

The last time I used a trigger sensor … didn’t restore its state

Must have been a long time ago.

Restore state of trigger-based template sensor

[FPro (Florian)]

@123

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.

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.

@123

Must have been a long time ago.

Yes, I stopped using those sensors after that experience. Scratch that point.

[123 (Taras)]

@FPro

one could make a specific action for that, then there is no need for a service call.

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.

@FPro

You only need states() in templates. In the automation UI there’s no need for that.

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

[FPro (Florian)]

If you have a better and user friendly solution, I’m happy to hear about it

[123 (Taras)]

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