Still confused about templates in configuration.yaml

Configuration
1

Could someone please help me understand sensors in configuration.yaml?

Do I understand correctly that this is the “old” way:

sensor:
  - platform: template
    sensors:
	  sensor_name:
	    friendly_name: "Friendly Name"
		unit_of_measurement: "Gallons"
		value_template: "{% if is_state_attr('some-sensor','an-attribute','the-attribute-value') -%}

And this is the “new” way:

template:
  - sensor:
      - name: "sensor_name"
	    unit_of_measurement: "Gallons"
		state_class: measurement
		state: "{{ (states('some-sensor' }}"
		
	  - name: "another_sensor"
	    state: "{{ state_attr('<some-sensor>','an-attribute') }}

  - binary_sensor:
    - name: "some_binary_sensor_name"
      state: "{{ is_state_attr('some-sensor','some-attribute','that-attributes-value') }}"

Where does this fit in with the old vs. new:

binary_sensor:
  - platform: trend
    sensors:
	  temp_falling:
	    entity_id: entity-id-here
		
  - platform: ping
    name: internet_connection
	host: 8.8.8.8
	
  - platform: template
    sensors:
	  temp-too-high:
	    value_template: "{{ states.sensor.temp.state}}

Thank you.

2

That’s the old way.

An outline of the new way, from doc

# Example configuration.yaml entry with two sections
template:
  # Define state-based template entities
  - sensor:
      ...
  - binary_sensor:
      ...

  # Define trigger-based template entities
  - trigger:
      ...
    sensor:
      ...
    binary_sensor:
      ...
1 Like
3

Thanks very much.

Do I understand correctly that all binary_sensors, including those with “- platform” under them, should be set up using the new way?

Like this:

template:
  - sensor:
      - name: "sensor_name"
	    unit_of_measurement: "Gallons"
		state_class: measurement
		state: "{{ (states('some-sensor' }}"
		
	  - name: "another_sensor"
	    state: "{{ state_attr('<some-sensor>','an-attribute') }}


  - binary_sensor:
    - name: "some_binary_sensor_name"
      state: "{{ is_state_attr('some-sensor','some-attribute','that-attributes-value') }}"

  - binary_sensor:
    - platform: trend
      sensors:
	    temp_falling:
	      entity_id: entity-id-here
		  	
    - platform: ping
      name: internet_connection
	  host: 8.8.8.8

    - platform: template
      sensors:
	    temp-too-high:
	      value_template: "{{ states.sensor.temp.state}}
4

Ping and Trend are integrations, they are no longer template sensors:

And you don’t add “Platform” to the templates because they are already under the platform of template, so:

template:
  - sensor:
    - name: "sensor_name"
      unit_of_measurement: "Gallons"
      state_class: measurement
      state: "{{ (states('some-sensor' }}"

    - name: "another_sensor"
      state: "{{ state_attr('<some-sensor>','an-attribute') }}"

  - binary_sensor:
    - name: "some_binary_sensor_name"
      state: "{{ is_state_attr('some-sensor','some-attribute','that-attributes-value') }}"

    - name: "temp-too-high"
      state: "{{ states.sensor.temp.state}}"
5

Well, now I am even more confused.

This is directly from the trend docs:

Example configuration.yaml entry

binary_sensor:

  • platform: trend
    sensors:
    cpu_speed:
    entity_id: sensor.cpu_speed
6

Yes, for the manual integration method, but it has since been updated to use integration from settings:

image
image722×560 39.6 KB

7

Oh, does that mean that creating a Helper does not create a corresponding entry in configuration.yaml?

Is there an entry added to another config file?

8

Helper entities end up elsewhere, in the .storage folder. They don’t have to be in YAML to work.

1 Like
9

No.

The “new way” only applies to Template integration-based sensors, binary sensors, buttons, images, numbers and selects… It does not affect any sensor that is platform-based or template-based entities from other integrations such as template lights, template fans, template switches, etc.

Each helper type has its own json file in .storage, there is no corresponding entry in configuration.yaml. Be aware, manually editing anything in .storage is not advised.

10

Just FYI you are missing a double quote " at the end of this template:

	  - name: "another_sensor"
	    state: "{{ state_attr('<some-sensor>','an-attribute') }}

Which is why all the text below that is red.

11

Thank you all so much!

I think this summarizes things:

  1. Helpers have a json file for each helper type, but those files should NOT be manually edited. Helpers should be created and modified via the UI.

  2. The “new” template format is for sensors, binary_sensors, buttons, images, numbers and selects only.

  3. binary_sensors (and non-binary sensors ??) that use a platform or template from other integrations (Trend or Ping, for example) are not included in the “new” (or “old” ??) format.

  4. Leaving out a closing double-quotation-mark results in red text.

12

And - simple template sensors, anything that only requires a template, and not a trigger, or a delay - can be done now in the UI they don’t have to be done in YAML.

ie - ALL your examples - can be done in the UI.

13

I think there is a confusion on your side: You seem to consider all YAML configured entities as “templates”.

That’s not the case. Generally speaking, all integration going forward will be configured through the UI (e.g. Ping mentioned before). Where / How that UI configuration ends up physically store is irrelevant, and subjet to change (currently, JSON files in the .storage directory.

When integrations have not yet been migrated to UI, they are configured through editing the configuration.yaml file (there are ways to subdivide that file, but, conceptually, there is still one file).

Most integrations define platforms like sensor, binary_sensor, …

A template is a specific integration which is special in that it defines sensors, binary_sensors, … in a specific way, and that is what I outlined above.

To be complete, an outline of configuration would be

# Example configuration.yaml entry with two sections
template:
  # Define state-based template entities
  - sensor:
      ...
  - binary_sensor:
      ...

  # Define trigger-based template entities
  - trigger:
      ...
    sensor:
      ...
    binary_sensor:
      ...

binary_sensor:
  - platform: integrationA
    conf1: foo
    conf2: bar

  - platform: integrationB
    confX: bla
    confY: bla

  - platform: template
    sensors:
      my_template_sensor:
        value_template: bla

sensor:
  - platform: integrationA
    conf1: foo
    conf2: bar

  - platform: integrationD
    confX: bla
    confY: bla

The “old” vs. “new” format regarding templates is how you define them:

  • under the template: header (new)
  • or as a “normal” platform (old)
1 Like
14

Thank you all so very much.

I can’t say I 100% fully understand, but I definetly understand a lot better than before your help.

Is there a recommended process regarding going forward once a complex HA system with a total mess of a configuration.yaml file already exists?

That is, is there a path to convert to UI-only?

15

No, partially because the UI does not offer all the functionality that YAML-defined template entities have.

For now, whether you convert legacy format template sensors and binary sensors to the new format and/or move anything to the UI is purely personal preference… AFAIK, there isn’t a functional reason to convert anything that is working the way you expect.

As other integrations have been moved to be 100% UI managed, the modus operandi has become to have them automatically migrated and raise a repair issue to tell the user that they need to remove them manually from the configuration. If the template integration ever gets moved, it is reasonable to expect that it will be handled the same way, if possible. If you wanted to prepare for that, it might be worthwhile to make sure all your YAML-configured entities are grouped together by integration or platform so they will be easy to find and remove. In other words… don’t have a “a total mess of a configuration.yaml”.