Entity ... (<class 'homeassistant.components.statistics.sensor.StatisticsSensor'>) is using state class 'measurement' which is impossible considering device class ('energy') it is using

[tefracky]

The problem

Similar to #86690, I have a problem with Version 2023.2: Entity ... (<class 'homeassistant.components.statistics.sensor.StatisticsSensor'>) is using state class 'measurement' which is impossible considering device class ('energy') it is using; Please update your configuration if your entity is manually configured, otherwise create a bug report at https://github.com/home-assistant/core/issues?q=is%3Aopen+is%3Aissue+label%3A%22integration%3A+statistics%22

If I want to add state_class: total, the following error occurs:
Invalid config for [sensor.statistics]: [state_class] is an invalid option for [sensor.statistics]. Check: sensor.statistics->state_class. (See ?, line ?).

What version of Home Assistant Core has the issue?

2023.2.1

What was the last working version of Home Assistant Core?

Not sure, but 2023.1

What type of installation are you running?

Home Assistant Supervised

Integration causing the issue

2023.01.1

Link to integration documentation on our website

https://www.home-assistant.io/integrations/statistics/

Diagnostics information

No response

Example YAML snippet

- name: Heizung Energieverbrauch Tag (Gesamt) (Statistik 24h)
  unique_id: heizung_energieverbrauch_tag_gesamt_statistik_24h
  platform: statistics
  sampling_size: 1000
  max_age:
    days: 1
  precision: 2
  state_characteristic: value_max
  entity_id: sensor.energy_consumption_total_daily

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant]

Hey there @fabaff, @ThomDietrich, mind taking a look at this issue as it has been labeled with an integration (statistics) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of statistics can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Change the title of the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign statistics Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

statistics documentation
statistics source
_{^{(message by IssueLinks)}}

[bouwew]

@tefracky I think your approach is wrong: you are trying to create a sensor with a unit_of_measurement that should be kWh/day. A sensor with such a unit_of_measurement would indeed need a state_class = total.

Instead you are creating a kWh-sensor, because the source-sensor has that unit I think?

[tefracky]

@bouwew
Unfortunately, I cannot change the unit_of_measurement:
Invalid config for [sensor.statistics]: [unit_of_measurement] is an invalid option for [sensor.statistics]. Check: sensor.statistics->unit_of_measurement. (See ?, line ?).

[bouwew]

@tefracky With wrong approach I mean you using the statistics platform.
I'm doing something similar but I'm using an input_number which I update every 24hrs via an automation.
If you want to use a platform, maybe this https://www.home-assistant.io/integrations/min_max/ might work better?

[nohn]

This started in 2023.2 for me. My config is

  - platform: statistics
    entity_id: sensor.wasserzaehler_hauptleitung
    unique_id: sensor.wasserzaehler_hauptleitung_60m
    name: "Wasserverbrauch 60m"
    state_characteristic: change
    max_age:
      minutes: 60
    sampling_size: 120

Error since 2023.2 is:

WARNING (MainThread) [homeassistant.components.sensor] Entity sensor.wasserverbrauch_60m (<class 'homeassistant.components.statistics.sensor.StatisticsSensor'>) is using state class 'measurement' which is impossible considering device class ('water') it is using; expected None or one of 'total', 'total_increasing'; Please update your configuration if your entity is manually configured, otherwise create a bug report at https://github.com/home-assistant/core/issues?q=is%3Aopen+is%3Aissue+label%3A%22integration%3A+statistics%22

Adding a state class doesn't work either:

ERROR (MainThread) [homeassistant.config] Invalid config for [sensor.statistics]: [state_class] is an invalid option for [sensor.statistics]. Check: sensor.statistics->state_class. (See /config/configuration.yaml, line 110). Please check the docs at https://www.home-assistant.io/integrations/statistics

[nohn]

It's btw not the only thing that started acting unexpected in 2023.2, see iprak/yahoofinance#87.

I don't see why "water" or "monetary" shouldn't be able to provide measurements, so to me this looks more like a bug in core than in statistics or https://github.com/iprak/yahoofinance.

[bouwew]

Looking at the statistics-code, the state_class can only be MEASUREMENT or None. Same for the min_max-code, also the state_class can only be MEASUREMENT, so not suitable for your purposes either.

[bouwew]

@tefracky @nohn have you considered using https://www.home-assistant.io/integrations/utility_meter/?
Should be more suitable for your purposes.

[nohn]

