IF - ELSE clauses in template - and how to use when created?

I try to control my AC according to the outside temp.

Ihave undersatood that I need to create a template that defines the value and then use the value with the script to feed it to AC. YThe script part looks simple enough, and I have not inserted it into this question.

The following compiles OK in Developer tools/ Template editor:

{% if 0.1 > float(states('sensor.pana_mek_outside_temperature')) >-2.1 %} 
18.5
{% elif -2.3 > float(states('sensor.pana_mek_outside_temperature')) >-4.1 %} 
19
{% elif -4.3 > float(states('sensor.pana_mek_outside_temperature')) >-6.1 %} 
20
{% elif -6.3 > float(states('sensor.pana_mek_outside_temperature')) >-8.1 %} 
21
{% elif -8.3 > float(states('sensor.pana_mek_outside_temperature')) >-10.1 %} 
22
{% elif -10 > float(states('sensor.pana_mek_outside_temperature')) >-12.1 %}
23
{% elif -2.3 > float(states('sensor.pana_mek_outside_temperature')) >-14.1 %}
24
{% elif -14.3 > float(states('sensor.pana_mek_outside_temperature')) >-16.1 %}
25
{% elif -16.3 > float(states('sensor.pana_mek_outside_temperature')) >-18.1 %}
26
{% elif -18.3 > float(states('sensor.pana_mek_outside_temperature')) >-20.1 %}
28
{% endif %}

Yes, I have tried to study the docs, but as far as I have noticed, nowhere is told, what I should do with the code. Where should I put it to be used to automate things?

OK, I have found, that people have used in configuration.yaml in a structure like this:

  - platform: template
    sensors:
      temperature_HVAC:
        friendly_name: "Whatever"
        value_template: >-
        your code goes in here (probably)

… but after several hours of trying I’m pretty sure the code that goes through template editor, does not validate in configuration.yaml.

So,

  • Can anyone point out where lies the documentation which describes the process of testing with the template editor and then transfer it to live automation?
  • Of course I would be very grateful, if someone could point me the way how to do this
1 Like

Yes, your code goes there but it must be indented by two spaces:

  - platform: template
    sensors:
      temperature_HVAC:
        friendly_name: "Whatever"
        value_template: >-
          {% set t = states('sensor.pana_mek_outside_temperature') | float(0) %}
          {% if 0.1 > t > -2.1 %} 18.5
          {% elif -2.3 > t > -4.1 %} 19
          {% elif -4.3 > t > -6.1 %} 20
          {% elif -6.3 > t > -8.1 %} 21
          {% elif -8.3 > t > -10.1 %} 22
          {% elif -10 > t > -12.1 %} 23
          {% elif -2.3 > t > -14.1 %} 24
          {% elif -14.3 > t > -16.1 %} 25
          {% elif -16.3 > t > -18.1 %} 26
          {% elif -18.3 > t > -20.1 %} 28
          {% else %} 22
          {% endif %}
1 Like

Just two things to notice.

  1. In order for your configuration.yaml to take effect you need to restart HA. Just if you did not know that.

  2. The last else in your if section will also catch everything besides a temperature, such as unavailable, errors and so on, which means you might end up heating up the house in the sommer.
    Its better to avoid the else statement and then just make a elif statement more with a ridiculous low temperature at the low end.

OK, thanks 123 Taras and WallyR for pointing me to right direction (btw, how do you make a “mention” here? Just linking to a profile?)

123 Taras
Very elegant solution using auxiliary variable, I thought that also myself, but because it is easy to copy and paste, I did not bother :slight_smile:

WallyR

  1. Yes, I know that, however I was just trying tio get this throught the validator first
  2. The last else actually was not there, it just got included in the response, I see. Anyway, this seem to work such way, that if case is covered by any condition, the value keeps unchanged, what I actually want it to be. E.g., “summer values” with temps > 0 are not covered, so control does not set anything for this situation. What comes to those decimal limit values for each if, it is just plce holder for fiddling with hysteresis, if needed. Probably not, because I get values from HVAC in 0.5 deg resolution, so hysteresis is somewhat automatically covered.

First I was looking for some kind of switch/ case -structure, but seems to be that that jinja2/ python does not support it at all? Neither are familiar to me.

Few notes:
That “>” or “>-” I also noticed on some examples, obviously meaning that several lines of code follows. however I could not find documention about it. There are these 2 versions I could find; “>” and “>-”. Which is to be used in which conditions?

Even my first code compiles according to Configuration → Server Controls → Configure Validation after inserting “>-” AND changing sensor name “temperature_HVAC” to something I have used before, e.g. weather_temperature. New sensor needs to be initilalized somewhere?? I thought it would be done here in the configuration.yaml automatically?

If and when I need a new sensor called temperature_HVAC (or anything else, if that matters), where do I present/ initilalize it?

don’t even bother learning it, the - removes whitespace which is already done by default in templates on home assistant. Just use > everyone who uses >- is just copying from others who used it.

Secondly, I think there’s a flaw in your template logic. Are you trying to just truncate every 2 degrees to a specific value? Currently your template has a lot of holes in it. You’ll get 22 at every increment of even number that has a remainder of .2.

Like said, “holes” are reservations if hysteresis is needed, assuming also that the HVAC does not change it’s set value if none of the if clauses cover the measured temperature.

Trying to avoid the set value oscillating too much.

