A helper sensor that calculates the min value from an attribute in list of input sensors?

Configuration
1

Helpers has a category named “Combine the state of several sensors” which can calculate the mean, max, min and other statistics values from the state value of all sensors added to the group.
What I need to do is exactly this, but not using the state values but rather an attribute value common to all the sensors in the group.
Is that possible?

2

You have to create templates sensors for each attribute. Then uses those new sensors in the helper.

Alternatively you can create three template sensors (min, max, mean) that operate on the attributes directly.

As an example:

template:
  - sensor:
      - name: Foobar Maximum
        unit_of_measurement: '%' # or whatever it is
        state: >
          {{ [ state_attr('sensor.foo1', 'bar_attribute1')|float(0), 
               state_attr('sensor.foo2', 'bar_attribute2')|float(0), 
               state_attr('sensor.foo3', 'bar_attribute3')|float(0), 
               state_attr('sensor.foo4', 'bar_attribute4')|float(0) ]|max }}
        availability: >
          {{ state_attr('sensor.foo1', 'bar_attribute1')|is_number and 
             state_attr('sensor.foo2', 'bar_attribute2')|is_number and 
             state_attr('sensor.foo3', 'bar_attribute3')|is_number and 
             state_attr('sensor.foo4', 'bar_attribute4')|is_number }}

      - name: Foobar Minimum
        unit_of_measurement: '%' # or whatever it is
        state: >
          {{ [ state_attr('sensor.foo1', 'bar_attribute1')|float(0), 
               state_attr('sensor.foo2', 'bar_attribute2')|float(0), 
               state_attr('sensor.foo3', 'bar_attribute3')|float(0), 
               state_attr('sensor.foo4', 'bar_attribute4')|float(0) ]|min }}
        availability: >
          {{ state_attr('sensor.foo1', 'bar_attribute1')|is_number and 
             state_attr('sensor.foo2', 'bar_attribute2')|is_number and 
             state_attr('sensor.foo3', 'bar_attribute3')|is_number and 
             state_attr('sensor.foo4', 'bar_attribute4')|is_number }}

      - name: Foobar Mean
        unit_of_measurement: '%' # or whatever it is
        state: >
          {{  ( ( state_attr('sensor.foo1', 'bar_attribute1')|float(0) +
                  state_attr('sensor.foo2', 'bar_attribute2')|float(0) +
                  state_attr('sensor.foo3', 'bar_attribute3')|float(0) + 
                  state_attr('sensor.foo4', 'bar_attribute4')|float(0) ) / 4 )|round(2) }}
        availability: >
          {{ state_attr('sensor.foo1', 'bar_attribute1')|is_number and 
             state_attr('sensor.foo2', 'bar_attribute2')|is_number and 
             state_attr('sensor.foo3', 'bar_attribute3')|is_number and 
             state_attr('sensor.foo4', 'bar_attribute4')|is_number }}

Note: I have included |float filters for each attribute to convert them to floating point numbers in case they are strings. Unlike states (which are always strings) attributes can be any type. So if they are already numbers you don’t need these filters.

Or do this for each sensor and use the helper:

template:
  - sensor:
      - name: Foo1 Bar1
        unit_of_measurement: '%' # or whatever it is
        state: "{{ state_attr('sensor.foo1', 'bar_attribute1')|float(0) }}"
        availability: "{{ state_attr('sensor.foo1', 'bar_attribute1')|is_number }}"

      - name: Foo2 Bar2
        unit_of_measurement: '%' # or whatever it is
        state: "{{ state_attr('sensor.foo2', 'bar_attribute2')|float(0) }}"
        availability: "{{ state_attr('sensor.foo2', 'bar_attribute2')|is_number }}"

      - name: Foo3 Bar3
        unit_of_measurement: '%' # or whatever it is
        state: "{{ state_attr('sensor.foo3', 'bar_attribute3')|float(0) }}"
        availability: "{{ state_attr('sensor.foo3', 'bar_attribute3')|is_number }}"

      - name: Foo4 Bar4
        etc...

Which method you choose depends on how many attributes you have. If you have more than 3 sensor attributes then the first method becomes more efficient. Three or less sensors and the second method is less work.

1 Like
3

Thank you very much for taking the time to provide such an extensive answer :slightly_smiling_face:
I ended up doing what you suggested in your very first sentence.
However, I think it would be a good idea to provide som means of controlling what should be exposed as an entity’s state value. The default or any one of it’s attributes. Having to create yet another sensor just to get hold of an attribute value, is not very efficient. I’m now referring to situations where templating doesn’t work.

4

Please provide an example of a situation where templating doesn’t work.

5

You can also add a state_class and then you’ll have those values for each sensor it’s added to.

6

Please provide an example of a situation where templating doesn’t work.

‘Helpers’ doesn’t seem to accept anything other than clean entity names.

7

You can also add a state_class

I don’t understand. Please prove a syntax example when creating a helper.

8

I can’t, because you gave fictional sensors. There are several state classes, but if e.g. it’s a temperature, you’d add state_class: measurement. Where you add it depends on the sensor’s definition, but it can always be added via customize.yaml. Such sensors will have long-term tracking, but also a mean, min and max. You can see this when plotted with e.g. a stats card.

A more advanced option would be to use the statistics integration.

9

The development team now prefer if new integrations do not use attributes. Some older integrations have even been changed to use sensors for what was exposed as attributes (e.g. Sun and Moon integrations).

Which integration are you using?

1 Like
10

I’m not using any particular integration. I’m just creating a number of sensors from an API call. Here’s an example of one:
image

11

Well if you are creating them create Waratahs you want as sensors rather than attributes.