Template sensor & based on a blueprint sensor - behave differently

I have 2 template sensors:
– both have same structure;
– one of them is based on a blueprint
and they behave differently.

There are 2 input_number helpers:

input_number:
  testing_number: &ref_input_number
    min: -1000
    max: 1000
    step: 1
    mode: slider

  testing_number_2: *ref_input_number

A template sensor:

template:
  - sensor:
      - name: testing_source
        unit_of_measurement: uom
        state: >-
          {{ states('input_number.testing_number') }}
        attributes:
          some_attr: >-
            {{ states('input_number.testing_number_2') }}

Now let’s create a trigger-based template sensor:

  - trigger:
      - platform: state
        entity_id: sensor.testing_source
        attribute: some_attr
    sensor:
      - name: testing_blueprint_attr_copy
        state: >-
          {% if trigger.to_state is not none -%}
            {%- if trigger.to_state.attributes['some_attr'] is defined -%}
              {{ trigger.to_state.attributes['some_attr'] }}
            {%- else -%}
              xxx
            {%- endif -%}
          {%- else -%}
            yyy
          {%- endif %}

The sensor uses the “sensor.testing_source” as a data source.
Let’s put a simple logic:
– if source attribute is defined - use it;
– otherwise use something else like “xxx” or “yyy”.
I intentionally did not use “condition” part here.

Next, a blueprint - which is supposed to do the same:

blueprint:
  name: xxx
  domain: template
  input:
    input_SOURCE_ENTITY:
    input_SOURCE_ATTR:

variables:
  SOURCE_ENTITY: !input input_SOURCE_ENTITY
  SOURCE_ATTR: !input input_SOURCE_ATTR

trigger:
  - platform: state
    entity_id: !input input_SOURCE_ENTITY
    attribute: !input input_SOURCE_ATTR

sensor:
  state: >-
    {% if trigger.to_state is not none -%}
      {%- if trigger.to_state.attributes[SOURCE_ATTR] is defined -%}
        {{ trigger.to_state.attributes[SOURCE_ATTR] }}
      {%- else -%}
        xxx
      {%- endif -%}
    {%- else -%}
      yyy
    {%- endif %}

Here there is same logic for the “state”.
And create a sensor based on this blueprint:

  - name: testing_blueprint_attr
    use_blueprint:
      path: xxx.yaml
      input:
        input_SOURCE_ENTITY: sensor.testing_source
        input_SOURCE_ATTR: some_attr

Reboot HA (needed due to this issue).
Start playing with “input_number” helpers (although only “testing_number_2” is supposed to influence).
Mysteriously the “traditional” sensor “testing_blueprint_attr_copy” works (= “testing_number_2”), and the blueprint-based “testing_blueprint_attr” is always “xxx”:
image

Seems that in the blueprint these vars are not set properly:

variables:
  SOURCE_ENTITY: !input input_SOURCE_ENTITY
  SOURCE_ATTR: !input input_SOURCE_ATTR

How to check: add this action into the blueprint:

action:
  - action: notify.persistent_notification
    data:
      message: |-
        SOURCE_ENTITY: {{SOURCE_ENTITY}}
        SOURCE_ATTR: {{SOURCE_ATTR}}

which causes these errors in log:

2024-11-20 04:35:10.908 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'SOURCE_ENTITY' is undefined when rendering 'SOURCE_ENTITY: {{SOURCE_ENTITY}}
SOURCE_ATTR: {{SOURCE_ATTR}}'
2024-11-20 04:35:10.909 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'SOURCE_ATTR' is undefined when rendering 'SOURCE_ENTITY: {{SOURCE_ENTITY}}
SOURCE_ATTR: {{SOURCE_ATTR}}'

after HA reboot and after every change of “testing_number_2” helper - which is supposed to trigger the sensor.

Also, I may speculate that this is unsupported:

trigger:
  - platform: state
    entity_id: !input input_SOURCE_ENTITY
    attribute: !input input_SOURCE_ATTR

but only can guess since we have no Docs so far.

A super simple test:

blueprint:
  name: xxx
  domain: template
  input:
    input_Var_1:
    input_Var_2:

variables:
  Var_1: !input input_Var_1
  Var_2: !input input_Var_2

trigger:
  - platform: state
    entity_id: input_boolean.test_boolean

action:
  - action: notify.persistent_notification
    data:
      message: |-
        Var_1: {{Var_1}}
        Var_2: {{Var_2}}

sensor:
  state: >-
    {{ Var_1|int(default=0) + Var_2|int(default=0) }}
template:
  - name: testing_blueprint_xxx
    use_blueprint:
      path: xxx.yaml
      input:
        input_Var_1: 12
        input_Var_2: 34

Causing

2024-11-20 04:48:34.370 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'Var_1' is undefined when rendering 'Var_1: {{Var_1}}
Var_2: {{Var_2}}'
2024-11-20 04:48:34.371 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'Var_2' is undefined when rendering 'Var_1: {{Var_1}}
Var_2: {{Var_2}}'
2024-11-20 04:48:34.373 ERROR (MainThread) [homeassistant.helpers.sensor] Error rendering state template for sensor.testing_blueprint_xxx: UndefinedError: 'Var_1' is undefined


on every change of “input_boolean.test_boolean”.

Seems that blueprints for template sensors are not functional.
Or there is smth which I miss.
BTW docs here are still incomplete.

issue

The issue seems to present in trigger-based sensors.
Here variables work as expected:

blueprint:
  name: xxx
  domain: template
  input:
    input_Var_1:
    input_Var_2:

variables:
  Var_1: !input input_Var_1
  Var_2: !input input_Var_2

sensor:
  state: >-
    {{ Var_1|int(default=0) + Var_2|int(default=0) + states('input_number.test_number')|int(default=0) }}

I know that it is a work-in-progress at this point. If it’s not in the DOCS yet, expect that to not work as expected.
All of the template domains had to be converted to the new syntax and have legacy translated to work with that. Currently many of the domains are in the legacy syntax under the hood with translators when you use the new syntax, or that’s how I understand it. So these Blueprints turned into a multi-month endeavor.
Personally I would have put EXPERIMENTAL tag on the project, but not my circus.

2 Likes

Well, have to agree about “experimental” (“beta-test on your risk”).

2 Likes