Create a constant

[stone]

whats the best way to create a constant?
ie: in climate i want to set the temperature as one constant value, then refer to that constant entity_id in all my other scripts and automations. so i when i want to change it, its only in one spot.

[datamonkey (Roland)]

Not sure this would work, but can you use a !secret to refer to a value that you store in the secrets file?

Not sure you can use !secret in a template, but worth trying…
Or maybe just a template sensor that you load with a number.

[Tinkerer (aka DubhAd on GitHub)]

What about using an input slider? Couple that with templates, and you should be able to achieve what you’re after.

[gpbenton (Graham)]

How about a command line sensor that reads the value from a file.

You could then change the value in the file without having to restart HA.

[ariel]

@stone did you find a way to do this - if yes can you share what you ended up implementing?

I have a similar need: I want to be able to create a simple constant at the top of my configuration.yaml that I will later refer to multiple times.

Example:

weekday_wakeup_time = "06:30:00"
weekend_wake_time = "07:30:00"

Then I have multiple automations that would use these constants e.g. in “at” triggers, and also notifications etc.

Currently I have to repeat 3-4 times the same ‘constant’ value, once in each automation, and inside some notifications, and every time I need to change it, I need to touch 3-4 places, which is an issue (easy to miss some of the instances).

Any advise on how to handle this use case would be great - thanks

[stone]

i ended up using the secrets.yaml to store my constants. then just use the !secret some_constant in my other yamls.

[ariel]

Thanks! I had the exact same idea! and then I thought maybe there was a cleaner to handle this use case, e.g. !constant or !macro or some other similar mechanism that would allow defining this in a different file

I’d be surprised there hasn’t been an ask to support this use case before, I still have some hope there could be a better way. Maybe using Jinja but without having to use templates everywhere and lots of overhead for a simple thing

If not better idea comes up I will give the !secrets approach a shot

[Mutt (Muttley)]

You could just create a sensor,
feed the sensor the value you want and off you go
To be honest I’d just use an input_number and if you don’t trust your user base set the low limit to equal the high limit.
That way the way I use variables is standardised.

Both would require a restart though if you ever needed to change the value.

[ariel]

@Mutt thanks. I see - in my use case I could use an input_text sensor to store the text string.

I see other people explored the same, for reference:

Time automation with input_text

hi all, trying to configure timer for several switches. each switch will have enable timer schedule toggle with input time for ON and OFF booleans, using input_text boolean. # timer 1 input_text: on_timer: name: ON timer initial: '16:00' pattern: '^[0-9]{1,2}:[0-9]{1,2}$' off_timer: name: OFF timer initial: '18:00' pattern: '^[0-9]{1,2}:[0-9]{1,2}$' input_boolean: on_timer_active: name: Activate On timer initial: off icon: mdi:calendar off_time…

The drawback would be that I’d have to change all my automation time triggers to something more cryptic like

   trigger:
      platform: template
      value_template: "{{ states('input_text.weekday_wakeup_time') == states('sensor.time') }}"

The resulting config will some extra boilerplate but this approach has much more potential. I.e turn on the coffee machine 10 minutes in advance, turn on/off some lights a few minutes after, etc

[ariel]

FWIW I ended up using two input_datetime variables, with the thought that they are easier to expose as ”inputs" in the GUI (as opposed to input_text), which I also ended up doing.

This is how the triggers look like:

trigger:
      - platform: template
        value_template: '{{ states.sensor.time.state ==
states.input_datetime.weekend_wakeup_time.state[0:5] }}'

In Messages (GUI notifications, emails) the same approach applies.

[Mutt (Muttley)]

All Valid and good options to list, for the next guy to visit this thread.
In fact I’m thinking about how I could use this …
Cheers

[Markus99 (Mark)]

I’ve been using this and it works AWESOME.

rogro82/hass-variables

You can easily create variables and update as you see fit - and set them to be ‘remembered’ across restarts.

