Script: variable defined within a sequence cannot be used in an entity state condition

Configuration
1

I’m seeing an error when trying to use a variable defined inside a sequence of a script (originally the variable itself is defined using an input variable but I’ve simplified it to be set to a string and it still doesn’t work).

I have used variables in the past without issues in the very same installation but for some reason this fails with an error.

Could it be that specifically “state” conditions do not support templates?
I’m getting the this error

image
image1462×87 10.2 KB

...
adjust_lights_based_on_presence:
  alias: blah
  description: blah
  fields:
    area_id:
      description: blah
      example: blah
  sequence:
    - variables:
        transition_delay: 7
        light_id: "light.north_bedroom" #light.{{area_id}}
        temp_saved_scene: "{{area_id}}_light_management_saved_scene"
    - choose:
        - conditions:
            - alias: Presence OFF and Lights ON
              condition: and
              conditions:
                - condition: trigger
                  id:
                    - presence_off
                - condition: state
                  entity_id: "{{ light_id }}" # <-- seems this line is the issue
                  state: "on"
          sequence:
...
2

yeah, you’ll need to use a template condition instead.

- condition: template
    value_template: "{{ states(light_id) == 'on' }}"
1 Like
3

A State Condition’s entity_id option doesn’t support templates. Use a Template Condition.

Replace this:

                - condition: state
                  entity_id: "{{ light_id }}"
                  state: "on"

with this:

                - condition: template 
                  value_template: "{{ is_state(light_id, 'on') }}"
1 Like
4

Thank you both @armedad and @123 .

Taras if that’s ok I’ll mark Armedad’s as the solution going by ordering though I prefer using the is_state stynax personally.

I do wish HA was a bit more consistent and transparent about these things.
It’s never clear – both in the front end, and in the back ned – what fields support what templating and also when you need quotes vs not. For a new-comer it tends to seem kind of random.

((a bit of a non-constructive rant: and when you couple that with the fact YAML is not ‘compiled’ but interpreted I sometimes just have to take a big sigh to implement otherwise trivial seeming things because I know it will take tens of minutes if not hours fighting with the syntax (which is also often quite verbose to express basic things). I do love that the “Studio Code Server” addon I’m using seems to be aware of certain YAML rules but the custom HA stuff overlaid on top is not well supported. It would be amazing if we got more of an “IDE”. That or move everything to the UI. But I suspect the issue is resourcing for NabuCasa as most people probably do not pay for HA. So I get it will probably take years to get there… The product is amazing but it can also be incredibly frustrating. Still, beats anything else out there for me. And I really appreciate the dev team. /rant)

1 Like
5

yeah… when you can use a template when you can’t, when you need quotes when you don’t… i don’t keep that totally straight in my head either.

it’s helpful to start figuring out the error messages. your error message above showed it was {{ light_id }}. which means it wasn’t getting evaluated.

the other thing is to get to know the tracing. you likely would have seen that the entity info was getting passed in raw, not evaluated there.

1 Like
6

If it’s not explicitly mentioned in the documentation that an option supports templating and/or there’s no example employing a template for a given option, simply do not assume that it does.

Nowhere in the documentation for State Condition is it described or implied that the entity_id option supports templating (or its state option).

It’s your choice if you believe that’s the post that other readers should be led to in order to understand the problem and its solution.

Nobody pays for HA, it’s open-source and freely available.

Subscription fees paid to Nabu Casa are for remote access and other value-added services they provide. It’s sufficient revenue to allow them to employ over 30 people. If you look at the backlog of reported Issues (currently over 2700) and long-standing unfulfilled Feature Requests, it’s obvious their priorities lie elsewhere (i.e. HA Yellow, Green, SkyConnect, Matter, Voice Assistant, Grace, etc). The past five years have demonstrated that the bulk of the subscription fees don’t fund fixing mundane things (those are often left to volunteers) but for expanding Home Assistant in new directions.

The majority of new integrations, features, corrections, and technical support comes from unpaid volunteers who have limited time and resources.