Energy consumption value reduces during restart causing negative power

[jezzaaa]

I use VT with two electric heaters powered by smart plugs. When Home Assistant is restarted, the "Energy" sensor sometimes goes back to a previous value, causing the Energy dashboard to show negative consumption.

Version of the custom_component

6.2.9 -->

Configuration

My VTherm attributes are the following:

hvac_modes:
  - heat
  - "off"
min_temp: 7
max_temp: 30
target_temp_step: 0.5
preset_modes:
  - none
  - frost
  - eco
  - comfort
  - boost
current_temperature: 18.2
temperature: 18
hvac_action: idle
preset_mode: none
is_on: true
hvac_mode: heat
type: null
is_controlled_by_central_mode: true
last_central_mode: Auto
frost_temp: 16
eco_temp: 19
boost_temp: 23
comfort_temp: 21
frost_away_temp: 0
eco_away_temp: 0
boost_away_temp: 0
comfort_away_temp: 0
power_temp: null
target_temperature_step: 0.5
ext_current_temperature: 13.7
ac_mode: false
current_power: null
current_power_max: null
saved_preset_mode: none
saved_target_temp: 19
saved_hvac_mode: null
motion_sensor_entity_id: null
motion_state: null
power_sensor_entity_id: null
max_power_sensor_entity_id: null
overpowering_state: null
presence_sensor_entity_id: null
presence_state: null
window_state: "off"
window_auto_state: "off"
window_bypass_state: false
window_sensor_entity_id: null
window_delay_sec: null
window_auto_enabled: false
window_auto_open_threshold: null
window_auto_close_threshold: null
window_auto_max_duration: null
window_action: window_turn_off
security_delay_min: 60
security_min_on_percent: 0.5
security_default_on_percent: 0.1
last_temperature_datetime: "2024-07-16T12:52:24.438594+10:00"
last_ext_temperature_datetime: "2024-07-16T13:06:09.209624+10:00"
security_state: false
minimal_activation_delay_sec: 10
device_power: 2
mean_cycle_power: 0.62
total_energy: 318.63
last_update_datetime: "2024-07-16T13:06:09.346734+10:00"
timezone: Australia/Sydney
temperature_unit: °C
is_device_active: false
ema_temp: 18.08
is_used_by_central_boiler: false
is_over_switch: true
is_inversed: false
keep_alive_sec: 0
underlying_switch_0: switch.jeremy_s_heater_switch
underlying_switch_1: null
underlying_switch_2: null
underlying_switch_3: null
on_percent: 0.31
power_percent: 31
on_time_sec: 93
off_time_sec: 206
cycle_min: 5
function: tpi
tpi_coef_int: 0.6
tpi_coef_ext: 0.1
friendly_name: Jeremy's Thermostat
supported_features: 401

If it is releveant to regulation performance or optimisation some curves are needed

Describe the bug

I have two virtual thermostats setup using VT. Both are using a smart plug to switch off/on electric heaters via ZigBee temperature sensors. The VT energy sensors are used in the Energy dashboard to show consumption over time. The Energy dashboard sometimes shows negative usage.

Energy sensors are supposed to be be ever-increasing, or reset to zero in some situations. However I have found that the energy sensors sometimes revert to a previous value around the time of restarting Home Assistant.

I'm trying to: have accurate graphs in the Energy dashboard, that show only non-negative power consumption.

And I expect: the energy accumulators provided by VT to always increase, or reset to zero when required, but to not go "back in time" to a previous non-zero value.

But I observe this .... the energy accumulators sometimes reduce to a positive value, when Home Assistant is restarted.

I read the documentation on the README.md file and I don't find any relevant information about this issue.

Debug log

I no longer have the logs from the last time this happened. If it would be helpful, I can try to reproduce the behaviour by restarting Home Assistant (or VT) while the heaters are consuming energy.

[jmcollin78]

Hello,

Energy sensor is persistant and is restored at restart. I can't do more than this on my own. Did you stop and restart HA properly ? I guess on a hard restart, the db have not the time to be updated and you may have some delta is not persisted correctly.

The other point you could check, the persistance delay, named commit_interval. This is in the recorder.yaml file.

The value in my env:

That mean I can loose up to 10 sec of data in case of haard stop.

[jezzaaa]

I can't find a file called recorder.yaml, sorry. Is it part of VT or HA? Reducing commit_interval would probably reduce the chances of negative consumption but not eliminate it - this seems to be more of a work-around than a solution.

I'm fairly sure my HA restarts were graceful (via the GUI), as part of HA or integration upgrades.

I'm wondering if a better solution might be to reset the energy accumulator to zero every time VT starts up. I believe this is what happens with smart plugs providing their own energy counters, when they are power cycled, and Home Assistant seems to recognise this special case and handle it correctly - that is, power usage doesn't suddenly go negative when a smart plug is disconnected and re-connected.

[jmcollin78]

In my configuration.yaml, I have this:

# Recorder and purge config
recorder: !include recorder.yaml

may be the recorder specification is directly in your configuration.yaml and not in the recorder.yaml which is included in the configuration.yaml

[jezzaaa]

I have no recorder specification in configuration.yaml.

Perhaps I need to create it in configuration.yaml (or add "recorder: !include recorder.yaml" and create recorder.yaml). I'll give that a try.

[jezzaaa]

Reading the documentation, the commit_interval default is 5 seconds. As I don't have any "recorder:" settings in my configuration.yaml or included files, my commit interval must be 5. Increasing to 10 (as you have it) would increase the likelihood of lost data samples during a reboot, so I don't think that is advisable.

If a commit_interval delay were causing this issue, then I would expect to see a negative energy consumption value that is around 5 seconds of consumption. Instead, I see several hours of samples before the value reverts. It's as if the total consumed energy goes back 8 or more hours in time. Certainly not 5 or 10 seconds.

So I believe that the commit_interval value is unrelated to the problem, and changing its value is not going to make things better or worse by the quantity of error that I'm seeing.