Giters

BottlecapDave / HomeAssistant-OctopusEnergy

Unofficial Home Assistant integration for interacting with Octopus Energy

Home Page:https://bottlecapdave.github.io/HomeAssistant-OctopusEnergy/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

target rate sensor not accepting target hours = zero since 11.0.1

ragg987 opened this issue · comments

commented

Describe the bug

Hi, I had set up some target rate sensors with 0 hours. This had worked fine but the 11.0.1 release is forcing me to have a none-zero value. In addition, when I call the service to update it gives an error if the service tries to set target hours = 0

Reproduction steps

Create or amend target sensor with target hours = 0 and try to save. Error message received.
Call service with target hours = 0 error in logs and sensor remains unchanged.

Expected behaviour

0 to be a valid value in both scenarios

Tariff Code

agile

Integration Version

11.0.1

Home Assistant Version

12.5.4

Fresh Install?

After upgrading

Home Assistant Logs

Logger: homeassistant.components.automation.myclimate_set_octopus_target
Source: components/automation/init.py:744
integration: Automation (documentation, issues)
First occurred: 09:25:09 (2 occurrences)
Last logged: 09:41:33

Error while executing automation automation.myclimate_set_octopus_target: Target hours must be in half hour increments (e.g. 0.5 = 30 minutes; 1 = 60 minutes) and a minimum of 0.5.

Confirmation

  • I confirm that I cannot find my solution within the documentation
  • I confirm that I cannot find my solution within the FAQ
commented

Re-reading the error message it looks like a 0.5hr minimum has been a deliberate choice in th design / code. I had been using a value of 0 as an output from my automations to say "do not run it" - e.g. because the weather forecast is warm and I don't want to call for heating in the house, or because solar next day is high so defer the night run. If this is a deliberate choice please reconsider.

commented

Hello. The 0.5 minimum was put in place to solve the scenario where at least one calculated weighting was assumed (whether explicit or implicit) and felt like a user error to allow zero hours. In your scenario i'd have probably had an additional input boolean or similar as an additional condition. However as you (and potentially others) are using this workaround, I've reverted the fix which is available in v11.0.2.

commented

Really appreciate the quick response and fix. So far so good.