Switch template or automation

sgw · June 30, 2019, 4:16am

this automation works fine:

automation:
- id: 'grow_on'
  alias: Kitchen Grow Light On
  trigger:
  - entity_id: sun.sun
    from: below_horizon
    platform: state
    to: above_horizon
  condition: []
  action:
  - data:
      entity_id: switch.kitchen_grow_light
    service: switch.turn_on
- id: 'grow_off'
  alias: Kitchen Grow Light Off
  trigger:
  - entity_id: sun.sun
    from: above_horizon
    platform: state
    to: below_horizon
  condition: []
  action:
  - data:
      entity_id: switch.kitchen_grow_light
    service: switch.turn_off

I decided to try a switch template as follows:

- platform: template
  switches:
    grow_light_on:
      value_template: "{{ is_state('sun.sun', 'Above_horizon') }}"
      turn_on:
        service: switch.turn_on
        data:
          entity_id: switch.kitchen_grow_light
      turn_off:
        service: switch.turn_off
        data:
          entity_id: switch.kitchen_grow_light

it appears in the front end, but does not follow the state of sun.sun
Is this not the purpose of template switches?

What I’m trying to do is have the grow light on when ever the sun.sun is “above_horizon”.
An example: The automation has only one chance of firing, and that’s when the sensor changes state. If HA had locked up the minute before and required a reboot, then the trigger would expire and the light won’t turn on.
When I move on to more mission critical switches, I’d like to make sure that the switch follows the sensor.
I’m sure that adding a trigger to check the sun state every minute or so would work, I’m worried that too much looping like this will bog down the pi…

nickrout · June 30, 2019, 5:00am

isn’t the state above_horizon, not Above_horizon.

sgw · June 30, 2019, 3:26pm

it appears that correct, but I have the same problem.
I made some test code to play with:

- platform: template
  switches:
    grow_light_on:
#      value_template: "{{ is_state('sun.sun', 'above_horizon') }}"
      value_template: "{{ is_state('input_text.test_text', 'on') }}"
      turn_on:
        service: switch.turn_on
        data:
          entity_id: switch.kitchen_grow_light
      turn_off:
        service: switch.turn_off
        data:
          entity_id: switch.kitchen_grow_light


test_text:
  name: test text input

these are in my switches.yaml and input_texts.yaml include files

the template switch “grow_light_on” follows the text as expected.
However the actual switch “switch.kitchen_grow_light” does not respond to changes in the template switch. (I have tested it in services and it works, as well as with the original automation shown above [remmed out of HA for testing above templates, of course]. }

123 · June 30, 2019, 7:17pm

It never will because that’s not how a Template Switch works.

The purpose of value_template is to report the current state of the Template Switch. You appear to believe it controls the Template Switch’s turn_on and turn_off functions (it doesn’t).

If your concern is that the two automations you’ve created might not be triggered due to a badly timed restart, create this additional automation:

- alias: 'Set grow light'
  trigger:
    platform: homeassistant
    event: start
  action:
    service_template: switch.turn_{{ 'on' if is_state('sun.sun', 'above_horizon') else 'off' }}
    entity_id: switch.kitchen_grow_light

At startup, the automation will turn on the grow light if the sun is above_horizon, otherwise it will turn the light off.

sgw · July 1, 2019, 1:49am

that little code will certainly fix some critical things at start. Thank you.

I can accept that “The purpose of value_template is to report the current state of the Template Switch.” And it appears to do that very well with no lag.

You are correct, I did believe it controls the on/off functions. seems logical to me when I look at it.
But then what is the purpose of the “Turn on” and “turn off” functions if they are never used? . What do they do?

In my example the template switch accurately reflects the input_text, and input_text will tether it if I manually toggle it. But the grow_light switch does nothing to the template and vice versa.

123 · July 1, 2019, 3:59am

They are indeed used, just not in the way you envisioned it. When you turn on a template switch, it executes whatever is defined in the turn_on section.

Here’s the example from the documentation:

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

When you turn on the template switch switch.skylight, it executes the turn_on section which, in this case, turns on switch.skylight_open (but it can be more complex than that).

sgw · July 1, 2019, 9:58pm

Sorry, Now I’m confused again. That sounds like what I first envisioned.
sensor.skylight turn ‘on’, template.switch.skylight mimics ‘on’ and executes it’s turn_on section.

I’m using a value_template of: “{{ is_state(‘input_text.test_text’, ‘on’) }}” to try to understand this.
when the text is on, (true) the template switch says ‘on’. If I type anything other than on, it displays ‘off’.

if I manually flip the template switch to ‘off’ when the text is “on”, the template switch is auto corrected back to ‘on’. And vice versa.

So doesn’t this prove

the template_switch reports the current state of the value_template (not the other way around)
the template switch is using a true/false test of the value_template to determine what state to display

I want to understand this before I move on to the turn_on and turn_off thing…

123 · July 1, 2019, 10:12pm