You are also referrring with that “22” to that else in the end? If you take a look of the original code in the first post, it was not there…

Or execute Configuration> Server Controls > Reload Template Entities

Actually, I added the final else because the author’s example lacked one. There are, as petro mentioned, holes in the coverage so without an else the original template would fail to report a numeric value. Ideally the coverage should be corrected (but I’ll leave that to the author).

2 Likes

Right but you’d need to have a returned value for those values otherwise the result will be ‘unavailable’. 123’s logic added in that value. So if you’re ok with the unavailable, then by all means, use it.

1 Like

OK, it’s the correct way of doing things not to let anything undefined, so I need to format the code. As said, there is a 0,5 deg resolution in how the HVAC reports the the temps, so hysteresis is somewhat automatically covered there anyway.

However, there is this one important aspect left:

Even my first code compiles according to Configuration → Server Controls → Configure Validation after inserting “>-” AND changing sensor name “temperature_HVAC” to something I have used before, e.g. weather_temperature. New sensor needs to be initilalized somewhere?? I thought it would be done here in the configuration.yaml automatically?

If and when I need a new sensor called temperature_HVAC (or anything else, if that matters), where do I present/ initilalize it?

How should this be done?

Did you mean to say Check Configuration?

If you created/modified an entity, that command confirms there are no syntax errors. It doesn’t load any of the new/modified configuration.

A restart will, obviously, reload everything but you can also selectively reload entity domains. Go to Configuration → Server Controls and the lower portion of the page lists everything that can be reloaded individually (assuming you have enabled Advanced mode for your user account).

Yes, we are talking about the same thing. In the panel where the “Check configuration” button is, it says “Configuration validation”

And yes, I have used that to check the syntax. However, the problem is that if I try introduce new sensor (I believe it is sensor), e.g. “temperature_HVAC”, it does not pass the validation. If i put something else instead, e.g. " weather_temperature" which I have used before in this:

  - platform: template
    sensors:
      weather_temperature:
        friendly_name: "Temperature"
        unit_of_measurement: 'degrees'
        value_template: "{{ state_attr('weather.huoltom_a', 'temperature') }}"

…it passes the validation.

Anyway, because of this I have not restarted server, nor reloaded templates or such, of course, because the new code does not validate…

Ok, if the else statement should be included, then I suggest looking into turning the list around, so the else-statement will be in the other end of the scale.

Try to add “sensor hvac:” above the -platform line without indentation.

E.g. like this:

temperature_HVAC:
  - platform: template
    sensors:
      temperature_HVAC:
        friendly_name: "Garage_hall_HVAC"
        unit_of_measurement: '°C'
        value_template: >-
          {% set t = states('sensor.pana_mek_outside_temperature') | float(0) %}
          {% if 0.1 > t > -2.1 %} 18.5
          ....

It does not validate either, giving:

                      Integration error: temperature_HVAC - Integration 'temperature_HVAC' not found.

Do I need that second “temperature_HVAC” anymore?

You missed the sensor word in front, ie “sensor temperature_HVAC:”

And avoid capital letters!

Where in the configuration.yaml file are you adding the Template Sensor?

You have defined a Template Sensor using the legacy format so it should be added to the sensor domain.

sensor:
  - platform: template
    sensors:
      weather_temperature:
        friendly_name: "Temperature"
        unit_of_measurement: 'degrees'
        value_template: "{{ state_attr('weather.huoltom_a', 'temperature') }}"

Yes, the abovementioned example is in sensor domain, exactly as you show. I’m sorry I did not remember to include it the code sample.

And it works as such. However exactly the same code with “weather_temperature” replaced with “temperature_HVAC” does not.

BUT, as instructed by WallyR, using “temperatur_hvac” (without capitals) validates.

It looks like that was it!

Thank You all! Next I start to examinen the differences between legacy and modern configurations.

Somewhat it feels that it is not that easy to try to get a hold on these from the scatch, not that they are that difficult, but that they are not easy to find. E.g. with google I have bumped in the Templating -page countless times, but first time I saw Template -page was via 123 Taras’s link…

templating is not to be confused with template, the integration(s) that based off templating.

Moving to the next step. Seems to be that creating scripts is not even nearly what documentation says. In HA there isa a graphical UI, where there is only option to feed in numerical values.

The documentation has nothinng about the UI.

There is an option to use yaml-editor, but I cannot make anything to stick there and I’m running out of variations what to even try. The following works:

set_garage_hall_temp:
  alias: Set Garage hall temp
  sequence:
  - service: climate.set_temperature
    target:
      device_id: c6d59cfa6cf443c19a372b6f317e22e7
    data:
      temperature: 26
  mode: single
  icon: mdi:air-filter

So, the question is: What should I feed in the script on the place of “26” to use there the value defined in configuration.yaml and discussed earlier in this thread?

There is also that data: which is in some threads adviced to change to data_template: but that has made no difference, other than of course made using graphical UI impossible.

Secondly, do I need something to trigger the script?

Yuo replace 26 with a sensor variable encased in double brackets, like

{{ states('sensor.weather_temperature') }}

The double brackets tells HA to put the value of the sensor in that place.

When you in other places in HA encounters brackets followed percent, ie {% some code %}, then its not a value that it is put in place, but an actually program step, that in some way is changing the execute, like

{% if (states('sensor.weather_temperature'))==20 %}
    26
{% endif %}

This only puts 26 in if the sensor is actually 20.