core: upgrade causes energy sensor total to be read as day's production

The problem

Each time I do a Supervisor update (and there’ve been a few on 2021.9 already), the value of the ‘Total’ sensor is added as that day’s energy consumption.

I have a sensor recording the total energy production of my solar inverter. Prior to 2021.9 I set this up as state_class: measurement with a fake last_reset timestamp set to Unix epoch. After the launch of 2021.9, which introduced the new state_class, I dropped the last_reset and changed the sensor to use state_class: total_increasing. The first day I did this, the Energy Dashboard used the value of the sensor as that day’s production. The day after the sensor worked as expected. However, each time I do a Supervisor upgrade, the issue reoccurs.

What is version of Home Assistant Core has the issue?

core-2021.9.4

What was the last working version of Home Assistant Core?

core-2021.8.8

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Energy

Link to integration documentation on our website

https://www.home-assistant.io/docs/energy/

Example YAML snippet

---
# Solis inverter data
#
# https://sequr.be/blog/2021/08/reading-ginlong-solis-inverter-over-serial-and-importing-in-home-assistant-over-mqtt/
#
# [... cut for brevity ...]
- platform: mqtt
  name: "Solis meter - Generated (All time)"
  qos: 1
  unique_id: "solis_com_gat"
  state_topic: "meters/solis_com/gat"
  device_class: energy
  unit_of_measurement: kWh
  state_class: total_increasing
  # 
  # Old config (2021.8.x)
  # state_class: measurement
  # last_reset_topic: 'meters/solis_com/gat'
  # last_reset_value_template: '1970-01-01T00:00:00+00:00'

Anything in the logs that might be useful for us?

No response

Additional information

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 32 (13 by maintainers)

Most upvoted comments

I think the easiest way is simply to do: mosquitto_sub -v -h <host> -t <topic>

Running mosquito_sub -h <host> -t meters/solis_com/gat -v | while read line; do echo "$(date) - $line; done | tee config/solis_mqtt_gat.log, which gives me outputs like Fri Sep 10 14:15:10 CEST 2021 - meters/solis_com/gat 7139. Will keep it running for 24h or so and see if it reports any non-integer values.

TheGroundZero on Sep 10, 2021

Thanks @dgomes! I wonder if we should fail on casting random strings to float/int instead of returning 0?

emontnemery on Sep 10, 2021

@Alex-joomla in your template check availability besides defining state.

Casting an UNAVAILABLE state to int/float leads to 0 (this is a very common reported issue)

dgomes on Sep 10, 2021

The analysis from @edelans is 100% correct.

Integrations should never set a sensor’s value to 0 when the state is unknown, for example in the constructor. It should instead set the state to None.

@TheGroundZero in your case you get data from MQTT topic meters/solis_com/gat, can you check if you sometimes receive 0 on that topic? @mc74909 Is your sensor also an MQTT sensor or something else? @Alex-joomla For the template and utility_meter sensor, can you share states from the states table which shows the state of the template and utility_meter + the sensors they depend on when the resets happen?

In Home Assistant 2021.10, state_class total is (re)introduced. This is similar to total_increasing but:

billing cycles are supported, but managed through the last_reset property
setting last_reset is optional, if it’s not set, the meter will never reset

emontnemery on Sep 10, 2021