Use variable in if/else to check attribute

I am creating a script that I can use repeatedly for calls made by automations for various lights which are triggered by button pushes, but I am running up against the issue if understanding and using a variable in the data_template.

I have automations that call the script with a light:

action:
    - service: script.lightincrease
      data:
        on_light: light.z_strip

on the script I am then using that given light to check the brightness, but getting an error in the logs no matter which way I attempt to use the variable within the brightness check.

lightincrease:
  alias: Light Increase
  sequence:
    service: light.turn_on
    data_template:
      entity_id: '{{on_light}}'
      transition: '1'
      brightness: >
        {%- if states.{{on_light}}.attributes.brightness <= 25 %}
          51
       {% elif states.{{on_light}}.attributes.brightness <= 51 %}
          77
...

I’ve looked through the forum but can’t find an answer (likely phrasing my query wrong), but hoping someone can point me in the right direction of how to do this.
Really don’t want to make 30+ versions of the same script to do this.

Thanks!

Try this:

      brightness: >
        {% if states.{{on_light}}.attributes.brightness|int <= 25 %}
          51
        {% elif states.{{on_light}}.attributes.brightness|int <= 51 %}
          77

brightness: >
{% if states.{{on_light}}.attributes.brightness|int <= 25 %}
51
{% elif states.{{on_light}}.attributes.brightness|int <= 51 %}
77

I get:

Invalid config for [script]: invalid template (TemplateSyntaxError: expected name or number) for dictionary value @ data['script']['lightincrease']['sequence'][0]['data_template']. Got None. (See /config/configuration.yaml, line 208).

Got the answer i was looking for from here:

Managed to set some variables and then do a check based on the passed entity_id.

Will likely adopt this script shortly to merge the light increase and decrease scripts into a single file and make it a singular dimmer.

Code below for reference:

lightincrease:
  alias: Light Increase
  sequence:
    service: light.turn_on
    data_template:
      entity_id: '{{on_light}}'
      transition: '1'
      brightness: >-
        {% set domain, name = on_light.split('.') %}
        {% set current = states[domain][name].attributes.brightness | int %}
        {%- if current <= 25 %}
          51
        {% elif current <= 51 %}
          77
        {% elif current <= 77 %}
          102
        {% elif current <= 102 %}
          128
        {% elif current <= 128 %}
          153
        {% elif current <= 153 %}
          179
        {% elif current <= 179 %}
          205
        {% elif current <= 205 %}
          230
        {% elif current <= 230 %}
          255
        {% endif %}

A direct way of achieving this:

        {% set domain, name = on_light.split('.') %}
        {% set current = states[domain][name].attributes.brightness | int %}

is this:

        {% set current = state_attr(on_light, 'brightness') %}

The brightness attribute is already an integer so the template doesn’t employ an int filter.

Here it is in your automation:

lightincrease:
  alias: Light Increase
  sequence:
    service: light.turn_on
    data_template:
      entity_id: '{{on_light}}'
      transition: '1'
      brightness: >-
        {% set b = state_attr(on_light, 'brightness') %}
        {% if   b <= 25  %} 51
        {% elif b <= 51  %} 77
        {% elif b <= 77  %} 102
        {% elif b <= 102 %} 128
        {% elif b <= 128 %} 153
        {% elif b <= 153 %} 179
        {% elif b <= 179 %} 205
        {% elif b <= 205 %} 230
        {% elif b <= 230 %} 255
        {% endif %}
3 Likes

and since we’re nitpicking, use data: instead of data_template:, assuming 116.+ (or was it 115 …)

Good point. Speaking of data_template, check out this unforseen side-effect of making data the equivalent of data_template.

The goal is to publish a payload containing a template, but you don’t want the template to be evaluated simply published literally. It becomes a bit more complicated now that data works like data_template.

Sorry for hijacking the thread! (See you in the other thread if you want to continue the conversation)

Perhaps I can hijack you all further in getting this to work:

notification:
  alias: Notification
  condition: state
    entity_id: '{{ person }}'
    state: 'home'
  sequence:
    service: '{{ notify_service }}'
    data:
      title: "S.A.R.A.H."
      message: '{{ message }}'

I’m getting the error

  • Error loading /config/configuration.yaml: mapping values are not allowed here
    in “/config/scripts/notification.yaml”, line 4, column 14*

Not sure what I’ve done wrong here, haven’t fully understood the syntax yet.

I do like shorted code, thank you!

I believe the condition should be part of the sequence.

notification:
  alias: Notification
  sequence:
    - condition: state
      entity_id: '{{ person }}'
      state: 'home'
    - service: '{{ notify_service }}'
      data:
        title: "S.A.R.A.H."
        message: '{{ message }}'

Script Syntax - Test a condition

Looks to be a step in the right direction, but get the following:

Invalid config for [script]: Entity ID {{ person }} is an invalid entity id for dictionary value @ data['script']['notification']['sequence'][0]['entity_id']. Got '{{ person }}'. (See /config/configuration.yaml, line 208). 
Invalid config for [automation]: string value is None for dictionary value @ data['action'][0]['service']. Got None. (See /config/configuration.yaml, line 207).

Sorry, I didn’t proofread the script. It’s probably flagging it as invalid because you can’t template the entity_id option within the condition. For example if you replace it with person.whatever it passes config check.

All good, you are helping me. I should have checked that myself, I thought that was what it was saying but didnt want to believe it.
That is a bummer though, hopefully I can perhaps move the condition back to the action phase of my automation and just use this as a general sending notifications script.

I did manage to move the condition back to the action phase of the automation, and just used the script as a notification script rather than needing to repeat that piece of code if different areas.