WTH are there no Variable Entities in HA?

[FPro (Florian)]

@123

What kind of sensors?

See my example in the post above.

@123

For example, the state of a Trigger-based Template Sensor is restored on startup.

The last time I checked this was not the case.

[FPro (Florian)]

@sparkydave

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.

[123 (Taras)]

@FPro

The last time I checked this was not the case.

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:

Trigger on Washing Machine finish

Here’s something simple that you can experiment with and enhance. - alias: example 1 trigger: - platform: numeric_state entity_id: sensor.washingmachinepower above: 500 for: "00:01:00" action: - wait_for_trigger: - platform: state entity_id: sensor.washingmachinepower to: 0 for: "00:00:05" - service: persistent_notification.create data: title: "{{ now().timestamp() | timestamp_local() }}" message: "Washing is done." How it works: It…

[farmio (Matthias Alphart)]

@FPro

If you want to display that nicely in your dashboard you’d need to derive a template sensor from your input select.

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

[FPro (Florian)]

@123

I also use a Template Sensor to report the current operating phase of a washing machine cycle. It reports the correct state on startup.

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.

@123

If you’re interested, refer to the “Washer Monitor” section in the following post:

What you are doing here is exactly what I want to avoid: use 2 entities for something I could solve with just one.

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