@bouwew this doesn't work for me. I need the value as sliding window: I do not need the value for every quarter hour or every hour but the value for the last 15 oder 60 minutes.

[bouwew]

@nohn your sensor.wasserzaehler_hauptleitung is a TOTAL_INCREASING sensor? Meaning the count only goes up when water is used?
If yes, and you don't want to use Utility_Meter, I would suggest using https://www.home-assistant.io/integrations/integration/
This one functions exactly as you describe.

[tefracky]

@bouwew You are right, there are some different integrations, which might be useful. However, this will be only a workaround for the problem/bug I described. Why shoud an energy sensor not have a measurement state?

[bouwew]

@tefracky the answer to your question can be found here: https://developers.home-assistant.io/docs/core/entity/sensor#available-state-classes, read under type: measurement.
Four your type of sensor, a kWh-sensor, the type "total" must be used.

[tefracky]

@bouwew No, this only describes, how it works and what is possible. As I said, there is a restriction for the using of the energy class, which does not make sence for some contexts.

[nohn]

I still don't see, why statistics shouldn't work on total_increasing sensors. You don't need to justify, but explaining helps others to understand and thus accept your decisions.

I've now removed device_class: water from my water sensor to "fix" this issue, since the statistics sensor is exactly doing what I need opposite to what utility meter, integration and derivative sensors do.

[bouwew]

Your base-sensor, sensor.wasserzaehler_hauptleitung, is a "current(-value)" sensor, it shows updates when water is acutally used.
You are creating a sensor that shows the water-use during a time-period, correct? That one is not a "current(-value)" sensor but a "total(-per hour)" sensor.

Also, you misunderstand what the integration-platform does, it does exactly what you want to achieve (make sure to use the left-method). I am using this one for a similar purpose.

But, it's your HA system, you can choose to use whatever you like :)
I'm just trying to help 🤷‍♂️

Also, I'm not making the rules, the HA Core Devs do this, I'm just showing you where to find the rules :)
I ran into the same problems/frustrations in the past, knowing what the rules are helped me understand why certain things don't work.

[nohn]

#84366 seems to be related.

[ThomDietrich]

Hey guys,
statistics dev here. The statistics component handles state class in a generalized fashion. Every statistic we derive is an aggregated form of value from your source sensor. Therefore it is a "measurement", as the component works atm.

@bouwew

state_class can only be MEASUREMENT, so not suitable for your purposes either.

True but I am not satisfied with that. The statistics component should be applicable to all statistics use cases. The one presented by @nohn certainly is. The example by @tefracky seems odd to me, please elaborate if you disagree.

I believe the real issue here is the implicit inheritance of device classes. In the config of @nohn the source entity is of device_class "water" and represents the total volume in L. The change characteristic over 60min should have the unit L/h (statistics component returns L only) and should have a different device class (strangely non defined for WATER_SPEED/VOLUME_RATE yet). The resulting statistics entity represents a momentary indicator value, not an increasing/decreasing characteristic, hence the "measurement" sensor_class is correct and not the real issue here.

Solving this issue is difficult. My opinion about this:

• A statistics sensor with it's moving window always represents a measurement, hence state_class=measurement

• A statistics sensor's device_class is currently derived from the source entity and the configured state_characteristic - this needs to be either enhanced or replaced/extended by a settable device_class

  • TBD a statistical characteristic of a source sensor with state_class == total is bound to change it's logical meaning, hence should loose it's device class. It can not be derived, but a user might want to set it explicitly

• Irrespective of improvement above, I believe unit_of_measurement, state_class and device_class should be optional configuration parameters of a statistics sensor.

@frenck this is comparable to the DSMR case linked, what do you think? #86690 (comment)

[bouwew]

@ThomDietrich I had a similar discussion with @frenck about a sensor with a m3/h unit_of_measurement in #87449. This one should have the state_class MEASUREMENT because it's a rate-measurement (rate of gasflow), was the conclusion in the end.

The same applies then to a sensor with a unit_of_measurement like L/h.

And, for these type of measurements there should not be a device_class. Instead there could be the possibility to add an icon.

[ThomDietrich]

All,
I've provided a bugfix in the PR linked above. Please review!

As mentioned above, I had to realize that the statistics component needs the optional configuration parameters unit_of_measurement, state_class and device_class to correctly define those statistics sensor. They are very similar to template sensors in that sense. I will propose that change in a different PR.

Edit: Fix will be in release 2023.2.5