Add counter/sensor to Long-term Statistics

Configuration
1

Hey,
Can anybody help me how to add my counters and my
energy_cost - sensors to the long term statistics?
Their unit_of_measurement would be ‘€’ and no measurement

Thanks

1 Like
2

To be included in LTS a sensor must have an appropriate state_class. It is not possible to include counters. Only sensors.

3

OK, so I have to create a sensor with the state_class measurement that saves my values.

4

No, you can add the attribute to your existing sensors either directly if they support it, or by using customize.

5

Sorry but I can’t get it.
That’s my configuration:

homeassistant:
  customize:
    counter.huhnereier_tag:
         state_class: measurement
    sensor.daily_energy_cost:
         state_class: measurement
         device_class: monetary

They’re both showed with these attributes, but won’t work with statistics.

6

Pretty sure the counter does not support a state_class. That’s only for sensors.

Your sensor should begin to accumulate LTS.

7

Finally solved it
with (configuration.yaml)

homeassistant:
  customize:
    sensor.eier_daily:
         state_class: measurement

and (sensor.yaml)

- platform: template
  sensors:
    eier_daily:
      friendly_name: Eier Tag
      value_template: "{{ states('counter.huhnereier_tag') }}"

Thank you :pray:

7 Likes
8

This helped me, thanks

9

Could you not have just added this under the sensor definition instead of adding a separate customize entry?

10

I’m also curious about that.

11

This seems like a good WTH. I’m not sure why the history of a counter can’t just be downsampled for long term statistics. It is easy enough to create a copy of the counter entities as sensors, but it shouldn’t be necessary.

12

There was talk of removing the state class from all helpers until it was pointed out that a utility meter with on LTS would be pointless.

I missed this:

The reason they can’t is because they are using the legacy template sensor platform. Which, while still valid, is not getting new features. So it does not support state_class. If they had used the new template integration to define the sensor then, yes, they could have added the state class there. e.g. instead of:

sensors.yaml

- platform: template
  sensors:
    eier_daily:
      friendly_name: Eier Tag
      value_template: "{{ states('counter.huhnereier_tag') }}"

Do this:

configuration.yaml

template:
  - sensor:
      - name: Eier Tag
        unique_id: eier_tag
        default_entity_id: sensor.eier_daily # required as the "name" option does not match slug from original sensor
        unit_of_measurement: "€"
        state_class: measurement
        device_class: monetary
        state: "{{ states('counter.huhnereier_tag') }}"

This is why you should use the new template integration for all new template sensors. Not the legacy template sensor platform.