Difference between "sensor platform Template" and "Template sensor "

Configuration
1

Hello,

I have several templates in my configuration (from multiple source) that work but are written differently
So I wonder what is the difference/best pratrice between .

sensor:
  - platform: template
    sensors:
      energy_return:

AND

template:
  - sensor:
      - name: "energy_return"
12 Likes
2

First one is legacy method, second one is new and advised method. Template - Home Assistant

15 Likes
3

Thanks for reminding me! I need to start updating my config file.

Any tips on making this change in a config that’s got lots of templates under sensor:?

Will automations, scripts and Lovelace cards need to be changed, or will the name: just be used same as it was in the old-style entry under sensors:? Will the Recorder database entries remain the same?

4

Just make sure the “name” of the “new” sensor matches the name of the old one… Everything else will be transparent… History is kept if name is the same…
Be careful about the changes: no “friendly name” allowed and “value”/“value_template” are becoming “state”…

2 Likes
5

Not sure if you have to migrate, i don’t recall any deprecation notice on this topic per se.

6

Thank you fuatakgun

CaptTomTom : No problem with migration, my sensors are still working.
It only apply to “platform:template”, no all sensors.

1 Like
7

So, I have a few entries in sensor.yaml. Should I move them to template?

In templates.yaml I only have - sensor: for now.

If I just copy the code from for example - platform: rest (sensor.yaml) it fails.

What i the official way to do this properly?

8

From your sensor.yaml file, you can only migrate the entries defined with - platform: template. Your existing - platform: rest sensors should remain as is.

As you copy your - platform: template entries, remove the friendly_name properties, and change value: and/or value_template: to state: so they fit the new format of templates.yaml.

I recommend to try it with one simple template sensor – comment it out in the old place, then paste it in the new place, with the new syntax in mind.

1 Like
10

I’m starting this migration mainly so that I can get stats on some of the sensors. Can you mix and match? i.e. i have sensors defined in 4 different files. Can 2 files be -platform: template and 2 files be template: -sensor? or do I have to migrate all -platform: template sensors at once across all files?

Thanks!

11

From everything I’ve seen, currently there isn’t a plan to deprecate the legacy format. As long as you set your files up using the correct top-level configuration keys and the files are properly included in your configuration.yaml file, you can have both formats… if you use packages, you can even have both formats working in the same file.

12

Awesome. I’ll give it a try :slight_smile:

13

Currently my sensors are in different files based on domain. They are included in configuration.yaml like this

“sensor: !include_dir_merge_list sensors/”

- platform: template
  sensors:
    solar_power_total_current_production:
      unique_id: 9fb71580-0687-434e-96c0-efc58cdc43cd
      friendly_name: "Total Current Power Production"
      unit_of_measurement: "W"
      value_template:

When moving to the new format, do they need to be included in configuration.yaml via

“template: !include_dir_merge_list templates/”

template:
  - sensor:
    - name: "Total Current Power Production"
      # solar_power_total_current_production:
      unique_id: 9fb71580-0687-434e-96c0-efc58cdc43cd
      unit_of_measurement: "W"
      state: "{{(states('sensor.envoy_current_power_production')|float) + (states('sensor.envoy_current_power_production')|float)}}"

When I left them included via sensor:, vscode gives me an error indicating “missing property “platform”” deriving from “Property template is not allowed.yaml-schema: http://schemas.home-assistant.io/integration-sensor”

Thoughts?

14

No need to split by a domain, you may split by “task” - like “for floor plan”, “garden”, “home climate” etc.
post.

15

That’s what I meant by domain. i.e. solar, tesla, 3d printer, etc

16

Then you do not need this:
“template: !include_dir_merge_list templates/”

Add packages where every package is a file containing helpers, sensors, templates, scripts, automations, customizations etc.
Details in my link above.

18

Maybe no deprecation announced yet, but for example state_class: can be defined in the new format only.
This might be important in order to make statistics working.

20

Does anyone know why this is different for some entities, e.g. switches? There, the old format is still recommended: Template Switch - Home Assistant

21

Likely, there was no need or advantage to switching them over. The trigger-based functionality that was added with the newer method for sensors, etc doesn’t really make sense for Locks, Lights, Switches…

1 Like