Create a constant

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.

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

I’ve been using this and it works AWESOME.

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

1 Like

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?

1 Like

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.

1 Like

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

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?

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…

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

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… :man_shrugging:

1 Like

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

1 Like

As far as the usefulness of constants, here’s one place I’d normally use a constant, and I’m curious what you guys would recommend for HA YAML.

So I have motion sensors in our bathrooms to turn on/off the lights. Cool. But when you get into the shower and close the door/curtain, the sensor no longer detects motion and turns the lights off. Now you’re showering in the dark. Not cool.

My current solution to this problem is to put a humidity sensor near the shower. Then add a condition to the “Lights Off” automation that it only activates if the humidity is below a certain value. No more unhappy wife. But… I’m still experimenting with exactly what value to use as the humidity trigger.

Especially considering I have multiple bathrooms that use this humidity value, instead of coding a literal value (i.e. magic number), I’d normally define a constant for this… but I don’t see a way to do that in HA YAML.

Example:

- id: 'spam'
  alias: Motion Lights Off - Master Bath
  trigger:
  - entity_id: binary_sensor.master_bath_motion_sensor_motion
    for: 00:02:00
    platform: state
    to: 'off'
  condition:
  - below: '65'
    condition: numeric_state
    entity_id: sensor.master_bath_humidity_sensor_humidity
  action:
  - data:
      transition: 5
    entity_id: light.master_bath_lights
    service: light.turn_off

In the above example, I’d love to be able to define a constant for the “65” and maybe even for the “5” on the transition to make tweaking things easier when those values are used in multiple automations. Suggestions?

Use an input_number.

Thanks! That seems to work well. From reading about how to use input_number , it sounds like you can’t just put that in the below or above field; using a template seems to be the way to do it, right?

Example:

  condition:
  - condition: template
    value_template: '{{ states("sensor.master_bath_humidity_sensor_humidity")  | float 
      < states("input_number.humidity_threshold_shower") | float }}'
1 Like

Yeah, that’s how to do it :+1:

Hi,
I suggets to deine a binary_sensor and use the sensor state as condition.

Example:

  • platform: template
    sensors:
    humidity:
    friendly_name: “BathHumidityLightLevel”
    device_class: none
    value_template: “{{states(‘sensor.bath1_humidity’)|float>60
    or states(‘sensor.bath2_humidity’)|float>60}}”

Can i also update that static number through automation?

Thanks exactly what I was looking for!

Simple Const idea

input_text:
  my_const:
  initial: 'required_value'

I’ve read through this chain and checked out a few others but remain unable to find a solution to my goal of using constants in Lovelace cards, As an example here is a Gauge card for rainfall:

type: gauge
min: 0
entity: sensor.rainfall_month
name: Month
needle: true
severity:
  green: 2.5
  yellow: 4.5
  red: 6
max: 8

This gauge is repeated a couple of times in other places so if I decide that I want to change the min/max or severity values I need to edit each instance. I’ve tried the suggestions described earlier but either they don’t address this instance or I am not implementing them properly. Any thoughts are appreciated.
Ron