Blueprint variable contains None after Jinja2 code has been executed

Hi, I’m trying to write a small blueprint which shall trigger an action, when entities of device_class: problem and integration: shelly turning on.
I have created a sensors variable at fill it with the help of some Jinja2 code. At the end it shall provide a string return, containing all friendly_names of Shelly problem entities which are turned on.

In the automation I want to send notifications, which shall include the content of the sensors variable. For whatever reason, within the action the sensors variable contains the correct amount of entities turned on, but instead of the friendly_name they are always printed as None.

When I execute the Jinja2 code with the help of the Developer Tools, then the return is like I want to have it: A string with comma separated friendly_names of the affected entities

I already have two other blueprints with similar code and they work fine. Major difference between them is, that the one which is not working, uses platform: state as trigger.

I’m pretty sure, that I have a mistake somewhere, or even worse, I misunderstand some concept/workflow of blueprints…

Any idea would be helpful and appreciated.

Here the code of the blueprint:

blueprint:
  name: Detection of Shelly senors for overheating, overpowering and overvoltage
  description: Monitors the Shelly sensors for overheating, overpowering and overvoltage as trigger for user defined actions
  domain: automation
  input:
    shelly_entities:
      name: The Shelly entity to check for problems
      description: The Shelly problem entities will trigger the action
      selector:
        entity:
          multiple: true
          filter:
            integration: shelly
            device_class: problem
    exclude:
      name: Excluded Sensors
      description: Shelly entities to exclude from detection. Only entities are supported, devices must be expanded!
      default:
        entity_id: []
      selector:
        target:
          entity:
          - device_class:
            - problem
#    user_conditions:
#      name: (Optional) Additional Condition(s)
#      description: In case of additional conditions must be met, they can be defined here
#      selector:
#        condition:
    actions:
      name: Actions
      description: Notifications or similar to be run. {{sensors}} is replaced with the names of sensors having problems.
      selector:
        action: {}
variables:
  exclude: !input exclude
  sensors: >
    {% set result = namespace(sensors=[]) %}
    {% set all_shelly_device_ids = integration_entities('shelly') | map('device_id') | unique | list %}
    {%- for shelly_device_id in all_shelly_device_ids %}
      {% set shelly_entity_list =  device_entities(shelly_device_id) %}
        {%- for shelly_entity in shelly_entity_list %}
          {% if not shelly_entity in exclude.entity_id %}
            {%- if is_state_attr(shelly_entity, 'device_class', 'problem') and is_state(shelly_entity, 'on') %}
              {% set result.sensors = result.sensors + [state_attr(shelly_entity, 'name')] %}
            {%- endif %}
          {%- endif %}
        {%- endfor %}
    {%- endfor %}
    {{ result.sensors | join(', ') }}
trigger:
  - platform: state
    entity_id: !input shelly_entities
    to: 'on'
#condition:
#- and
#    - '{{ sensors != '''' }}'
#    - !input user_conditions
action:
- choose: []
  default: !input actions
mode: single

And here the defined action when I configure the blueprint:

service: notify.persistent_notification
metadata: {}
data:
  message: >
    Schwerwiegende Probleme mit den folgenden Shelly Geräten entdeckt:
    {{sensors}}
  title: Schwerwiegende Probleme mit Shelly Geräten entdeckt

I’m not good enough at templates to pick out the error on the fly like this, but I would plug that into developer - templates and troubleshoot it to solve that.

Open your Home Assistant instance and show your template developer tools.

I think you’ve made your template much more complicated than it needs to be, but there are a number of choices that are a little confusing:

If the blueprint is based off a selected group of Shelly devices why is the notification template starting with all Shelly devices. Why not start from the list generated by shelly_entities?

Is there a reason the template is getting all the entity IDs, then converting them to device IDs, then converting them back to entity IDs?

I don’t have enough problem sensors to test this, but I think it should do what you are trying to do:

{{  integration_entities('shelly')
| reject('in', exclude.entity_id)
| select('is_state', 'on')
| select('is_state_attr', 'device_class', 'problem')
| unique | expand | map(attribute='name') | join(', ') }}

Instead, if you used and opt-in approach you could get rid of the exclude input. Then the template could start from the list of selected Shelly entities assigned to a variable, and it would just be a matter of checking the states and getting the names:

{{  selected_shellys | select('is_state', 'on') | expand | map(attribute='name') | join(', ') }}

@Sir_Goodenough I’m always using the Template Dev Tool to test the template code. But thanks for the hint.

@Didgeridrew Yes, it is complicated. Mainly because the template code evolved when I was searching around how I can filter for the integration and device_class, etc. This is the reason for converting IDs back and forth.

Many thanks for the examples.
Both templates you had posted are working perfectly and much less complicated than mine :smile:

The original idea of the blueprint was, that the Shelly problem entities are automatically “filtered/selected” for the trigger section. But my understanding is, that the variable section is handled after the trigger was raised.

At the moment my idea is to use a helper template entity to count the devices in problem state and then using this helper as trigger, so that I can get rid of the manual entity selection in the blueprint.