You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: Added support for multiple EVs (6 hours 5 minutes dev time)
BREAKING CHANGE: Intelligent device related entity ids have been changed from including the account id to including the device id. This is to support multiple EVs as well as other future intelligent devices OE might want to add in the future (e.g. Snug)
is_dispatching entity will now only show when the car is within a scheduled dispatching period. It will no longer turn on when within the standard off peak period. This is because the naming and behaviour was confusing with the name (on when it's not dispatching) and behavior in conjunction with the off peak sensor (off peak not turning on when in an ad-hoc off peak period). See https://bottlecapdave.github.io/HomeAssistant-OctopusEnergy/architecture_decision_records/0002_intelligent_is_dispatching_behaviour_changes for full details.
# 0001 - Deprecation and removal of Target Rate Sensors in Octopus Energy Integration
2
+
3
+
## Status
4
+
Accepted
5
+
6
+
## Context
7
+
Target rate sensors are currently a core feature of the Octopus Energy integration. A variation of this feature was also introduced into the [Carbon Intensity integration](https://github.com/BottlecapDave/HomeAssistant-CarbonIntensity), where carbon emissions were used instead of price.
8
+
9
+
Maintaining this feature across multiple integrations has become problematic, as it requires ongoing effort to ensure feature parity. Meanwhile, more energy providers are emerging with dynamic pricing models similar to Octopus Energy that cannot benefit from the existing implementation.
10
+
11
+
In addition, there are broader automation opportunities beyond energy pricing, such as identifying optimal times for solar generation, that could leverage this functionality.
12
+
13
+
To address these issues, a new integration, [Target Timeframes](https://bottlecapdave.github.io/HomeAssistant-TargetTimeframes/), has been developed. It abstracts the concept of selecting optimal timeframes from the data source, allowing it to work with any metric (price, carbon intensity, generation, etc.). This ensures long-term viability and avoids duplication of effort across multiple integrations.
14
+
15
+
## Decision
16
+
Deprecate and remove target rate sensors from the Octopus Energy integration in favor of the Target Timeframes integration.
17
+
18
+
- A migration guide has been provided: [Target Timeframes Migration Guide](https://bottlecapdave.github.io/HomeAssistant-OctopusEnergy/migrations/target_timeframes/).
19
+
- A set of [blueprints](https://bottlecapdave.github.io/HomeAssistant-TargetTimeframes/blueprints/#octopus-energy) for using Octopus Energy data with Target Timeframes is already available.
20
+
- A repair notice has been introduced to inform users of the upcoming removal.
21
+
- The target rate sensors feature will be removed six months from the notice, around the end of **November 2025**.
22
+
23
+
The Carbon Intensity integration has already removed its variation due to a smaller user base. Given the higher user count of Octopus Energy, this proposal is being [made openly](https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy/discussions/1305) before proceeding.
24
+
25
+
## Consequences
26
+
27
+
### Positive
28
+
- Centralizes the feature into a single integration, reducing maintenance overhead.
29
+
- Ensures consistent functionality and feature parity across different use cases.
30
+
- Provides flexibility for multiple data sources beyond Octopus Energy (dynamic pricing, carbon intensity, solar generation, etc.).
31
+
- Protects users from losing the feature if they move away from Octopus Energy.
32
+
33
+
### Negative
34
+
- Users will need to migrate their automations to the Target Timeframes integration.
35
+
- Some short-term disruption may occur as users adapt to the new integration.
36
+
- Potential gaps in the new integration’s functionality may need to be identified and addressed through community feedback.
# 0002 - Intelligent Is Dispatching behavior changes
2
+
3
+
## Status
4
+
Accepted
5
+
6
+
## Context
7
+
8
+
The Octopus Intelligent feature was heavily based on an [existing integration](https://github.com/megakid/ha_octopus_intelligent), with [an original proposal from author](https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy/issues/114). This resulted in the intelligent based entity behavior being identical to the existing integration.
9
+
10
+
Since inception, this integration has evolved and resulted in other sensors (i.e. [off peak](../entities/electricity.md#off-peak)) which have brought some inconsistencies in naming compared to behaviour (e.g. not turning on for **all** off peak times). Some of the intelligent sensors have also had inconsistencies in naming compared to behaviour (e.g. dispatching sensor turning on during standard off peak when the device isn't scheduled to be charged).
11
+
12
+
## Decision
13
+
14
+
The [Is Dispatching entity](../entities/intelligent.md#is-dispatching) will have its behaviour updated to only turn on when during a planned/scheduled dispatch period and the state of the intelligent device is in a "scheduled" mode.
15
+
16
+
The [Off peak entity](../entities/electricity.md#off-peak) will have its behaviour updated to turn on whenever an off peak rate is active. In the case of intelligent tariffs this will be during the standard off peak times (23:30-05:30 at time of writing) or when a planned/scheduled dispatch is active and the state of the intelligent device is in a "scheduled" mode.
17
+
18
+
## Consequences
19
+
20
+
### Positive
21
+
- Expected behavior based on entity names, which will be easier for new users to understand
22
+
23
+
### Negative
24
+
- Downstream integrations that rely on existing behavior will need to change
25
+
- Users using effected entities will need to update all references
26
+
- Some short-term disruption may occur as users adapt to the new entity behaviour.
This sensor is used to determine if you're currently in a planned dispatch period (i.e. "smart-charge" determined by Octopus Energy) or are within the standard off peak period. This sensor **will not** come on during a bump charge.
13
+
This sensor is used to determine if you're within a dispatching period (i.e. "smart-charge" determined by Octopus Energy) for a **single** intelligent device. This sensor **will not** come on during a bump charge.
14
+
15
+
Depending on your [account configuration](../setup/account.md#intelligent-rates-mode), what is determined as an active dispatching period will change. If you have configured to accept [planned or started dispatches](../setup/account.md#planned-and-started-dispatches-will-turn-into-off-peak-rates), then the sensor will turn on when you're are within an active planned or started dispatch period. If you have configured to accept [only started dispatches](../setup/account.md#only-started-dispatches-will-turn-into-off-peak-rates), then the sensor will turn on when you're are within an active started dispatch period, but not planned dispatch.
16
+
17
+
!!! info
18
+
19
+
This sensor will only turn on during dispatches for a single intelligent device. If you're after a sensor that turns on during the standard off peak rates as well or cover multiple intelligent devices then you're best to use the [off peak sensor](./electricity.md#off-peak).
14
20
15
21
!!! warning
16
22
17
23
If you are using this to drive other automations for cheap rates (e.g. to fill batteries), you should perform additional checks to make sure your vehicle is actually charging. If it isn't, this sensor could be incorrectly on if during a dispatch outside of the standard off peak period and you will therefore not receive the off peak rate.
18
24
19
25
If you are wanting to know when you are within a guaranteed off peak period, you should use the [off peak](./electricity.md#off-peak) sensor.
20
26
21
-
!!! info
27
+
!!! warning
22
28
23
29
This sensor is only partially supported for the following intelligent providers
24
30
25
31
* OHME
26
32
27
-
If you are supplied by one of the above providers, `planned_dispatches` will always return an empty collection and this entity will only turn on when within the standard off peak period.
33
+
If you are supplied by one of the above providers, this sensor will never turn on.
28
34
29
35
| Attribute | Type | Description |
30
36
|-----------|------|-------------|
31
37
|`planned_dispatches`|`array`| An array of the dispatches that are currently planned by Octopus Energy. |
32
38
|`completed_dispatches`|`array`| An array of the dispatches that have been completed by Octopus Energy. This will only store up to the last 3 days worth of completed dispatches. This includes dispatches that were scheduled by OE and boost dispatches issued by the user. OE do not provide details on what triggered the completed dispatches. |
33
-
|`started_dispatches`|`array`| An array of the dispatches that have been planned by Octopus Energy and upon API refresh are still planned when the current 30 minute period has started, is not in a boosting state and the data has been refreshed within the last 3 minutes. A planned dispatch will be added one 30 minute period at a time. This will only store up to the last 3 days worth of started dispatches. This is used to determine current and historic off peak rates. For example if you have a planned dispatch of `2025-04-01T10:00:00`-`2025-04-01T11:00:00`, at `2025-04-01T10:01:00` if the planned dispatch is still available the period of `2025-04-01T10:00:00`-`2025-04-01T10:30:00` will be added. |
39
+
|`started_dispatches`|`array`| An array of the dispatches that have been planned by Octopus Energy and started. See the [FAQ](../faq.md#what-are-started-dispatches-and-how-are-they-calculated) for how this is calculated and why it exists. |
34
40
|`provider`|`string`| The provider of the intelligent features |
35
41
|`vehicle_battery_size_in_kwh`|`float`| The size of the target vehicle battery in kWh. |
36
42
|`charge_point_power_in_kw`|`float`| The power of the charge point battery in kW. |
@@ -70,9 +76,9 @@ Each item in `started_dispatch` have the following attributes
This sensor displays the current state of your intelligent provider as told by the OE API. The value of this sensor can be one of the following
81
+
This sensor displays the current state of your intelligent provider as told by the OE API for a **single** intelligent device. The value of this sensor can be one of the following
76
82
77
83
*`AUTHENTICATION_PENDING` - ready to start authentication and authorization, or auth is in progress.
78
84
*`AUTHENTICATION_FAILED` - failed to connect and ready to restart authentication and authorization.
@@ -91,9 +97,9 @@ This sensor displays the current state of your intelligent provider as told by t
This sensor is used to see and set the target time for your future intelligent charges. This is limited to 30 minute increments between 4 and 11 to match the Octopus Energy app. This is useful if you use the app or have non-technical people interacting with the integration.
150
+
This sensor is used to see and set the target time for your future intelligent charges for a **single** intelligent device.
151
+
152
+
This is limited to 30 minute increments between 4 and 11 to match the Octopus Energy app. This is useful if you use the app or have non-technical people interacting with the integration.
145
153
146
154
!!! info
147
155
@@ -159,9 +167,11 @@ This sensor is used to see and set the target time for your future intelligent c
This sensor is used to see and set the target time for your future intelligent charges for a **single** intelligent device.
163
173
164
-
This sensor is used to see and set the target time for your future intelligent charges. This gives you finer control over the times (still within valid time periods), but may have unintended consequences with other apps (e.g. the Octopus Energy app) that use the data.
174
+
This gives you finer control over the times (still within valid time periods), but may have unintended consequences with other apps (e.g. the Octopus Energy app) that use the data.
165
175
166
176
!!! info
167
177
@@ -180,9 +190,9 @@ This sensor is used to see and set the target time for your future intelligent c
180
190
181
191
If you're moving to this integration from [megakid/ha_octopus_intelligent](https://github.com/megakid/ha_octopus_intelligent), below is a quick guide on what entities you should use
182
192
183
-
*`binary_sensor.octopus_intelligent_slot` - Use the [is dispatching sensor](#is-dispatching)
193
+
*`binary_sensor.octopus_intelligent_slot` - Use the [off peak sensor](./electricity.md#off-peak)
184
194
*`binary_sensor.octopus_intelligent_planned_dispatch_slot` - There is no alternative for this.
185
-
*`binary_sensor.octopus_intelligent_slot_next_1_hour`, `binary_sensor.octopus_intelligent_slot_next_2_hours` and `binary_sensor.octopus_intelligent_slot_next_3_hours` - These sensors felt like they would always fall short of peoples requirements as everyone has different time periods they wish to know about. The [is dispatching sensor](#is-dispatching) exposes the current and next start/end times which could be used in a template sensor to determine how long the rate is cheap for when on. Or the [target rate](../setup/target_rate.md) or [rolling target rate](../setup/rolling_target_rate.md) might help for what you need.
195
+
*`binary_sensor.octopus_intelligent_slot_next_1_hour`, `binary_sensor.octopus_intelligent_slot_next_2_hours` and `binary_sensor.octopus_intelligent_slot_next_3_hours` - These sensors felt like they would always fall short of peoples requirements as everyone has different time periods they wish to know about. The [off peak sensor](./electricity.md#off-peak) exposes the current and next start/end times which could be used in a template sensor to determine how long the rate is cheap for when on. Or the [target rate](../setup/target_rate.md) or [rolling target rate](../setup/rolling_target_rate.md) might help for what you need.
186
196
*`sensor.octopus_intelligent_next_offpeak_start` - The default off peak start date/time can be found as an attribute on the [off peak sensor](./electricity.md#off-peak). This can be extracted using a [template sensor](https://www.home-assistant.io/integrations/template/).
187
197
*`sensor.octopus_intelligent_offpeak_end` - The default off peak end date/time can be found as an attribute on the [off peak sensor](./electricity.md#off-peak). This can be extracted using a [template sensor](https://www.home-assistant.io/integrations/template/).
188
198
*`switch.octopus_intelligent_bump_charge` - Use the [bump charge sensor](#bump-charge)
Copy file name to clipboardExpand all lines: _docs/faq.md
+17Lines changed: 17 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -35,6 +35,23 @@ Once a successful request is made, the refreshes will revert back to the redefin
35
35
!!! note
36
36
The retrieving of data does not effect the rate the entities states/attributes are evaluated.
37
37
38
+
## What are started dispatches and how are they calculated?
39
+
40
+
Started dispatches are a concept derived by the integration.
41
+
42
+
Octopus Energy provide rate information for intelligent tariffs. Unfortunately, this rate information is only the standard rate information (e.g. standard peak and off peak rates). This means that periods that are charged at off peak rates outside of the normal off peak period has to be adjusted to the off peak rate manually. Luckily, Octopus Energy provides information on planned and completed dispatches. However, there are a few issues with this data
43
+
44
+
1. Planned dispatches can be removed at the last minute. This can cause issues as they can be removed just before they start but counted as "active" if the data isn't refreshed before they start. If you have setup [the integration](./setup/account.md#intelligent-rates-mode) to accept [planned or started dispatches](./setup/account.md#planned-and-started-dispatches-will-turn-into-off-peak-rates), then this can result in sensors turning on and then turning off once the data is refreshed and the planned dispatch is removed
45
+
2. The completed dispatches do not specify a source of the dispatch. This means that boost charges (ones that do not result in off peak rates) will be mixed in with smart charges (ones that do result in off peak rates). This means that it can't be used to retroactively change rates to off peak for things like previous consumption cost sensors.
46
+
47
+
Therefore, there is the concept of started dispatches. Once data is refreshed, any planned dispatches that are active become a started dispatch, thirty minute increments at a time. This is because the whole thirty minute period for a smart charge dispatch is charged at off peak, even if only a minute charge has occurred. It is done thirty minute increments at a time because Octopus Energy might stop a dispatch early. This will only occur if the [intelligent state](./entities/intelligent\.md#current-state) is in `SMART_CONTROL_IN_PROGRESS`. For example if you have a planned dispatch of `2025-04-01T10:00:00`-`2025-04-01T11:00:00`, at `2025-04-01T10:01:00` if the planned dispatch is still available the period of `2025-04-01T10:00:00`-`2025-04-01T10:30:00` will be added.
48
+
49
+
!!! warning
50
+
51
+
This does not apply to the following providers, as they don't provide planned dispatch information.
52
+
53
+
* OHME
54
+
38
55
## The integration provides features I don't need, can I turn the feature off?
39
56
40
57
There is no config option to turn features on/off. This is because the required data is not cut and dry per feature as some data is shared among "features" (e.g. rate data is required to determine if consumption data is peak or off peak).
0 commit comments