jonasbkarlsson / ev_smart_charging

Electric vehicle smart charging for Home Assistant.
MIT License
169 stars 25 forks source link

Earliest time slot to charge not latest #180

Open andlo opened 1 year ago

andlo commented 1 year ago

Version of the custom_component

Version 1.8.0

Configuration

Describe your configuration here.

Describe the bug

When no completion time is set, it defaults to a slot in cheapest time. That is fine, it it uses latest possible time and not earliest cheapest time slot.

Debug log


Add your logs here.
jonasbkarlsson commented 1 year ago

For clarification, do you mean that if, for example, there is one hour of planned charging and there are two hours with exactly the same the lowest price, then the integration chooses the later of the two hours?

andlo commented 1 year ago

As I see it if there is 3 hours with same low prise, and only need one hour charging, it chooses the last hour and not the first

Arjanmus commented 1 year ago

+1 Tomorrow there are 5 consecutive hours with the same price (within 0.001 euro). My charging is planned at the latest hours in this window. All other things being equal, I would prefer to charge at the earliest hours.

Clausr commented 1 year ago

I was looking to create a feature request as well, to have have the ability to add some margin to the prices. So if the price is within 0.05 or something like that, it would be more preferable to have the car charged sooner (rather than up to 0.05 cheaper) - Alternatively it could be a setting looking at amount of digits that the user cares about.

I'm also pretty sure that @andlo might not be seeing the last digits of the price (on the graph), which is why it chooses the latter timeslot.

andlo commented 1 year ago

I'm also pretty sure that @andlo might not be seeing the last digits of the price (on the graph), which is why it chooses the latter timeslot.

That is very sensibly.

jonasbkarlsson commented 1 year ago

If the price is exactly the same during several hours, the integration will choose the earliest hours. So when it might have looked like it has choosen the latest hours, those latest hours have been cheaper, but by so little that it was not visible.

One way to achieve what you are asking for is to add a new configuration entity, "price resolution", that would apply a rounding to the prices before finding the lowest earliest price.

Assuming the prices [1.23 1.21 0.9].

Resolution 0.1 would give [ 1.2 1.2 0.9]. Last hour being the earliest lowest hour. Resolution 1.0 would give [ 1.0 1.0 1.0]. First hour being the earliest lowest hour.

How important would this be?