Change Charge Target and Target Time sensors to selects

[GrahamShutts]

Describe the feature

Would it be possible to change the intelligent tariff sensors for charge target and target time to selectors. It would be much easier to update these values if they were drop-down lists rather than having to type in values which are then validated (for example, it’s possible to set values that are invalid and rejected by Octopus).

Expected behaviour

Be able to select charge target and Target Time from a list

Use Case

Easy selection without need to type in numbers which are then required to be validated.

Confirmation

• By submitting this feature request, you agree that you have read the documentation and confirmed it does not already exist
• I am willing/able to help contribute to the solution of this feature

[BottlecapDave]

Hello. I'm not on intelligent and the OE APIs only provide the values as numbers which is why they're exposed like they are. I'm also not sure if these accepted values differ per integration (e.g. Ford vs OHME). If you could provide the error that's raised, I can probably improve the sensors to not support invalid values. Alternatively, what values are provided as part of the app for you (and what intelligent integration are you with?)?

[GrahamShutts]

Thanks for quick response.I’m on Intelligent Octopus Go.For the target charge value, I can set any percentage, but if incorrect, the entry goes red, but no error. It is reflected in the Octopus App which then crashes if you try and edit the percentage. It should range between 10% and 100% in 5% increments.For the target time value, I get an error if set outside the permitted range. E.g setting 15:15 as target time results in:Failed to perform the action time/set_value. Errors in request (https://api.octopus.energy/v1/graphql/): [{'message': 'Serializer validation error.', 'locations': [{'line': 2, 'column': 3}], 'path': ['setVehicleChargePreferences'], 'extensions': {'errorType': 'VALIDATION', 'errorCode': 'KT-CT-4321', 'errorDescription': 'One or more serializers did not have valid input values.', 'validationErrors': [{'inputPath': ['input', 'nonFieldErrors'], 'message': '15:15:00 or 15:15:00 are outside the valid time range.'}]}}]Also, if I set the value to be something like 7:15, it is reflected in the Octopus App which crashes if I try and edit it. It should be in the range 04:00 to 11:00 in 30 minute increments.Regards,GrahamSent from my iPadOn 13 Nov 2024, at 17:00, David Kendall ***@***.***> wrote: Hello. I'm not on intelligent and the OE APIs only provide the values as numbers which is why they're exposed like they are. I'm also not sure if these accepted values differ per integration (e.g. Ford vs OHME). If you could provide the error that's raised, I can probably improve the sensors to not support invalid values. Alternatively, what values are provided as part of the app for you (and what intelligent integration are you with?)? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[philip98642]

I’ve just come to ask for the same feature. I’ve recently installed HA to automate the control of my house battery since the scheduling in Intelligent Octopus Go became more dynamic and one thing has led to another and I’m now setting up a dashboard so I can devolve the nightly configuration of intelligent octopus go to the other 2 EV drivers in the house but to get them to use it I need to make it as easy as possible to set the time.

To add to Graham’s response I don’t think he mentioned the “Ready by time” has to be from 04:00 and 11:00 in 30 minute increments as he already mentioned.

[BottlecapDave]

Thank you for supplying the required restrictions. You're not the first people to request this change, especially as its exposed to more non-technical people. When the intelligent part was first added, the API didn't give any indication to any restrictions which is why it has been exposed the way it has.

In order to not create a breaking change in the integration, if this is introduced it will need to be a new sensor that is available along side the existing sensors.

[GrahamShutts]

New sensors would be great with the required restrictions. Ideally, these sensors would be the same type as the megakid/ha_octopus_intelligent sensors for the ready time and charge limit sensors i.e. selects.

…

On Sat, 23 Nov 2024, 09:39 David Kendall, ***@***.***> wrote: Thank you for supplying the required restrictions. You're not the first people to request this change, especially as its exposed to more non-technical people. When the intelligent part was first added, the API didn't give any indication to any restrictions which is why it has been exposed the way it has. In order to not create a breaking change in the integration, if this is introduced it will need to be a new sensor that is available along side the existing sensors. — Reply to this email directly, view it on GitHub <#1079 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BDOUPSVO5CPZ5MW5QBTL4B32CBEMHAVCNFSM6AAAAABRU32FE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJVGQYTQMRRGQ> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[GrahamShutts]

Did a charge last night and noticed that the charge limit value in the octopus app is now any number between 10 and 100 - no longer just multiples of 5.

[BottlecapDave]

This was kinda why I made the sensors as they are, as the API suggests it can be any value, and it might be that the values differ depending on the intelligent provider. There is already some validation on the values, which is why it goes red, but there could be more.

I'll probably concentrate on migrating the target time one first, as this seems like it's purposefully restrictive in the app across all providers.

[BottlecapDave]

A new select based sensor for setting the time is now available in v13.5.0. The old time based sensor has been marked for deprecation and will be removed in the future. I've left the current sensor for setting the target charge but fixed the issue where an invalid value was sent to the OE API. Therefore I'm marking this issue as complete.

[paultweedy77]

Just wanted to note that although it's fine and useful to have the target time as a set of fixed select values, making the target charge percentage a set of 5%-increment select values instead of an input number would make automations that set the target charge to the %age remaining in the car battery (like I do, so it's completely automated) a bit more challenging, so I would support leaving this as it is.

