Migrating legacy templates to the new template section

I organize mine this way as well, with everything related to a particular “feature” (like my Roomba or Frigate, for example) in its own package file, including any sensors, input helpers, automations, etc…

So using the new template format (or trigger templates in general) would completely break my organization.

I found this thread because I was also trying to replace some of my ‘legacy’ sensors in a package with the ‘modern’ sensor.
I was actually trying to get the new Statistics Graph Card to work but a sensor was not showing up. Apparently, specifying “device_class: temperature” was not enough; it also needed “state_class: measurement”. But that’s not available in the legacy.
Does anyone have any insight into how to add a “state_class: measurement” to a legacy template sensor?

- platform: template
  sensors:
    temperature_raw:
      device_class: temperature
      unit_of_measurement: °F
      value_template: >
        {{ state_attr('sensor.28_FF2F0DC01701_temperature', 'raw_value')  *1.8 +32 }}

And I hope there’s a way to keep the ‘modern’ sensors in packages for organization…

Until the new template sensors will be available in packages (if they ever will be), you can cjstomize the entity to add the attribute, e.g. from my system:

homeassistant:
  customize:
    sensor.energy_daily_lights:
      last_reset: "2021-07-30T00:00:00+00:00"
      state_class: measurement
1 Like

From a purely objective point of view I really don’t see any rational argument for them not being.

Clearly there may be very good technical reasons but that would then just beg the question how did they ever get past any kind of architectural discussion?

I’d be interested to know what percentage of HA users use packages.

There are probably some (major) technical difficulties, otherwise I don’t see a reason why it shouldn’t be possible from the beginning.

@klogg and @Burningstone

Take a look here and vote, if it fits your needs. :wink:

1 Like

Did this already in the beginning :wink:

1 Like

Yep, me too.

1 Like

following along, Attempting to create a sensor for the energy part.
I have my config/templates folder created.

inside my config/integrations/templates.yaml I have:

bash-5.1# cat templates.yaml
---
#  Templates / Test Sensors
#
#
template: !include_dir_merge_list ../templates

Then I created: config/templates/test-template.yaml

bash-5.1# cat test-template.yaml
---
# Test Templates (Energy)
#
#
- sensor:
  - name: "Envoy Test Sensor"
    unit_of_measurement: "kWh"
    state_class: measurement
    device_class: energy
    state: "{{ (((states('sensor.envoy_122001xxxxxx_lifetime_energy_consumption')| float / 1000 - states('sensor.envoy_122001xxxxxx_lifetime_energy_production') | float / 1000)) / 1000 )| round(2) }}"

It’s showing up now… (so that’s nice!)
image

…however it doesn’t show up in the energy section as a valid sensor. I’ll swing over that another thread to see what I am missing, but this thread helped to get the sensor showing up in HA. (maybe this will help someone else).

The attribite last_reset is missing, which is required by the energy dashboard. You can add it through customization.

something else i have noticed in trying to use the new template format… is that Check Configuration will not catch all the issues. I have had it say everything is “OK” only to see the errors in the home-assistant.log.

I’m not sure that is only related to new template sensors.

It seems to be happening to me on several different yaml configured things lately.

i’m not sure if it’s some change to the config checker or not but I have never had it miss so many errors and report ‘valid’ only to have the errors pop up in the logs (or as a persistent notification) before just recently.

I noticed the same thing.

I even recently pointed it out to someone who claimed Check Configuration reported no error but they overlooked the fact there was an error and it was reported in Log (along with a persistent notification). That’s new behavior and make the “Configuration valid!” message misleading.

Unless by ‘new’ you mean several months, it’s not.
I was first caught out by this a while ago and it still happens occasionally even though I know to look for new notifications before I trust that (now useless) “Configuration Valid!” message.

There are some things that really surprise me about HA and this is one of them. So much seems to be so carefully thought out and I often hear about proposed changes being scrutinised to within a inch of the developer giving up and going home, that quite how this slipped through the net is beyond me!

But hey ho!

Each month represents one new version so how many versions ago did you first notice it?

I can’t recall precisely but it seems like it’s been doing this for at least the last 3 versions (so June, maybe even May). Did you notice it in an older version?

I noticed this a few months ago for the first time. But I can’t pinpoint it more closely… Could be anything between three and seven or even eight months, my feeling tells me, it’s rather seven than three. Sorry, can’t say for sure.

In my experience the “Config check” reports ok, if the error isn’t blocking a restart. These errors do show in the log. But this is just off the top of my head, I didn’t pay attention, I just started to lock in both places… :slight_smile:

To be honest I couldn’t tell you but it feels like more than three or four months ago.

All this to say that it makes it challenging to report the issue to the developers when at least four people (including me) can’t recall when it all started.

Unless I am misremembering, it seems to me there was a time when config errors were never reported via a persistent notification pointing to the Log but only via the UI, jammed under the Check Configuration button. Maybe this all started when the decision was made to use persistent notification as an additional way to grab one’s attention. :thinking:

That is how I remember it…

I don’t know. Maybe I’m just making more errors recently but it seemed to only start for me in the release right before this one…so 2021.7.