jonasbkarlsson
commented
1 month ago Thanks for the very detailed suggestion and thoughts about charging using PV. I have had similar thoughts myself, and also about adding other more advanced energy mangement features.
The conclusion I have made is that the current integration is already "too" complex, and it would become unfeasible to test and maintain the integration if such features would be added. Instead, my thought is to make another integration that handles those more high-level features, and that integration could then use this integration as a tool to control the EV charging.
That said, I should also say that I will not have time to make such a high-level intergration anytime soon, I'm afraid.
In Home Assistant we have a forecast module for the energy dashboard, which shows a forecast with the PV production per hour. (Unfortunately I haven't yet found a sensor which contains this hourly based PV forecast data, for today day or the next day. )
We could use this hourly data to include how much can be charged from PV, and thus optimize the charging planning from the grid based on the predicted available PV energy.
"Basic" implementation: All PV forecast hours between now and the departure time could be included, if they are above the minimum required level to start charging (e.g. 1.4 kWh). We now have a value, which we will call available PV kWh before departure. We can subtract this from the amount that is required to be charged by the grid.
Example: We need to charge the car with 20 kWh before departure. There will be 10 kWh of available PV energy during this period. Now we only need to calculate how to optimize for the remaining 10 kWh.
The only constrain here is that we can't exceed "number.ev_smart_charging_charging_speed", and the example doesn't take into consideration if there is grid and PV load at the same moment. To workaround this we could opt to not plan grid charging at all, when PV charging happens. (simpler to implement, but not as cost efficient.)
Safety feature There should also be a safety feature; since forecast are not accurate by nature, and we don't want to have a lower SoC than required upon departure. This safety feature would also solve the "number.ev_smart_charging_charging_speed" limitation mentioned above.
What it does is, it adjusts the planned charging, by excluding the last period before departure from the planned charging. Of course this only needs to happen while the PV forecast outcome still assumes that some PV charging will happen.
The unused/planned period before departure, can be used used to catch up to the desired battery level. To compensate for situations where the actual PV output was lower than forecasted, or grid and PV where both charging and we didn't compensate for the lower grid input. The length of this safety period should depend on the required time to go from current SoC to the desired SoC, based on the number.ev_smart_charging_charging_speed.
Benefit of this safety feature is that the EV battery may also be warm at departure, improving efficiency and battery health.
implementation which takes PV and grid mix into consideration: By calculating the mixture of PV energy and grid energy. We can optimize the cost based calculations, and also allow for charging when PV output is below 1.4 kWh. However it requires some extra variables, which may add additional complexity?
This would mean you have two extra variables:
number.ev_smart_charging_charging_speed_solar, containing the forecasted solar output for each hour.
number.ev_smart_charging_charging_speed_grid, containing grid limit (per hour). Usually this would be the same as number.ev_smart_charging_charging_speed. However to add support for users that have hourly capacity based tariffs, this could come in handy later.
Neither the grid or solar variables can exceed the max charging speed of the charger/car, configured in: number.ev_smart_charging_charging_speed. Now for each hour we can calculate what the available grid speed would be; grid speed - solar speed = effective available grid speed
Now we can use this hourly available grid speed to optimize the moments to charge from the grid. Even with this approach, it would still need the same safety feature as mentioned earlier. Since we still predict solar output.
Some configurable settings: Prefer negative energy prices, or solar. Some users may prefer the negative energy price. Others may prefer to use all their own solar energy, for environmental or other reasons (e.g. solar return fees).
Always charge for x period before departure. Set a configurable period before departure, during which the battery will be filled to the desired SoC. This would defer some % of the Desired SoC, till the period just before departure. Reason for this is to warm up the battery before departure, improving efficiency when driving and improving battery health.
Some features to take into consideration: The above probably includes some redesigning. While doing this, it may make sense to look into a configurable charge speed per hour (e.g. for those users that want to prevent exceeding their hourly capacity based tariffs)
Feature which subtracts basic household load from predicted PV output.