BottlecapDave / HomeAssistant-OctopusEnergy

Unofficial Home Assistant integration for interacting with Octopus Energy
https://bottlecapdave.github.io/HomeAssistant-OctopusEnergy/
MIT License
532 stars 49 forks source link

target rate sensor schedule change error #867

Closed ragg987 closed 1 month ago

ragg987 commented 1 month ago

Describe the bug

When I edit an existing target rate sensor, it does not apply the new parameters consistently. The target hours parameter is not updating and retains the old value in the scheduling result.

Reproduction steps

Edit an existing target rate sensor. Change the number of hours and save. When you view the sensor in development tab it is still scheduling based on the old sensor.

Expected behaviour

Update the targer hours to the new vaue.

Tariff Code

agile

Integration Version

11.0

Home Assistant Version

2024.05

Fresh Install?

Not specified

Home Assistant Logs

Adding developer tools view. Previously had set 1hr and changed to 2.5hr.

icon: mdi:camera-timer friendly_name: Octopus Energy Target home_washer_nighttime name: home_washer_nighttime hours: 2.5 type: Continuous mpan: xxxx rolling_target: false last_rates: false target_invert_target_rates: false start_time: 22:00 end_time: 05:00 kind: target_rate account_id: A-xxxx is_target_export: false rates_incomplete: false target_times:

target_times_last_evaluated: 2024-05-12T16:16:31.900012+01:00 overall_average_cost: 0.09051 overall_min_cost: 0.090405 overall_max_cost: 0.090615 current_duration_in_hours: 0 next_time: 2024-05-13T02:00:00+01:00 next_duration_in_hours: 1 next_average_cost: 0.09051000000000001 next_min_cost: 0.090405 next_max_cost: 0.090615 last_evaluated: 2024-05-12T16:39:31.768367+01:00 weighting: 7,*

Confirmation

ragg987 commented 1 month ago

Update: a reload of the integration entry seems to fix the issue.

Edit: tried it again and the reload did not fix it. Something odd...

BottlecapDave commented 1 month ago

Hello and sorry you were experiencing an issue. I believe this is tied to HA's restoration of the sensors. When I get a chance I'll see if I can make this a bit more intelligent

ragg987 commented 1 month ago

Ok thanks. I notice the target rate sensor sorts itself out after some time. There must be some background processing.

Low priority issue for me on that basis.

ragg987 commented 1 month ago

Hi, an update. I notice this issue also arises if I change the target rate sensor by calling a service. I looked into the logs and notice this entry - looks like the weighting code has an unwanted regression impact. This sensor has weighting set to blank and the service only updated the target hours.

Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 258, in _handle_refresh_interval
    await self._async_refresh(log_failures=True, scheduled=True)
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 414, in _async_refresh
    self.async_update_listeners()
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 168, in async_update_listeners
    update_callback()
  File "/config/custom_components/octopus_energy/target_rates/target_rate.py", line 203, in _handle_coordinator_update
    self._target_rates = calculate_continuous_times(
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/octopus_energy/target_rates/__init__.py", line 118, in calculate_continuous_times
    continuous_rates_total = rate["value_inc_vat"] * (weighting[0] if weighting is not None else 1)
                                                      ~~~~~~~~~^^^
IndexError: list index out of range

and here is the sensor output from the development tab (sensitive data obfuscated)

name: dhw_yutaki_daytime
hours: 5
type: Continuous
mpan: 9999
rolling_target: false
last_rates: false
target_invert_target_rates: false
start_time: 08:00
end_time: 15:00
kind: target_rate
account_id: A-XXXX
offset: -00:01:00
is_target_export: false
icon: mdi:camera-timer
friendly_name: Octopus Energy Target dhw_yutaki_daytime
weighting: null
BottlecapDave commented 1 month ago

Thanks for raising this. I'll see if I can fix it soon.

BottlecapDave commented 1 month ago

@ragg987 I'm failing to recreate your second issue. The only thing I can see is that the target rate sensor was possibly set to zero target hours at some point to produce this result?

BottlecapDave commented 1 month ago

Your original issue along with some additional validation should now be fixed in v11.0.1. This should resolve your latter issue as well, although I'm unsure how it got into that state.

ragg987 commented 1 month ago

Hi, 11.0.1 seems to have fixed it, I'll continue to test - thanks. However new issue found. Creatin a separate incident.

BottlecapDave commented 1 month ago

Thanks for responding. I'll close this issue as complete.