WTH, Why can't template sensors have a state_class:?

Month of "What the heck?!"
1

I finally purchased my power monitor, created a RESTful sensor to get the data and parsed it into the individual values with templates.

You can imagine my disappointment when the values don’t show up in the integrated energy monitoring. I obviously made a series of assumptions here but WTH!!!.

Sensors for energy monitoring require “state_class: measurement” so they will be retained long term.

I see this as a limitation to adding devices into energy monitoring and hope it can be rectified. I’m currently having to use the integral to sum my consumption and some history graphs.

I hope we’ll eventually see an integration for it. [Eyedro, I selected it because they are local]

Mark

2

You can add state_class: measurement to your sensors with customize:

  customize:
    sensor.entity_id:
      state_class: measurement
3

The legacy template sensor format does not support and will not support state_class (except by using customize).

Legacy formats are only included for backward compatibility and will not get new features.

The new format for template sensors do support state_class:

https://www.home-assistant.io/integrations/template/#state-based-template-binary-sensors-buttons-numbers-selects-and-sensors

Screenshot 2022-10-07 at 22-05-54 Template
Screenshot 2022-10-07 at 22-05-54 Template850×434 10.1 KB

If you are making new sensors you should be using the new format.

4

Thanks, the progress with HA is amazing, I suspect I’ll have to just start fresh. Between all the bluetooth updates and general improvement I have a crap ton of work to do to get caught back up!!

5

Be aware, unless it has changed, refactoring legacy format template sensors to the new format raises some issues with entity naming. You’ll get new entities with template_* in the name.

(To me this should be a WTH itself. but maybe I’m out of date.)

6

I converted all my templates sensors to the new format and did not see that. Under what circumstances does it occur?

7

It occurs if you swap and add a unique id in the process. If you add the unique_id prior to the swap, it doesn’t happen.

1 Like
8

Thanks for that clarification.

IIRC using friendly_name also introduced some complexity that played into that.

9

I did not bother with unique id’s so that would explain why I did not see the “feature”.

However if you do add a unique id that should make it possible to change the name from the front end. So it’s a bit less of an issue I guess.

10

The “issue” only arises when you want a different name for your entity_id and name. If you omit the name, it uses the unique_id to create the entity_id.

1 Like
11

Yes, you can change the name and area in the UI once you set a friendly name, though it does wind up being a multi-step process.

I also noticed If you only specify unique_id, you’ll still wind up with sensor.template_

  - binary_sensor:                                                                │
    - unique_id: lyric_hvac_running                                               │
      state: >                                                                    │
        {{ is_state('sensor.lyric_hvac_action', 'heating') or                     │
           is_state('sensor.lyric_hvac_action', 'cooling') }}
12

You only wind up with template_ when you only specify a unique_id. The entity_id is first taken from name, and as a backup, it’s taken from unqiue_id with template_ appended to the front. There’s nothing else to the rule. This is actually how all integrations (non-platform) that provide both name and unique_id handle the entity_id.

1 Like