[ChrisWarwick]

Just wanted to note that although it's fine and useful to have the target time as a set of fixed select values, making the target charge percentage a set of 5%-increment select values instead of an input number would make automations that set the target charge to the %age remaining in the car battery (like I do, so it's completely automated) a bit more challenging, so I would support leaving this as it is.

I also automate the target-charge-percentage value (on Intelligent Go), but I use a helper template sensor, which is set to a value between 10-95 in increments of 5. Here's the template sensor yaml:

# Helper value to calculate how much energy Octopus Intelligent charging
# should add to the car battery, based on the car's current state of charge
- name: "EV6 Battery Percentage to Add"
unique_id: ev6_battery_percentage_to_add
state_class: measurement
unit_of_measurement: "%"
state: >
{# calculate from the current state of charge, how much energy can be squeezed into the battery #}
{% set current_capacity = (100 - states('sensor.ev6_last_updated_ev_battery_level')|int(50)) %}
{# Round to the nearest higher multiple of 5... #}
{% set current_capacity = ((current_capacity/5)|round) * 5 + 5 %}
{# Make sure result is in the range 10..95 (percentage charge to add will never be outside these values) #}
{{max(10,min(current_capacity,95))}}

The automation action to set the value in the integration is then:

actions:
- metadata: {}
data:
option: "{{ percent_to_charge }}"
target:
entity_id: select.octopus_target_state_of_charge
action: select.select_option
variables:
percent_to_charge: "{{ states('sensor.ev6_battery_percentage_to_add') }}"

[BottlecapDave]

Due to a recent change in the app and integration, you no longer need to have the value be a multiple of 5.

[MJWMJW2]

Please consider to not deprecate the existing entities. time.octopus_energy_a_1a111111_intelligent_target_time allows input of time which is valid which the select does not. It is perfectly valid, for example, to select a target time of 10:59 should one wish to. Should this be done through existing sensor, or another API call, this then leaves the new sensor not able to display a value. Removing it would remove the ability to set a number of valid times which may be desired.

Similarly Charge _intelligent_charge_target can be aligned to any integer value between 10 and 100%. Using a limited select would remove valid options.

[BottlecapDave]

Charge limit has all of the validation it will have now and will not be removed or altered.

Target time was changed as a few users, including some here, gave the impression that invalid times could be entered in HA which would cause the app to break. I'm not on intelligent, so rely on the community to provide me valid information. I ideally don't want to maintain two versions of the same value, not just because it's more code, but also because as you've demonstrated the sensors can not render correctly in certain scenarios, or can become out of sync if you change one of the sensors. I'll need to think of a solution. It might be that there's a configuration option which exposes one or the other.

[philip98642]

Thanks for the changes to the charge limit. Just to restate my previous comments about the target time sensor - I need it to be simple for the 2 other EV drivers in my house to be able to select their settings - spetcifically now the preferred ready time, using the original sensor was causing issues e.g. to change from 0730 to 1100 they would need to change the minutes to 00 and then the hours to 11 because if they selected the hours as 11 then 11:30 would fail before they got to edit the minutes. The new drop down is working well for us.

[MJWMJW2]

Thanks for the changes to the charge limit. Just to restate my previous comments about the target time sensor - I need it to be simple for the 2 other EV drivers in my house to be able to select their settings - spetcifically now the preferred ready time, using the original sensor was causing issues e.g. to change from 0730 to 1100 they would need to change the minutes to 00 and then the hours to 11 because if they selected the hours as 11 then 11:30 would fail before they got to edit the minutes. The new drop down is working well for us.

In such a case it could also be possible to create a helper or set of radio buttons with predefined values for them to use within your setup. Limiting everyone to only half hour time windows I think is not a good idea.

[MJWMJW2]

Charge limit has all of the validation it will have now and will not be removed or altered.

Target time was changed as a few users, including some here, gave the impression that invalid times could be entered in HA which would cause the app to break. I'm not on intelligent, so rely on the community to provide me valid information. I ideally don't want to maintain two versions of the same value, not just because it's more code, but also because as you've demonstrated the sensors can not render correctly in certain scenarios, or can become out of sync if you change one of the sensors. I'll need to think of a solution. It might be that there's a configuration option which exposes one or the other.

I’ve not seen any breaking of the app, if you attempt to go from 07:30 to 11:00 by changing first the hour, it attempts to set the value when moving from the HH field to MM rather than on exit of the complete time entity. This then gives a brief message at the bottom of a dashboard as below. If you continue to set the minutes to 00 then the value is correctly set at octopus.

Failed to perform the action time/set_value. Errors in request (https://api.octopus.energy/v1/graphql/): ['message': 'Serializer validation error.
, locations': K'line': 2, 'column': 3}], 'path':
['setVehicleChargePreferences'], 'extensions': {'errorType':
'VALIDATION', 'errorCode': 'KT-CT-4321', 'errorDescription': 'One or more serializers did not have valid input values!, 'validationErrors':
K'inputPath': ['input', 'nonFieldErrors'], 'message': '11:30:00 or

[philip98642]

In such a case it could also be possible to create a helper or set of radio buttons with predefined values for them to use within your setup. Limiting everyone to only half hour time windows I think is not a good idea.

I am new to home assistant so I will go and read about helpers however my first instinct is that if there is a one way link between the helper and the actual time entity then it would be possible for the helper and the time entity to get out of step which I think is what Dave has said his problem is with having two entities.

I am curious to know what is the use case for setting the finish by time to not be on a half hour / hour? In the Octopus app the options are 30 minute intervals and this makes sense to me because Octopus bill half hourly so the whole half hour is at the lower rate. I also know there is no guarantee when Octopus will finish charging the car / when the car will finish charging.... even if I were to ask for the car to be ready by 10:59 Octopus may finish it at 10:35 or even 08:35 and they may change their mind during the night anyway.

[MJWMJW2]

One would write the logic to keep it in sync, but you can also consider your use case, if you set from one place only, a two way sync is not needed. You could simply have two number helpers, one to represent hours, and one to represent minutes, should hours be set to 11, then set minutes to 0. You would then use both values to set the integrations entity. This is moot however as you have a drop down.

When considering why you’d want to select sat 10:15 and not 10:30 you can extrapolate to the extreme. Why not align all to 07:00? Simply put, having a selectable time allows one to control what’s going on, the more control, the more ability we have to control when. Consider, I plug in at 10:00, I am due to leave in 15 minutes and I want +2%. Setting to 10:30, I may get no charge. Setting 10:15 I guarantee it. I can also use automation to chase that and keep adding five minutes for example assuming I’m running late.

[philip98642]

When considering why you’d want to select sat 10:15 and not 10:30 you can extrapolate to the extreme. Why not align all to 07:00? Simply put, having a selectable time allows one to control what’s going on, the more control, the more ability we have to control when. Consider, I plug in at 10:00, I am due to leave in 15 minutes and I want +2%. Setting to 10:30, I may get no charge. Setting 10:15 I guarantee it. I can also use automation to chase that and keep adding five minutes for example assuming I’m running late.

In the 10:15 to 10:30 example I would use a bump charge as I see that we get cheaper charging slots by allowing Octopus to chose when we get them - I try very hard not to ask for charge volumes which mean they must start now and last until the finish by time. This is also true for the example of just using 07:00 - I try to be realistic with the ready by time to give as much opportunity for Octopus to chose when to allocate the charge - which also works in my favor to get mid morning slots at the weekend!

[MJWMJW2]

Bump charge is at full price and would need different automations or manual engagement.

The point still is that we should allow any valid input, if a specific selection is required for a certain use case, that should be configured on an individual client side, and not block the ability for all.

[BottlecapDave]

I just wanted to say that @philip98642 hasn't been the first person to request this change, which is why it came into the integration. I've had other requests in other threads. Some of this has been from people who have come from megakids integration and potentially don't like change. Some of this has been from non technical users using the integration via a dashboard. Some of this has been from people who want the app replicated.

Originally, I didn't want to add too many restrictions and just rely on OE errors, as has been shown in this thread alone, OE can change restrictions without notice. This is why the current behaviour results in you getting an error raised if you select an invalid time.

From my pov, the less configuration, the better. But also understand this is sometimes unavoidable. Because of this, I am currently leaning towards having these sensors behind a configuration option where you get one or the other (e.g. simple Vs advanced).