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):
Is this something people think is a good addition to HA?
Does it look intuative and easy to use?
Is there some killer functionality that is maybe missing/would be good to include?
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.
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?
@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 statetemplate is a new user’s primary challenge (because it requires knowledge of Jinja2). The rest of the Template entity’s configuration is comparatively easy.
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
