HomeAssistant-OctopusEnergy
HomeAssistant-OctopusEnergy copied to clipboard
BottlecapDave
Odd Target Rates behaviour
I'm now on v4.5.0. I've set up two intermittent Target Rates, one for three hours and the other for six hours. No offset and a 00:00 - 23:59 min/max. Here are the results:
Couple of things seem odd:
- The three hours are not a sub-set of the six hours, e.g. the three hour sensor came on at 4pm for 90 mins (during a period that definitely wasn't in the top 3 cheapest hours of the day!).
- There is much more than 3/6 hours where each sensor is activated in a 24hr period.
Today's pricing is as follows (incl. a nice plunge in the early morning!):
00:00 - 00:30 | 22.36
00:30 - 01:00 | 6.05
01:00 - 01:30 | 1.05
01:30 - 02:00 | -0.27
02:00 - 02:30 | 0.00
02:30 - 03:00 | -1.64
03:00 - 03:30 | -3.19
03:30 - 04:00 | -8.40
04:00 - 04:30 | -4.20
04:30 - 05:00 | -8.40
05:00 - 05:30 | -7.14
05:30 - 06:00 | 2.10
06:00 - 06:30 | 6.51
06:30 - 07:00 | 23.73
07:00 - 07:30 | 18.06
07:30 - 08:00 | 31.50
08:00 - 08:30 | 35.80
08:30 - 09:00 | 35.80
09:00 - 09:30 | 33.10
09:30 - 10:00 | 30.74
10:00 - 10:30 | 27.89
10:30 - 11:00 | 23.10
11:00 - 11:30 | 20.50
11:30 - 12:00 | 17.26
12:00 - 12:30 | 17.43
12:30 - 13:00 | 14.49
13:00 - 13:30 | 15.58
13:30 - 14:00 | 6.89
14:00 - 14:30 | 13.44
14:30 - 15:00 | 12.01
15:00 - 15:30 | 12.10
15:30 - 16:00 | 16.80
16:00 - 16:30 | 29.40
16:30 - 17:00 | 35.80
17:00 - 17:30 | 35.80
17:30 - 18:00 | 36.75
18:00 - 18:30 | 35.80
18:30 - 19:00 | 38.79
19:00 - 19:30 | 35.80
19:30 - 20:00 | 35.80
20:00 - 20:30 | 35.80
20:30 - 21:00 | 30.60
21:00 - 21:30 | 35.80
21:30 - 22:00 | 29.82
22:00 - 22:30 | 35.80
22:30 - 23:00 | 25.62
23:00 - 23:30 | 35.80
23:30 - 00:00 | 31.08
Finally, I'm still getting the following error when I try to create a new Target Rates sensor without entering min/max times (may also be caused by blank offset?):
Logger: aiohttp.server
Source: custom_components/octopus_energy/config_flow.py:215
Integration: Octopus Energy ([documentation](https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy/), [issues](https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy/issues))
First occurred: 18:12:16 (3 occurrences)
Last logged: 18:12:54
Error handling request
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/aiohttp/web_protocol.py", line 435, in _handle_request
resp = await request_handler(request)
File "/usr/local/lib/python3.10/site-packages/aiohttp/web_app.py", line 504, in _handle
resp = await handler(request)
File "/usr/local/lib/python3.10/site-packages/aiohttp/web_middlewares.py", line 117, in impl
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 60, in security_filter_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 222, in forwarded_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 28, in request_context_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 82, in ban_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 236, in auth_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 136, in handle
result = await result
File "/usr/src/homeassistant/homeassistant/components/config/config_entries.py", line 216, in post
return await super().post(request)
File "/usr/src/homeassistant/homeassistant/components/http/data_validator.py", line 73, in wrapper
result = await method(view, request, data, *args, **kwargs)
File "/usr/src/homeassistant/homeassistant/helpers/data_entry_flow.py", line 71, in post
result = await self._flow_mgr.async_init(
File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 225, in async_init
flow, result = await task
File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 252, in _async_init
result = await self._async_handle_step(flow, flow.init_step, data, init_done)
File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 367, in _async_handle_step
result: FlowResult = await getattr(flow, method)(user_input)
File "/config/custom_components/octopus_energy/config_flow.py", line 246, in async_step_init
return await self.__async_setup_target_rate_schema(config, {})
File "/config/custom_components/octopus_energy/config_flow.py", line 215, in __async_setup_target_rate_schema
vol.Optional(CONFIG_TARGET_START_TIME, default=config[CONFIG_TARGET_START_TIME]): str,
KeyError: 'Start time'
Appreciate any pointers!
Hi @no1knows.
This seemed to be an issue with the labels, where the logic was the wrong way around. If you update to the latest version (v4.5.1) and re-configure your sensor you should get the desired behaviour. I also believe I've fixed the error you specified.
Thank you! The error is gone and I've re-added the sensors. Will report back if I see any more unexpected behaviour.
I'm on Octopus Go, so a simple situation where I already know that 00:30 to 04:30 is 7.5p/kWh and the rest of the time, it's 42.3p/kWh.
I've set up a target rate for a continuous 4 hours. The sensor finds 00:30 to 04:30, but also finds multiple other 4 hour slots during the day.
Is this due to a rounding error, or something along those lines?
Sorry for the late response - @FalconUK Do you still see this behaviour with the latest version of the integration? If so, have you reconfigured your target rate sensor as per the instructions
Hi Dave, no worries. Yes, for example, the sensor was on for 0030 - 0430 as expected, but also 0500 - 0900, and then came on again at 0930.
I currently have "Re-evaluate multiple times a day" set to true. Is this the issue? Even so, evaluation shouldn't turn the sensor on, as there's no cheap rate during the day.
I believe the "Re-evaluate multiple times a day" setting is probably the issue. With that set to true, it's basically a moving target for the current day (and specified period).
This setting turned on is best for people on variable rates (something that most people aren't probably on atm) or where the sensor is powering an automation that can't be missed but is only a part of the reason why the automation might run. For example in my house, I have the ability to set my washing machine to remote start. I want the sensor to find the best time for the day from the moment I turn on remote start. If I didn't have this setting then the washing machine might not turn on until the next day because the best time was in the past.
It was a bug in the previous release where "Re-evaluate multiple times a day" was the default setting, which has since been fixed.
Please do let me know if unsetting this doesn't fix your issue though.
Hi Dave, I'll try it without, but something is a little off. With my flat rate during the day, there's no 'best' four hour period, but the sensor is on and off regularly throughout the day.
Because you're on a flat rate, you probably don't want "Re-evaluate multiple times a day" switched on. As previously mentioned, it's a setting that is best for rates where they fluctuate during the day (e.g. Octopus Agile) or the sensor is being used in conjunction with something else that powers something that "must" not be missed (e.g. my washing machine automation has an additional flag I check to know if the washing machine should be turned on). I'll try to update the readme with more examples.
With "Re-evaluate multiple times a day" turned off, the behaviour of the sensor is more stable, but it's true from 0030 to 0500 every morning. Octopus Go cheap rate is from 0030 to 0430.
@FalconUK Very odd that you're seeing this behaviour as in my testing I'm not seeing this behaviour. Are you receiving any errors in your Home Assistant logs relating to this integration? In addition, could you post the attributes associated with your target rate sensor to see if it holds any clues?
@BottlecapDave, I've just enabled debug-level logging and will keep an eye on the logs.
Target rate sensor is configured as follows:
Today:
Attributes attached. interestingly, this show the low rate starting from 00:00, and the high rate starting from 03:30, so I guess they're in GMT/UTC and 23:30-00:00 belongs to yesterday? - but the attribute data for the low rate ending at 03:30 would be correct, even though the switch changed state incorrectly at 05:00.
@BottlecapDave I've enabled debug-level logging. Is there any useful info you'd like?
Sorry, I've released a new version (v4.6.0) which will hopefully fix your issue. Do you mind giving it a try?
@BottlecapDave I'm running v4.6.0 and still seeing the sensor switch on at 00:30 and off at 05:00, not 04:30. The attribute data confirms that the lower tariff finishes at 03:30 UTC.
I might have found the issue. Just testing now. However, I don't think it will be an issue by next week when the clocks go back :(
Ahhh, the joys of BST.
If you're able to release an updated version, I'm happy to test before and after the clocks go back.
🤞 that https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy/releases/tag/v4.6.1 will fix your issue before the clocks go back
@BottlecapDave, have installed v4.6.1 and will let you know how it goes over the next week.
@BottlecapDave, looking good this morning. I'll keep and eye on it and update after the clocks go back.
