jmcollin78 / versatile_thermostat

A full featured Thermostat for Home Assistant: presets, window, motion, presence and overpowering management
MIT License
327 stars 34 forks source link

Energy consumption value reduces during restart causing negative power #485

Closed jezzaaa closed 1 month ago

jezzaaa commented 4 months ago

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

image

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.

image

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 commented 4 months ago

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: Capture d’écran 2024-07-16 à 14 10 43

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

jezzaaa commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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.

jmcollin78 commented 1 month ago

Hello @jezzaaa

It seems the problem was not a restoration problem but more than the energy was not saved every time it should.

I try this fix with beta release https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.3.4.beta3

If you can give it a try because I'm not able to reproduce the case at home. I will publish a release tomorrow if you can give it a try

jezzaaa commented 1 month ago

It seems the problem was not a restoration problem but more than the energy was not saved every time it should.

Great news.

I try this fix with beta release https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.3.4.beta3

I don't know how to run a beta version. I believe HACS used to allow enabling beta versions, but since HACS 2.0, that option is not present.

If you can give it a try because I'm not able to reproduce the case at home. I will publish a release tomorrow if you can give it a try

I would give it a try if I could install it. But a day isn't long enough to test. It would sometimes take 2 or more weeks for the problem to show up. So with a day's testing, I wouldn't be able to say with confidence that the problem had been fixed.

jmcollin78 commented 1 month ago

You should click on the three dot and select "retélécharger" (in French) Capture d’écran 2024-10-13 à 11 27 59

Then you can choose the release you want.

jmcollin78 commented 1 month ago

https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.3.4

jezzaaa commented 2 weeks ago

I installed 6.3.4 when it came out. It's been a few weeks, and I haven't seen any problems with the integration, so I believe the problem is fixed. Thankyou!