Why are switch templates in legacy format compared to everything else?

A really dumb question that probably has a very simple explanation. Pls dont flame my ignorance

Some years ago we had to (well not necessarily) migrate all our template sensors over to a new format, but we didnt do it in a template switch.

Why are template switches still configured in legacy format???

Im actually asking “Why are they still being configured in Legacy format???”

https://community.home-assistant.io/t/template-switch-and-yaml/427886

Legacy Format of a template binary sensor:

binary_sensor:
  - platform: template
    sensors:
      sun_up:
        friendly_name: "Sun is up"
        value_template: {{ state_attr('sun.sun', 'elevation') > 0 }}

Switch Template:

switch:
  - platform: template
    switches:
      skylight:
        value_template: "{{ is_state('sensor.skylight', 'on') }}"
        turn_on:
          service: switch.turn_on
          target:
            entity_id: switch.skylight_open

where modern format template entities should be

template:
  - sensor:
      - name: "Transmission Down Speed"
        unit_of_measurement: "kB/s"
        state: "{{ states('sensor.transmission_down_speed')|float * 1024 }}"
        availability: "{{ is_number(states('sensor.transmission_down_speed')) }}"

so therefore a template switch should look like this:

template:
  - switch:
      - name: skylight
        state: "{{ is_state('sensor.skylight', 'on') }}"
...

There are many template entities that are still configured under their original integrations and have not been moved to the Template integration. These include Lock, Light, Switch, Fan, Cover, Alarm Control Panel, Vacuum, and Weather.

I assume these weren’t switched over because doing so offers no advantage. And, since the trigger-based functionality doesn’t really apply, there was no necessity. Also, based on analytics, these are in active use by a very low percentage of users.

Part of the reason why is I want to be able to use variables in my switch templates

{% set use_this_switch = 'input_boolean.sky1_or_sky2' %}
{% if states(use_this_switch) == 'on') %}
 value_template: "{{ is_state('sensor.skylight1', 'on') }}"
   turn_on:
   ....
   turn_off:
    ....

{% elif states(use_this_switch) == 'off') %}
 value_template: "{{ is_state('sensor.skylight2', 'on') }}"
   turn_on:
   ....
   turn_off:
    ....

{% endif %}

This is not the ACTUAL use case but the concept of me using variables in a template switch is actually what Im getting at

There is nothing stopping you using Jinja variables in template switch configurations. But, no matter whether it’s the legacy or contemporary format, you cannot build YAML with templates… the provided example would not work.

Sorry, @Didgeridrew . Not quite following your statement

no matter whether it’s the legacy or contemporary format, you cannot build YAML with templates <

I do realize the above code will not work (Ive been trying to get variables to work). Could you point me to a rough syntax as switches dont follow the same syntax for a conditional (if/elif) as a sensor (obviously) and I dont seem to be able to find a resource that shows any examples.

My use case is to detect device errors and if one is detected, use a different switch template

I currently do a similar thing for my temp sensors - if a sensor comes back with an error or a temp of > 110 then make the sensor.tank_global_error__state = “unavailable”

