Added state_class 'TOTAL' to todays cost sensors

[vladimir-babichev]

This PR addresses #35 by adding state_class SensorStateClass.TOTAL to Smart Meter Electricity: Cost (Today) and Smart Meter Gas: Cost (Today) sensors.

[megakid]

Thanks 🙏

[Excentyl]

Hi, I've had some issues with the total cost in the energy dashboard.

Unfortunately, I don't think the 'TOTAL' state class is the correct thing to use, unless a 'last_reset' attribute is added. Every day, the sensor resets to 0 (this is because the calculation uses the daily import) and so at the start of every day, the energy dashboard is taking away the cost from the previous day.

For example, if you use £10.00 on Monday and then £8.00 on Tuesday, the energy dashboard will show a cost of -£2.00 on Tuesday.

It looks to me that 'TOTAL_INCREASING' is correct state class to use, but I note that it was changed away from 'TOTAL_INCREASING' in version 1.6.1. Was something breaking when it was set to 'TOTAL_INCREASING'?

[sourbrambles]

Hi, I've had some issues with the total cost in the energy dashboard.

Unfortunately, I don't think the 'TOTAL' state class is the correct thing to use, unless a 'last_reset' attribute is added. Every day, the sensor resets to 0 (this is because the calculation uses the daily import) and so at the start of every day, the energy dashboard is taking away the cost from the previous day.

For example, if you use £10.00 on Monday and then £8.00 on Tuesday, the energy dashboard will show a cost of -£2.00 on Tuesday.

It looks to me that 'TOTAL_INCREASING' is correct state class to use, but I note that it was changed away from 'TOTAL_INCREASING' in version 1.6.1. Was something breaking when it was set to 'TOTAL_INCREASING'?

You might want to log this as an issue, I have the same problem with negative values. Happy to log it but your description covers it.

[vladimir-babichev]

Hi @Excentyl @sourbrambles

I recently started observing the same behaviour you described. I agree, the state class TOTAL_INCREASING should be used for the given sensors. However, when you set one, HA reports the following error:

Entity sensor.xxx (<class ‘homeassistant.components.template.sensor.SensorTemplate’>) is using state class ‘total_increasing’ which is impossible considering device class (‘monetary’) it is using; expected None or one of ‘total’

I believe last_reset can be used to workaround the issue.

[sourbrambles]

@vladimir-babichev I find the explanation on the Long-term Statistics confusing but I agree it looks like TOTAL_INCREASING would be the option. However from a quick parse of this home-assistant/core#88457 it sounds like the HA core developers would expect total & last_reset to be combined. It looks like the core development team don't see daily cost as the appropriate method for monetary calculations. There might be other info in that thread, I just had a quick skim

Edit: I'm not a developer so not sure if this is relevant but I remember having all sorts of problems getting last_reset working with my manually created mqtt sensors during the introduction of long term statistics and prior to "total_increasing". looking at old configs I ended up using customize.yaml to add in last_rest but I think it really needed an last_reset_topic but this is going back a few years so lots has changed.

[megakid]

Happy to accept a working PR here but since these values are not accurate for me (I have a dual tariff and my IHD reports the wrong cost).

As mentioned above, I removed the previous state_class because of the warning logs but would reinstate them if we can avoid them with another setting.

[cmatte]

I wanted to also flag this does calculate costs wrong for dynamic rates tariffs like Agile Octopus, where rates change every half an hour - is there a working or workaround solution for those?