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.
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.
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.
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.
Thank you for bringing this to my attention but this is yet anoter workaround additionally to those 2 I already posted.
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
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.
see my solution or fes’s, both do this.
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.
(for both mine and fes’s)
(for mine, fes’s would have an issue with this since it’s actually using attributes)
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.
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).
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.
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.
see my solution or fes’s, both do this.