Template entities and helpers best practice

Configuration
1

I am using HA for a long time and it seems, I got lost a bit, so perhaps someone can help me structuring my config in the right way.

First of all, I got all my configs defined in YAML and arranged it into seperate files and defined as follows in configuration.yaml:


# Components
switch: !include_dir_merge_list components/switches
sensor: !include_dir_merge_list components/sensors
climate: !include_dir_merge_list components/climate
notify: !include_dir_merge_list components/notify
mqtt: !include_dir_merge_named components/mqtt

Of course, I noticed, more and more configs moved to the UI, completely understandable for less technical users. I must say, I often have the feeling that this gives me less controll over de configuration. For example: If one of my ONVIF camera;s get’s a different IP address, I can’t just hange that, but have to completely remove and reinstall that camera, and probably adjust all of the scripting and UI stuff. However, this is just a little sidestep from this topic.

I do use a lot of templates. These where defined in seperate yaml files, for example, like this climate.yaml:

- platform: buienalarm
  timeframe: 5
  name: buienalarm
  monitored_conditions:
   - temperature
   - precipitation
   - precipitation_forecast_average
   - precipitation_forecast_total 
   - next_rain_forecast

- platform: template
  sensors:

    weater_hot:
      friendly_name: "Warme Dag"
      value_template: >  
          {{ states("sensor.buienradar_temperature_1d") | int(0) > 22 }}

    weather_hot_cooling:
      friendly_name: "Zet het raam open om af te koelen"
      value_template: >  
        {{ 
        (states("sensor.smoke_detector_air_temperature_bedroom") | float(0) + 0.5 > 
        states("sensor.pir_motion_sensor_with_temperature_sensor_air_temperature_2") | float(0))
        and states("sensor.smoke_detector_air_temperature_bedroom") | float(0) > 21
        }}

- platform: statistics
  name: humidity bathroom avg
  entity_id: sensor.humidity_bathroom
  state_characteristic: average_linear
  max_age:
    hours: 24

As you can see, I grouped different climate stuff togehter, like a buienalarm platform, template sensors and statistics.
However it seems there is a ‘new’ notation for templates and somehow I have the feeling this is the recommended way. Let’s take for example de configuration for the ‘weather_hot’ sensor from the example above. This could also be defined in the new way as:

template:
  - unique_id: 490d20e7-29ae-49da-86e9-dc3f410cb300
    name: 'warme_dag'
    icon: mdi:weather-sunny
    device_class: binary_sensor
    state: >-
          {{ states("sensor.buienradar_temperature_1d") | int(0) > 22 }}

It gives some extra options, like a unique_id, icon, device_class but the friendly_name seems to be gone. Notice that the platform statement seems to be gone too. If I want to store my templates as seperate files, I remove the template: statement and move that to configuration.yaml like this: template: !include_dir_merge_list components/template. However, I cannot combine it with other platform types anymore, leaving the buienalarm integration seperated from other climate stuff (untill the buienalarm integration gets converted to the UI).

It gets more complicated when I look at a switch template. As you can see in my configuration.yaml it points to a folder where I could define switches:

# Components
switch: !include_dir_merge_list components/switches

Then one of the switches could be defined like this:

- platform: template
  switches:
    alarm:
      friendly_name: "Alarm ingeschakeld"
      icon_template: mdi:alarm-light
      value_template: "{{ states.variable.alarm.state }}"
      turn_on:
        service: variable.set_variable
        data:
          variable: 'alarm'
          value: 'on'
      turn_off:
        service: variable.set_variable
        data:
          variable: 'alarm'
          value: 'off'

In the ‘new’ way, it seems I cannot define the turn_on and turn_off anymore, so I have to maintain separate automatons for them.

Finally we have the growing set of helpers. switches can be defined as helpers. Like the ‘new notation’ I cannot add simple automations to the turn_on and turn_off events in helpers though. Templates cannot be defined as helpers, although more and more kinda predefined templates become available, like threshold sensor.

Of course this is great for less technical people, but somewhat limted. Unfortunately, it is not possible to switch from GUI to YAML mode like in lovelance.

So what are the best practices here:

  1. Do I need to convert all templates to the new template notations because the ‘old’ notation will become obsolete?
  2. Do I need to use the helpers as much as possible?
  3. How about packages?
  4. Is there another elegant way?

And:
a. I would love to see an option to switch edit the helper and device configs to yaml mode like in lovelance
b. I would love to see the option to define simple automatons like switch on and of in the helper
c. I would love to see the helpers completed with binary sensors

1 Like
2

Only if you want to take advantage of new fields that are available.

That’s personal preference. I personally don’t like helper entities, I try to keep everything automatic via template entities.

That’s a good way to separate your config. Many advanced configs use this method.

Do whatever works best for you. There’s no ‘1 ring to rule them all’.

As a sidebar, template switches have not moved to the ‘new’ style. So the old style is the only way at the moment.

1 Like