Unreliable syntax for a jinja script

Configuration
21

@petro

Thanks fo the comment. Can you say why my code throws this up and can be ignored ?

I don’t want to explicitly list entities otherwise I need to maintain every time I change things. Eg, I am gradually splitting my heavy use items into peak/shoulder/offpeak to track what is costing most and this string matching code will catch and ignore them without amendment.

22

Because the template references the entity it resides in, but you filter that entity out.

You don’t have to if you use group.set.

2 Likes
23

@petro Thanks, that really helps and explains.

24

For anyone interested, @petro solved it for me and here is my final code. Edited to exclude unknown etc dynamically not at startup.

template:
  - sensor:
      - name: Untracked Power Usage
        state: >
          {% set ns = expand('group.tracked_power_list')
          | rejectattr('state', 'in', ['unavailable','unknown']) 
          | map(attribute='state') | map('float', 0) | sum %}
          {{ (states('sensor.power_total') | float(0) - ns) | round(2) }}
        unit_of_measurement: "W"
        device_class: "power"

automation:
  - id: MakeGroupOfPowerEntities
    alias: Power Entity Group
    trigger:
      - platform: homeassistant
        event: start    
    action:
      - service: group.set
        data_template:
          object_id: tracked_power_list
# Get all sensors with power 
# but ignore duplicated entities, battery powered devices and power in-coming entities.
          entities: >
            {{ states.sensor
            | selectattr('attributes.unit_of_measurement', 'defined') 
            | selectattr('attributes.unit_of_measurement', 'eq', 'W')         
            | rejectattr('object_id', 'search', 'shelly|other|aca_|acb_|peak|shoulder|battery|power_tot|office_x34|untracked|all_lights')
            |  map(attribute='entity_id') | join(',') }}
    mode: single
2 Likes
25

Oh, right… I got halfway there, but see now where I went wrong: the listener subscribes to changes in states.sensor and the warning is that HA is preventing a recursive loop, because the sensor being updated is in there. What I missed, was that the filter is obviously after the fact and hence the warning remains.