FYI: The below is designed to detect if any of my tanks have errors and then I use it to highlight a custom button called “global error” in lovelace. The input_boolean.1_enabled is actually my way of ignoring a tank as I see fit in other parts of the system in the case the sensor/device goes faulty and I dont have time to replace it immediately, I can just turn enabled off

  - sensor:
      - name: tank_global_error_state
        state: >
          {% set enabled1 = 'input_boolean.1_enabled'%}
          {% set enabled2 = 'input_boolean.2_enabled'%}
          {% set enabled3 = 'input_boolean.3_enabled'%}
          {% set enabled4 = 'input_boolean.4_enabled'%}
          {% set enabled5 = 'input_boolean.5_enabled'%}
          {% set enabled6 = 'input_boolean.6_enabled'%}
          {% set enabled7 = 'input_boolean.7_enabled'%}
          {% set enabled8 = 'input_boolean.8_enabled'%}                                                                      
          {% set tsens1 = 'sensor.1t_global_temp_dny' %}
          {% set tsens2 = 'sensor.2t_global_temp_dny' %}
          {% set tsens3 = 'sensor.3t_global_temp_dny' %}          
          {% set tsens4 = 'sensor.4t_global_temp_dny' %}
          {% set tsens5 = 'sensor.5t_global_temp_dny' %}
          {% set tsens6 = 'sensor.6t_global_temp_dny' %}
          {% set tsens7 = 'sensor.7t_global_temp_dny' %}
          {% set tsens8 = 'sensor.8t_global_temp_dny' %}
          {% if (states(tsens1) == "unavailable" and states(enabled1) == 'on') or (states(tsens1) == "unknown" and states(enabled1) == 'on') or (states(enabled1) == "on" and states(tsens1) | int (0) > 110) %}
            unavailable
          {% elif (states(tsens2) == "unavailable" and states(enabled2) == 'on') or (states(tsens2) == "unknown" and states(enabled2) == 'on') or (states(enabled2) == "on" and states(tsens2) | int (0) > 110) %}
            unavailable
          {% elif (states(tsens3) == "unavailable" and states(enabled3) == 'on') or (states(tsens3) == "unknown" and states(enabled3) == 'on') or (states(enabled3) == "on" and states(tsens3) | int (0) > 110) %}
            unavailable
          {% elif (states(tsens4) == "unavailable" and states(enabled4) == 'on') or (states(tsens4) == "unknown" and states(enabled4) == 'on') or (states(enabled4) == "on" and states(tsens4) | int (0) > 110) %}
            unavailable
          {% elif (states(tsens5) == "unavailable" and states(enabled5) == 'on') or (states(tsens5) == "unknown" and states(enabled5) == 'on') or (states(enabled5) == "on" and states(tsens5) | int (0) > 110) %}
            unavailable
          {% elif (states(tsens6) == "unavailable" and states(enabled6) == 'on') or (states(tsens6) == "unknown" and states(enabled6) == 'on') or (states(enabled6) == "on" and states(tsens6) | int (0) > 110) %}
            unavailable
          {% elif (states(tsens7) == "unavailable" and states(enabled7) == 'on') or (states(tsens7) == "unknown" and states(enabled7) == 'on') or (states(enabled7) == "on" and states(tsens7) | int (0) > 110) %}
            unavailable
          {% elif (states(tsens8) == "unavailable" and states(enabled8) == 'on') or (states(tsens8) == "unknown" and states(enabled8) == 'on') or (states(enabled8) == "on" and states(tsens8) | int (0) > 110) %}
            unavailable
          {% else %} 
            Online
          {% endif %}

Anyway as I said, am attempting to do a similar use case as the above, only, in this case, for switch templates

Whatever supports Jinja2 templates will support Jinja2 if/elif/else.

The problem with the example of your attempt to “use variables in my switch templates” is that it employs Jinja2 outside of a YAML option. Nothing in Home Assistant supports that and so that’s why Didgeridrew said “you cannot build YAML with templates”.

Your second example, the Template Sensor configuration, is valid because the lengthy Jinja2 template is where it’s supposed to be; it’s used exclusively for computing the value of the (YAML) state option.

tl;dr
You can’t use Jinja2 to control which YAML options should/shouldn’t be used.

Hey hey… thanks for replying. :grinning_face_with_smiling_eyes:

Please excuse my ignorance, am not trying to be difficult. :woozy_face:

So essentially, youre saying that because switch templates use YAML in their configuration, its not possible to use jinja inside a switch template, whereas a template sensor is pretty much all jinja.

No, that’s not at all what I said.

Perhaps this is what you are attempting to do:

   value_template: >
     {% set use_this_switch = 'input_boolean.sky1_or_sky2' %}
     {% set entity = iif(states(use_this_switch) == 'on', 'sensor.skylight1', 'sensor.skylight2') %}
     {{ is_state(entity, 'on') }}
   turn_on:
   ....
   turn_off:
    ....

Be aware that whatever Jinja2 variables you define in a YAML option are only defined in that one option. In other words, the Jinja2 variable use_this_switch defined in value_template is not accessible in the turn_on option or any other option.

Ohhhhh lightbulb moment… your clarification NOW makes sense

You can’t use Jinja2 to control which YAML options should/shouldn’t be used.

Tq :pray:

1 Like

Unfortunately not.

I need multiple value templates because I need the entities in the turn_on: and turn_off: to reference different devices.

And based on your comment - it sort of defeats the purpose of using variables as they are not referenceable within turn_on/turn_off

Oh well - it was worth the try and I have learned something new today :grinning:

I will think of another solution

You’re asking for something that isn’t supported by any Template entity. There’s one instance of a given option and you can use Jinja2 to assign it a computed value.

If that’s your conclusion then I suggest you review how Home Assistant employs YAML and Jinja2.

  1. Think of YAML as a form with fields (item, quantity, size, color, etc).
  2. The value for each field can be computed using Jinja2.
  3. The Jinja2 “formula” for computing the field’s value is unique to that field.

So what you can’t do is use Jinja2 to create or rearrange the form’s fields nor can you borrow parts of one field’s formula to use in another field’s formula.