#templating the 'enabled" state for a condition in a blueprint

1 messages · Page 1 of 1 (latest)

cunning garden
#

Hello, I have this issue that I can't solve. I tried all the possible ways, but just doesn't work if I use something else than true or false for the 'enabled" value

            condition: template
            value_template: "{{ states('weather.home') in weather_conditions }}"
#            enabled: '{{ is_auto_irm_enabled }}'
            enabled: true```

and the 'is_auto_irm_enabled' is itself another template in trigger_variables :
```trigger_variables:
  auto_option_weather_condition: !input auto_option_weather_condition
  is_auto_irm_enabled: '{{ ''auto_using_IRM'' in auto_option_weather_condition }}'```

auto_option_weather_condition is a list selector, I tried to put the values with no quote, single quote and double quotes

I verified in the template editor and the result should just work. For what I get is that the template would always return 'false' (as the condition result is always 'null')
For now I hardcoded the value, but surely it should work (I'm using strickly the same code as from another blueprint)
Thank you for any help here
image.png
flint tree
flint tree
#

Perhaps you can't chain limited templates together in this way?

#

Seems like this might work based on the example given.

            enabled: '{{ ''auto_using_IRM'' in auto_option_weather_condition }}'
lament oyster
#

It only works with limited templates which are only resolved at configuration load/reload

#

anyways, with a template condition, you don't need to even bother using enabled. Build the if check into the template itself.

          - alias: "Check for auto_using_irm"
            condition: template
            value_template: "{{ (is_auto_irm_enabled and states('weather.home') in weather_conditions) or not is_auto_irm_enabled }}"
#

@cunning garden

cunning garden
# lament oyster anyways, with a template condition, you don't need to even bother using `enabled...

ok, good to know. But the configuration is static, and even if I reload, it remains false.
The reason why I wanted to do it as part of the 'enabled' is because I have multiple other condition like that, and as soon one triggers a false, it exits the 'choose' to pick default value. Or maybe I need to use a OR, but not sure how to write it for the 3 last conditions (if any is true I should continue) ``` - choose:
- conditions:
- condition: template
value_template: "{{
state_attr('sun.sun', 'azimuth') | float(default=min_azimuth) > min_azimuth |float() and
state_attr('sun.sun', 'azimuth') | float(default=max_azimuth) < max_azimuth |float()
}}"
alias: "Azimuth between {{ min_azimuth}} and {{ max_azimuth}}"
- alias: "Elevation above {{ min_elevation}}"
condition: template
value_template: "{{
state_attr('sun.sun', 'elevation') | float(default=min_elevation) > min_elevation |float()
}}"
- alias: "Check for auto_using_irm"
condition: template
value_template: ...

enabled: '{{ is_auto_irm_enabled }}'

        enabled: true
      - alias: "Check for auto_using_radarbuien"
        condition: template
        value_template: ...

enabled: '{{ is_auto_buienradar_enabled }}'

        enabled: false
      - alias: "Cloudiness for specific conditions"
        condition: template
        value_template: ...```
#

I want to keep them separated, so I can follow a bit more easily in the traces

#

and not make a big template which would just be true or false

lament oyster
#

post where is_auto_irm_enabled is coming from, because they still don't look static to me

#

when I say static I mean, when the configuration loads, that template only resolves at that time. Never again. It is a static value, the tempalte is not stored it's resolution on load is stored

#

so if you load the configuration, and the value of is_auto_irm_enabled is false at the time of load, that will always remain false forever.

#

@cunning garden ^

cunning garden
#

before I defined it in 'variables', not sure which one would be best (can't find a clear difference between variables and trigger variables, I though trigger variables would be refreshed when triggered)

lament oyster
#

trigger_variables are limited templates that are usable inside triggers that have templates

cunning garden
lament oyster
#

you can't

#

limited templates are limited, they do not use the state machine and they are resolved on configuration load

#

do you understand what I mean when I say that?

cunning garden
lament oyster
#

Here's an example pulled from enabling/disabling conditions documentation:

blueprint:
  input:
    input_boolean:
      name: Boolean
      selector:
        boolean:
    input_number:
      name: Number
      selector:
        number:
          min: 0
          max: 100

  trigger_variables:
    _enable_number: !input input_number

  conditions:
    - condition: state
      entity_id: sun.sun
      state: "above_horizon"
      enabled: !input input_boolean
    - condition: state
      entity_id: sun.sun
      state: "below_horizon"
      enabled: "{{ _enable_number < 50 }}"
#

notice how their input is in trigger_variables, and the value is static. As it in comes from an input

#

that's all you can do

cunning garden
# lament oyster do you understand what I mean when I say that?

yes, that I understood, but as my config is static (I didn't change the ***auto_option_weather_condition ***since I created the automation from the blueprint), the ***is_auto_irm_enabled *** should still be updated each time I reload automation via the developper tools> YAML

lament oyster
#

they are dynamic, they get reloaded when triggered

#

they also don't get passed to limited templates

cunning garden
#

wait, you're loosing me

lament oyster
#

put them back in trigger_variables

#

then it will likely work based on what you showed me

cunning garden
#

in my input, I have the auto_option_weather_condition

lament oyster
#

right

cunning garden
#

ha, in trigger_variables I'm using a template, and I can't

lament oyster
#

now in trigger_variables, you have

trigger_variables:
  auto_option_weather_condition: !input auto_option_weather_condition
  is_auto_irm_enabled: '{{ ''auto_using_IRM'' in auto_option_weather_condition }}'
#

then in your conditions, enabled can be enabled: "{{ is_auto_irm_enabled }}"

cunning garden
lament oyster
#

not trigger_variables

cunning garden
#

BUT it always resolves to false

bronze quartz
#

Code is in the first post

lament oyster
#

are you filling out the blueprint fields when you save the blueprint as an automation?

#

I see that, but if you read below rob, they say differnt things

cunning garden
flint tree
#

I tried to make this work with trigger_variables I couldn't get it to work either.

cunning garden
lament oyster
#

are you using the beta?

cunning garden
#

I tried to use different kidn of value (as I though the template could resolve as a string instead of boolean)

lament oyster
#

are you using the beta?

cunning garden
#

I spent almost a complete day to try all possibilities

lament oyster
#

ffs, I have no idea how this ever worked. Someone seems to have broken it or it never worked from day 1

cunning garden
#

I used the code I found from another blueprint. It was way more complex, so wanted to make something simpler for myself

lament oyster
#

Never worked

cunning garden
#

so I assume it somehow worked someday

lament oyster
#

looking at the original PR, still has same issue

bronze quartz
#

Good ol' blame:

image0.jpg
lament oyster
#

The test cases don't properly test it

cunning garden
#

ok, well, that won't solve my issue 🙂

lament oyster
cunning garden
#

Thank you for you help Petro, at least I can stop searching

lament oyster
#

Yep, it's just bad luck

#

I know it works for triggers

#

and actions

#

I think it was just overlooked for conditions

#

Anyways, wrote up an issue for it above

cunning garden
#

another one might be needed for conditions/0 [Unknown condition] Executed: 31 March 2025 at 18:52:44