The value_template computes the template switch’s state.
The other two parts are executed when the template switch is turned on and off.

That’s how it works.

In your original example, the template switch duplicates the functionality of switch.kitchen_grow_light. Not sure why you chose to do this. Is this just an experiment?

sgw · July 1, 2019, 11:46pm

yes, just an experiment. I thought it was a neat way to guarantee the state of a physical switch from the state of a sensor and not just trip it once on the sensor’s change of state (like an automation). I’m using the grow light to experiment with because I can see the results easily.
But I guess that is not the purpose of a template sensor.

Maybe I’m not understanding what the template switch is,
and what you mean by “The value_template computes the template switch’s state.”

Here are two screen shots from my frontend.
Isn’t the template switch the second one? It’s following the value_template above it. Toggling the physicalswitch.kitchen_grow_light .has no effect.

false:

** true:

123 · July 2, 2019, 12:18am

What I mean is quite literally what I said. If my attempt to explain it has fallen short, I recommend you read the Template Sensor’s documentation for value_template

I have no idea. You’re showing screenshots of switches without revealing their configuration. Your original example contained no input_text component but now this one does. I have to assume this example uses a different template not based on sun.sun, as in the original example, but on an input_text. I have no idea what this revised template looks like so I can’t comment on the screenshots you’ve posted.

Maybe this will help. This example is purposely eccentric in order to make a point.

You have a door that’s closed (off).
You have a ceiling light that’s off.

Imagine creating the following template switch:

Its value_template reports the status of the door.
Its turn_on and turn_off portions control a ceiling light switch.

Q: What happens when you turn on the template switch?
A: The ceiling light turns on.

Q: What is the template switch’s status after being turned on?
A: It’s the door’s current state so its off.

Unless there’s some relation between the door and the ceiling light, this template switch’s status will forever be unrelated to the ceiling light’s status.

If you change the value_template to monitor the ceiling light’s status, now the template switch will report on whenever the ceiling light turns on. However, this isn’t a particularly useful template switch because all it does is mimic the ceiling light switch.

sgw · July 2, 2019, 12:59am

my second post way above contains the complete template with the input_text code I substituted for sun.sun.

I will study the rest of your reply tonight, thank you for the patience.

123 · July 2, 2019, 11:46am

Then it explains why the screenshot shows the template switch reports it’s off. There’s no relation between the input_text and switch.kitchen_grow_light.

sgw · July 4, 2019, 5:52am

I think we’re on the same page. I’m hoping that my lack of understanding is due to the switches just not working. I believe this code to represent your example. However I can’t get it to work. I replaced the service calls directly to input_text.set_value to with the scripts just to be sure that I was able to set the value.

Assuming the code is accurate; when I change the ‘door’ status to ‘open’ the switch turns on. However nothing effects the light. I can’t see why the template’s turn_on and turn_off are not working…

switch:
  - platform: template
    switches:
      ceiling_light_template:
        value_template: "{{ is_state('input_text.door_status', 'open') }}"
        turn_on:
          service: script.turn_on
          entity_id: script.ceiling_light_on
        turn_off:
          service: script.turn_on
          entity_id: script.ceiling_light_off

input_text:
  door_status:
    initial: closed
 
  ceiling_light:
    initial: initial
    max: 10

script:
  'ceiling_light_on':
    sequence:
    - data:
        entity_id: input_text.ceiling_light
        value: is on
      service: input_text.set_value
  'ceiling_light_off':
    sequence:
    - data:
        entity_id: input_text.ceiling_light
        value: is off
      service: input_text.set_value

123 · July 4, 2019, 11:57am

I don’t think so because you went on to say this:

… and we’re back to square one.

Here’s the deal, your template switch is behaving exactly as it should. However, your preconceived model of how a template switch should work makes you conclude it’s working incorrectly. It’s not; your preconceived model is incorrect.

sgw · July 4, 2019, 3:19pm

You’re right, I’m just not seeing how or what turns the light on. Is my code totally off base or is it close enough you could correct it? I can change my understanding of the model when I’m able to see it working…

123 · July 4, 2019, 3:44pm

If your goal is still this:

then use automations (the ones you created plus, optionally, the one I offered).

You’re right, I’m just not seeing how or what turns the light on.

For starters, definitely not the value_template. You turn a template switch on/of using a service like switch.turn_on or manually via the UI. It isn’t turned on/off via its value_template (which serves to report the switch’s status and nothing more).

Is my code totally off base or is it close enough you could correct it?

If you’re referring to the template switch, there’s nothing to correct. It’s the wrong tool for the job.

I can change my understanding of the model when I’m able to see it working…

How about changing your understanding of the model based on seeing how it does not work? It does not work the way you think it does.

drujebober · December 27, 2019, 4:41pm

Did you find a solution to the problem?
I have the similar issue

123 · December 28, 2019, 2:20am

The main issue in this thread was sgw misunderstood how a Template Switch works.