Why do I get error setting state_class 'measurement' and device_class 'volume'

I have a water sensor with MQTT that periodically sends the (incremental) volume consumed
I want to record the device_class as ‘volume’ (or ‘water’) and the state_class as ‘measurement’ (since it’s not ‘total’ or ‘total_increasing’) and the unit_of_measurement as ‘gal’

However, I get the following error in my logs:
Entity sensor.waterplug_water (<class 'homeassistant.components.mqtt.sensor.MqttSensor'>) is using state class 'measurement' which is impossible considering device class ('volume') it is using; expected None or one of 'total', 'total_increasing'

  • Should I be setting state_class to `None’?
  • Should I be using a different device_class?
  • Is this a bug?

Note it’s not really a flow rate since the consumption amounts may arrive at random times and just represent the incremental recorded since the last time.
The sums may not even be fully cumulative since the sensor is not always connected to the water supply.

But when it is connected, I want it to record the amount that is published as consumed.
Then on the statistics, I want to show the ‘total’ reported in each 1 hour and 5 min period -for statistics and statistics_short_term tables respectively.

Also how do I configure history so that it shows the number of units (i.e. gallons) consumer per period which should be a bar rather than line chart – similar to how the energy dashboard displays

Remove the state class, leave the device class as volume.

If you then send your sensor to a utility meter helper (any cycle you want, daily, hourly, etc… or even none if you want it to count up forever) with the delta_values option set to true the utility meter will keep a track of the total for you.

Hopefully this will then pick up the correct state class for you as well. If not, this can be set to total_increasing using manual customization.

Thanks very helpful.
I removed the state_class

Wondering though whether this is a bug or a feature?
In other words, shouldn’t there be a measurement class associated with volume where you are looking to just input absolute amounts.

A simple example would be fuel for your car. Where you input the number of gallons of gasoline every time you fill up…

The device class make sense as “volume” and there should presumably be a “state class” associated with it, right?

Or am I misunderstanding what state_classes do…

I now get an error when I try to look at the statistics.
It says:

Statistics cannot be generated until this entity has a supported state class.

It seems to me like there should be a state class called something like “quantity” which could potentially have positive or negative values depending on whether the associated quantity is added or subtracted for each entry in the state table – for example whether boxes are added or removed from a warehouse.

The statistic would then sum all the values of the quantity for the given period so that in the statistics table it would include the total quantity added or subtracted during each 1 hour interval.

Similarly in the statistics_short_term table it would include the total quantity added or subtracted in each 5 minute interval.

This seems like such an obvious use case that I am surprised that the concept of quantity (as opposed to total) doesn’t seem to exist yet.

Of course, I could use a template sensor to convert my quantity sensor into a new cumulative total sensor, but that seems kludgey and unnecessary.

Am I missing something here?

Delta measurements do not fit the available state classes for the volume device class. Volume is a total. But by converting your delta measurements to a running total with the utility meter it will.

Please see my edited previous message.
My question is why isn’t there a concept of “delta measurements” for volume.
It seems very natural for some problems.

Suppose I fill up my oil tank every week or two with a certain number of gallons of fuel. I could of course compute and enter the running total, but it would seem more natural to enter the amount delivered by the fuel company for each delivery.

Is this a feature that makes sense to add if the concept doesn’t exist yet?

I did and it does not change my answer.

You don’t have to compute anything. The utility meter will do that for you when you enter the amount delivered. That is what the delta_values: true option does.

It seems to me that utility_meter is really just a fancy way of creating another set of entities that keep the running totals for different time periods.

But why do I need another integration (i.e Utility meter) to do this? which effectively keep the running totals per period).
It would seem this should be a native state_class with or without adding the utility meter integration…

Feel free to create a feature request for a new device class and hope that a developer agrees enough to implement it some time in the next 6 months.

Or fix it now with the Utility Meter, up to you.

Regardless, thank for clarifying and helping here!