Helper for Template Sensors

So, I’ve been thinking, with all the great helpers we currently have in HA and that 20% of the install base of HA use templates, why is it still that this has to be done by editing the configuration.yaml file, which is probably quite a task for newcommers.

Well, rather than just ponder, I have started writing a helper for template sensors. Below are the demo videos. I intend to release this in the next week or so (maybe HACs initially and then try and move it into core). It still needs some finesing and documenting.

Looking for feedback on the following (understand this is just an initial demo video):

  1. Is this something people think is a good addition to HA?
  2. Does it look intuative and easy to use?
  3. Is there some killer functionality that is maybe missing/would be good to include?

Videos

Binary Sensor
binary_template_sensor

Sensor
template_sensor

11 Likes

Looks nice, will you still be able to edit them manually in config?

1 Like

I never use the ui for anything unless i have to but I think it looks interesting.

No, doing it as an integration means it is no longer stored in configuration.yaml.

I see it as that you can use the developer tools to create your template and then copy and paste into the helper for more complicated things, but for simple templates (prob a high percentage) and for newer users, it walks you through the different options. For example, you can only pick UOMs and state classes related to the device type selected so you cant pick incompatible ones. Personally i also think it is quicker to add a simple template than via config.yaml.

Agreed. I will test when available. :slight_smile:

To answer your questions:
1 - Yes
2 - Yes, but need to test to provide better feedback
3 - Hmm, I needs to think about that (also related to 2)

Looks great,
Maybe a preview/errors option.
Or default templates to inject

There’s a tendency, in Home Assistant’s migration from YAML configuration to config flow, of losing functionality in the process. In other words, the config flow version doesn’t always include all available features (that exist in the YAML version).

For example, in your demo, how would one add attributes or template the availability and icon options? Perhaps all of that is already possible but not shown in the demo?

To create one new entity, probably yes.
To create multiple new entities, no.

I can create a new entity based on an existing Template entity. It’s faster (for me) to simply copy-paste an existing configuration and modify it.

Don’t get me wrong, I like what you have created but feel it’s merely the starting point for the features it should support before actually adding it to Home Assistant.

Also, do you intend on including support for Trigger-based Template Sensors?

3 Likes

OK, I have made an initial beta release so that it can be played with to see what we think.

2 Likes

@123 agree with your comments. I am certainly expecting to add the functionality for attributes and availability templates. Triggers maybe something too far for it. But as I said, I think experienced 'HA’ers may alway prefer to edit config.yaml but for newbies, it may make getting a first setup that little bit easier. It should probably also look to be able to create other types of platform entity but not sure if that is better as individual helpers to stop it getting too complex to use (going against the whole point of it!)

FWIW, based on helping thousands of users over the past 4+ years, I would say that composing a Template entity’s state template is a new user’s primary challenge (because it requires knowledge of Jinja2). The rest of the Template entity’s configuration is comparatively easy.

1 Like

FYI

2 Likes

Well there we go, seems not all ideas are unique! I’ll follow this and maybe contribute. Thanks.

Hi, Great this got implemented !!!

A related idea:

  • Add a group helper with a template for evaluating the member entity states.

Example:
If I want to group Alert entities, having 3 states “On, Off, acknowledged”
into a binary_sensor group having 2 states “on or off”.
By having a template option one can define a group template to calculate the group state.
The group members attribute entity_id should be availabe as a variable:

 {% set ns = namespace(counter=0) %} 
 {% for entity in entity_id %}     
      {% if states(entity) != 'idle' %}
         {% set ns.counter = ns.counter + 1 %} 
      {% endif %} 
 {% endfor %}    
 {{ 'on' if ns.counter else 'off' }}

This example evaluates off if all members are idle, but any other criteria can be made

I have 20 entities representing battery values of various sensors and I’m using the Homekit Infused dashboard which has a notification function based on the following construct:

- type: conditional
  conditions:
    - entity: binary_sensor.door_window_sensor_1485_door_left_open
      state: "on"
  card: !include
    - "../hki-base/templates/header/subtitle-notification-template.yaml"
    - icon: mdi:alert
      name: The sliding door to the pergola is open!

so when the condition(s) is(are) true it fires a notification to the dashboard.

Could I use your construct to create a helper that represents all battery entities and sets a helper to true if any of the battery sensors is lower than a threshold; say 15%? How would I go about implementing this as a helper?

@tfmeier
Template helpers are limited to defining the state template only.
You can create a template binary sensor in yaml to create very advanced template sensors.
This is an example of a battery binary sensor that evaluates the levels of all member battery entities and represent a group state for them, plus some statistics as attributes.
It looks more complicated than it is:

  • I used yaml anchors (e.g &my_variables_battery) to specify the list of battery entities only once.
  • the hard coded threshold in this example is 30%, but you can set another level for specific batteries in customize.yaml (see below)
  • it creates an attribute entity_id. By doing that this sensor can be used as a group sensor in i.e the auto-entities card and the batteries card
  • the group battery icon is set according the minimum battery level
  • the attributes low, lost and short_msg can be used in notifications.
  • I use this sensor as the source for alerts. Don’t know the Homekit Infused dashboard , but it will serve that most likely as well
  • my rf433 sensors don’t have number values, but the state ok or low. This example deals with them as well

This is the example:

- trigger:
  # Battery checks of all stationary stations around the house
  - platform: state
    variables: &my_variables_battery
      entities: &triggered_by_battery
        - sensor.mge_battery_charge
        - sensor.rf433_voorraam_battery
        - sensor.rf433_tuinhuis_battery
        - sensor.keuken_switch_battery_level
        - sensor.keukenblok_switch_battery_level
        …
      batteries: "{{ expand(entities) | map(attribute='state') | list }}"
      values: "{{ batteries | reject('in', ['unavailable', 'unknown','ok']) | map('int',25) | list | sort }}"
      lost: "{{ batteries | select('in', ['unavailable', 'unknown']) | list | count }}"
      low: >
        {% set ns = namespace(count = 0) %}
        {% for entity in entities %}
         {% if states(entity) not in ['unavailable', 'unknown','ok'] %}
          {% set bat_min = state_attr(entity, 'bat_min') or 30 %}
          {% if (states(entity) | int(0)) < bat_min %}
           {% set ns.count = ns.count+1 %}
          {% endif %}
         {% endif %}
        {% endfor %}
        {{ ns.count }}
      
    entity_id: *triggered_by_battery
  - platform: homeassistant
    event: start
    variables: *my_variables_battery
  binary_sensor:
  - unique_id: batteries
    name: "Batteries group"
    state: "{{(lost+low)>0}}"
    attributes:
      entity_id: "{{ entities }}"
      low: "{{ low }}"
      lost: "{{ lost }}"
      short_msg: "lost:{{lost}}, low:{{low}}"
    device_class: problem  
    icon: >
      {% set level = (values[0]/10) | round(0,"ceil",2)*10 if lost == 0 else 0 %}
      mdi:battery{{ '-alert' if level == 0 else  '-'~level if level < 100 }}

Optionally a default threshold can be defined in customize_glob.yaml:

"sensor.*battery*":
  bat_min: 30

And an optional different threshold can be set for particular sensors in customize.yaml like this:

# batteries with specific limits
sensor.keukenblok_switch_battery_level:
  bat_min: 15 
1 Like