Incorrect warning that measurement state class is incompatible with device class monetary
mmillmor opened this issue · 5 comments
The problem
I am getting a warning;
Entity sensor.gas_standing_charge (<class 'custom_components.geo_home.sensor.GeoHomeGasStandingChargeSensor'>) is using state class 'measurement' which is impossible considering device class ('monetary') it is using; Please update your configuration if your entity is manually configured, otherwise report it to the custom integration author.
I am assuming someone thought that a monetary measurement must be something that increases, but in this case the monetary measurement represents a spot price that can go up and down, but which is not cumulative. The current absolute value is all that is of interest. As the documentation on state class total says;
"This state class should not be used for sensors where the absolute value is interesting instead of the accumulated growth or decline"
and for total_increasing, it really makes no sense - this is not something that resets every time the value goes down. Think of it more like tracking a stock price.
This warning is therefore incorrect - measurement is the correct state class here
What version of Home Assistant Core has the issue?
2023.2.1
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant Core
Integration causing the issue
GeoHome
Link to integration documentation on our website
https://developers.home-assistant.io/docs/core/entity/sensor/
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response
So what would be the unit of this sensor?
The unit would be a currency. Here's an example;
state_class: measurement
unit_of_measurement: GBP
device_class: monetary
icon: mdi:currency-gbp
friendly_name: Electricity Standing Charge per Day
Are you thinking the unit should be GBP/day in this example? I could certainly see that as valid.
I don't think it changes the fundamentals of the bug though - there are things that have a spot price, e.g. I could be tracking the cost of a share and change the colour of my lights when it goes below a certain price. Or tracking my bank balance and sending a notification when it gets too low
Right, that is what I expected :)
The problem is in the sensor configuration, it uses a monetary device class for a rate (and not really providing a correct unit either, but that is not really in scope). Which is not accumulative, hence the state class will not match either.
In conclusion, the state class is correct (in this case), but the device class (and arguably the unit) are not. Removing the device class, resolves the warning message.
The currently provided bug report is not a bug, the warning is actually correct in this case. Incorrect and incompatible values are assigned to this sensor.
As this is a custom integration, please report the issue with the project/repository tracker providing this integration.
../Frenck
I don't think that that is the right solution. If I remove the state class, I start to get errors about the statistics;
The state class of this entity, is not supported.
Statistics can not be generated until this entity has a supported state class.If this state class was provided by an integration, this is a bug. Please report an issue.
If you have set this state class yourself, please correct it. The different state classes and when to use which can be found in the developer documentation. If the state class has permanently changed, you may want to remove the long term statistics of it from your database.
Do you want to permanently remove the long term statistics of sensor.electricity_standing_charge from your database?
Having access to the statistics is important for some of these measurements (e.g. looking at electricity price trends), and we can only get the statistics if the state class is measurement.
Measuring the price of something is no less valid than measuring other attributes of something, and seeing the statistics of that is a useful feature. This warning that measurements can't be of monetary things is a clear regression, and should be reverted