[NYSteve (Steven Abrams)]

Still getting my feet wet in HA but it seems that this is a specific version of a very general problem with Home Assistant, namely duplication of literal values throughout the configuration files. I’m hoping I’m wrong and that there is a good general solution to this, but I’m finding that if I want to do something that sets or depends on (eg) the current activity in my Harmony Hub, or the current source on my Vizio, or the current input on my receiver, or the Spotify source list, I’m doing it based on a string literal. And it this seems pretty fragile to me. Am I missing something?

[Markus99 (Mark)]

Happy to try to help, but would need more information.

HA is really based on setting up integrations (which you’re doing it sounds like) and then leveraging Automations and/or Scripts to ‘work with’ these integrations to do things.

Being able to grab ever-changing values of different entities w/in various integrations is the heart of automating TBH.

Personally I’ve been running HA for almost a year and, beyond some breaking changes w/ version upgrades and underlying integrations changing APIs and the like, I’ve found HA to be extremely stable and reliable. If you have an example or something more specific - the community is typically happy / eager to help.

[NYSteve (Steven Abrams)]

Thanks for the help. Let’s dig into one of these examples.

I have a template sensor that returns the value of my Harmony Hub’s current activity. This lets me do lots of things based on the current activity.

For example, I have a vertical stack card which includes picture-glance card for my basement media setup; it has a state_image that is based on the current activity. I have other cards in the stack that are conditional on the current activity, eg to put up the right buttons for that activity. These conditions are all based on the string returned by the Harmony - like “Watch TV” for example. That’s the string that literally appears in the Harmony app.

Now imagine that I decide to change the string that appears on the Harmony app to be longer, shorter, friendlier, whatever. Maybe my wife says that “Watch TV” is confusing because it’s all TV - it should say “Watch Fios.”

I’m pretty sure that if I do this, all of my code breaks. I think there ought to be a table or something that maps between the user facing strings and state values that I use in the code. I hope there’s a way to do this.

(I had a thought for how to put this indirection in the sensor itself with a bunch of conditionals, but that seems kludgey.)

Does that make sense?
~Steve

[frits1980 (Frits)]

So, you change a state value to something else. And you suggest a state value should have a state value uid to always stay the same no matter what value you decide to give it? This sounds logical, but the question is, what is more work to maintain?

[NYSteve (Steven Abrams)]

Well the specific problem here is that the state values and the user presentation of the state values are the same. Entities have an entity_id that is distinct from the friendly name. But certain states (Harmony activity names, and I think the input names on tv’s and receivers, for example) have IDs that are the same as the user facing names. I feel like there are other places where I’ve encountered this situation in HA but can’t recall where.

And honestly, typing YAML that’s the equivalent of "if x == “Some String” just seems wrong…

[frits1980 (Frits)]

Thank you for elaborating. Though again I ask myself, what would be more time consuming?

[Markus99 (Mark)]

You could create duplicate template sensors, one w/ your ‘pretty’ name and another with ‘static’ names and leverage the latter for your conditions and such. You could also just get a text editor like Atom and do find/replace in all files. You could also tell your wife that she’s just has to live with whatever name you give the states…

[NYSteve (Steven Abrams)]

@frits1980 - if there are lots of scripts that depend on those state names then it would be way easier to make the change in one place - where the mapping is established - than everywhere. This kind of indirection is, of course, common in many systems.

@Markus99 - your suggestion was exactly my thought for how to put this indirection in the sensor itself with a bunch of conditionals. I think it’s a bunch of if statements like ‘if the state is “Pretty Name” then the sensor value is symbolic_name’ which is an odd form of a map.

I think what I’m starting to realize is that while HA is amazing in its scope and flexibility, the YAML decision is weird. It’s may be too technical/geeky for “lay people” and not as expressive as something imperative or procedural.

I may also look into YAML templating solutions; wondering if anyone has applied these in HA?