The purpose of this document is to explain how the scheduler works, focusing on the high-level concepts and goals rather than specifics of the implementation.
The scheduler is a contained package of logic that determines when a particular EVSE or vehicle should charge. It does so based on user settings, EVSE or vehicle data and external signals.
At ev.energy, we define managed charging as charging that is controlled by our software. If a charging session is not controlled by us, then it is unmanaged. In this case, we don't (or can't) send any charging commands to the charger or vehicle and our scope is limited to just reporting EVSE/vehicle data to the user.
- Smart: ev.energy performs some optimisation and determines when it's best for the EV to charge. There are various types of smart charging, depending on the driver settings - see below for more details.
- Boost: we charge the EV immediately when the driver activates boost mode, until their maximum % is reached or until the driver disables the boost mode.
- Load management: this applies to sites with multiple EVSEs and it is used to control the maximum rate of charge of each EVSE to avoid it exceeding the site limit. In this case, we are not performing a smart optimisation (i.e. we're not optimising and controlling the timing of charge) but rather a charge rate optimisation (reducing the charge rate of each EVSE).
We generally distinguish between:
- Unmanaged at home: the session is unmanaged but it is happening at the driver's smart charge location
- Unmanaged on-the-go: the vehicle is charging somewhere other than their smart charge location
The behaviour in the two cases is analogous - i.e. we have no control over the charge.
We generally expect the vehicle to start charging straight away when plugged in for an unmanaged session (unless the hardware is faulty). There are cases, however, where the EVSE or the vehicle is unmanaged by ev.energy but is being managed by the customer using different systems (e.g. a timer on the EVSE or the vehicle manufacturer's app). We refer to these as “customer-managed” sessions. Again, from our point of view, there is no difference between how fully unmanaged and customer-managed charging sessions are treated (all we do is report what happened).
While we generally refer to both of these modes as “smart scheduling”, there are actually two separate ways we optimise and control charge:
- Load-planning defines a schedule, i.e. a series of periods in the future where each period is characterised by a specific charge instruction. It does so by estimating how much charge the EV needs and finding the best times to provide a full charge (or to the desired level) before the user-selected ready-by time. (There are exceptions to this dictated by the settings described below.)
- Load-matching is the act of matching the EV charge command to a load - generally solar excess generation - in (nearly) real-time. It doesn't generate a schedule, but rather continuously adapts to external conditions by modulating the EVSE or Vehicle's charge rate.
Below is a list and description of all the inputs that can affect the schedule calculation.
Note: at the time of writing, not all of these settings are exposed by our API. If you need access to a setting not currently available, please contact your account manager or email developers@ev.energy.
- Smart charging on/off: The user can turn smart charging on/off. If off, none of the below settings apply and their charging will be unmanaged, except for enforcing their maximum charge level.
- Boost mode on/off: When smart charging is on, the user can temporarily override smart charging by turning on boost mode. This will stop any smart charging optimisation and prompt the EVSE/vehicle to start charging immediately. The charge will continue until the battery is full or boost is turned off by the user.
- Ready-by time: This is the time (in the local time zone) when the user wants the car to be charged by. One ready-by time is set for each day of the week. The smart scheduler will look at this ready-by time and aim to fully charge the battery by then (subject to some of the constraints discussed below). If a car is plugged in after the ready-by time for that day of the week, it is assumed that the target ready-by time is the one for the day after.
- Override schedule: This allows the user to override the next ready-by time as a one-off, while keeping the same ready-by time settings for future sessions.
- Precondition battery on/off: When this is on, the scheduler will try to schedule up to one hour of charging as close as possible to the ready-by time. The remaining charging required will be done based on the smart scheduling optimisation. This is so the battery is warm before the user starts driving it, which has efficiency gains in cold weather.
- Only charge off-peak on/off: When this is on, the smart scheduler will not schedule any charge when the electricity price is above the specified threshold. In this scenario, we can't guarantee that the vehicle battery will be fully charged, as the hours when the electricity price is below or equal to the threshold before the ready-by time may be fewer than what is required. If there is a sufficient amount of time with electricity price below or equal to the threshold before the ready-by time, then the usual smart charging optimisation will be used to prioritise charge within those hours.
- Price limit: The user can enter the price threshold (local currency / kWh) above which they don't want us to charge. The range of possible price limits shown to the user is determined based on the electricity prices for their tariff over the next 24 hours. The user can't select a price outside of this range.
- Minimum charge level: The user can set a minimum charge level. When the car is plugged in, the scheduler will start charging immediately to reach that minimum charge level. The remaining amount of charge will be optimised as usual. The setting cannot be used in cases where we don't have state-of-charge data (EVSE-only integrations).
- Maximum charge limit: The user can set the maximum charge limit they want their car batteries to be charged to. If they don't, we aim to charge the battery to 100%. This setting cannot be used in cases where we don't have state-of-charge data (EVSE-only integrations). When possible, we sync this setting with the vehicle's internal charge limit setting.
- Trickle charging on/off: When trickle charging is on, we smart charge at full power as usual; however, when the vehicle is supposed to not charge, we charge it at a rate of 6A (instead of not charging at all). This is a workaround for certain vehicles which fall asleep when not charged for a certain amount of time, preventing later charge commands taking effect.
- EVSE lock: This is meant to prevent unauthorised use of an EVSE. The feature is only available for EVSE integrations. there are two types of EVSE locks that can be selected:
- Smart lock: the EVSE can only dispense power during the times selected by the smart scheduler or when boost mode is turned on. This is the default smart charging behaviour.
- Holiday lock: the charger will never dispense power. If this option is selected, no charge will happen - until the lock is turned off.
- Solar on/off: When this is on, the smart scheduler will take the user's solar generation into account as well, when that is available. The details of how this works depend on the selected solar mode and on the hardware compatibility. However, the overall idea is for the scheduler to prioritise charging from the user's home solar excess generation - as that is a free and green resource.
- Solar mode: the user has the choice between two solar modes
- Solar only: The scheduler will charge exclusively from solar excess generation. This does not take into account the user's ready-by time: it just charges the car whenever solar excess generation is available. The charge rate is modulated to match the available solar excess generation. The battery may not be fully charged.
- Solar and grid: In this case, the charge rate is not modulated, i.e. the EVSE and EV will charge at their maximum rate. When there is solar generation available, the corresponding electricity price for that period is discounted, as the proportion of charge coming from solar generation is free. The smart scheduler then does its usual optimisation, but considering the modified electricity prices as input.
- Array size: Size of the solar panel array. This is used to estimate the solar generation forecast.
- Solar mode: the user has the choice between two solar modes
These are the time-series data that determine the priorities for scheduling slots. We expect to have a series of data for each from the beginning to the end of a charging session. If a particular type of energy data is missing then it will just not be considered in the optimisation.
- Electricity import prices: Prices for customer's electricity tariff. If there are data gaps in the prices, an infinitely high price is assumed (this is a conservative approach to discourage charge when we're not sure what the price of electricity is).
- Grid levels: These represent demand response and grid services signals. As with a tariff, low values are meant to encourage charge (e.g. encouraging charge when the load on the grid is low) while high values are meant to discourage charge (e.g. to shift charge away from peak times).
- Carbon intensity: This represents the grams of CO2 emitted per unit of energy produced. The scheduler will aim to charge when the carbon intensity is lowest. As with tariffs, when there are data gaps, an infinitely high carbon intensity is assumed.
- Solar excess generation: This represents the net solar power generated by the customer's solar array (net of the amount of that generation that is consumed by the household itself, i.e. this amount would otherwise be input into the grid). There are two ways we can get this data:
- Hardware: the EVSE itself or another asset (solar inverter, battery) measures the solar excess generation and reports it to us (either via direct EVSE integration or through an API with the asset).
- Software: We get solar generation forecasts for the user's location using an external API. We then combine those with the array size info input by the user, to generate an estimate forecast of the solar generation at the user's premises. This is actually an estimate of the total solar generation (rather than the excess after household consumption); for this reason, we sometimes ask the user to adjust down their array size as an approximation.
- Household load: This represents the net household electricity demand at the user's premises (net of any generation). This is used by the V2H algorithm to match discharge with electricity demand. It needs to be obtained via a hardware integration, i.e. a CT clamp measuring the net load at the premises. Note that this is exactly the same measurement as hardware solar excess generation: if demand exceeds generation then a net flow of electricity into the home will be detected (positive net household load and zero excess solar generation); if generation exceeds demand then a net flow of electricity out of the home will be detected (zero net household load and positive excess solar generation).
This is data that is derived from the assets' (EVSE and/or vehicle) specification and from their data logs.
- Required time to full charge: This is the amount of time that needs to be scheduled to fully charge the vehicle battery from the current state of charge. Note that this can be reduced in the scheduler based on the user-defined maximum charge limit (i.e. if the user only wants their battery charged to 80%). The required time to full charge can be derived from:
- Vehicle logs directly: some vehicles report the number of minutes they need to be charged for
- A combination of:
- Vehicle battery size: static information saved on the vehicle trim
- Current state of charge: this can be obtained from the vehicle. For users that have an EVSE-only integration and, therefore no state of charge data, the current state of charge is always assumed to be zero at the beginning of a charging session, and updated during the charging session by summing the amount of energy that has gone into the vehicle since the start.
- Charge rate at location: this can be obtained from the EVSE or vehicle logs. It estimates the charge rate at which we expect the vehicle to charge based on historical charge rate data.
Note: The required time to full charge is augmented by 1 hour before being input in the scheduler. This is a rough conservative approach used to make sure the car is fully charged (which is prioritised over the “perfect” optimisation).
- Available charge rate steps: This is used for solar-only and solar smart optimisations where we aim to modulate the charge rate to match solar excess generation. When trying to match solar, we need to take into account that the charger/vehicle may only be able to charge at certain power levels. This determines what power levels are available to the asset and therefore can be instructed as a charging command. We use the nearest, higher charging level (e.g. if solar excess generation is 1900W and the asset can only charge at 1400W, 2000W and 3000W, we will issue a command to charge at 2000W).
The output of the scheduler is a schedule for that charging session. A schedule is composed of a series of (half-hourly) periods; for each period, a charging current is specified. This is meant to distinguish charging on/off periods. Unless modulating the charging current (solar-only and solar smart), the current during charging-on periods is always defined as the maximum 32A current, even if the asset has a lower maximum current (any asset-specific current constraint is handled later when sending the command). The current during charging-off periods is defined as 0A, unless trickle charging is turned on.
Schedules get recalculated throughout the charging session. Whenever they get calculated the series of periods spans from the current half-hour to the next ready-by time. After creating the schedules a command is also enqueued to execute the schedule, i.e. sending the relevant instructions to the EVSE or vehicle.
Assuming none of the constraints detailed above apply, smart sessions (managed sessions at a user's home location) will be scheduled based on these priorities:
- Electricity price (lowest first). This does not include slots above the price threshold, if present. A price threshold will be respected, even if it means not charging the vehicle on time.
- Grid signal (lowest first). Note that grid signal values are arbitrary numbers between 1 (do charge) and 100 (do not charge). A default base grid level of 50 is automatically assigned.
- Carbon intensity, in gCO2e / kWh (lowest first)
- Time (latest first)
Each level serves as a tie-breaker only when multiple periods have equal values for the levels above. In other words, the smart scheduler aims to satisfy these requirements, in order:
- The vehicle will be fully charged, on time.
- Charging will be as inexpensive as possible.
- The most grid services will be performed.
- The greenest energy will be used for charging.
- Charging will occur at the latest possible time.
The latter is to take into account the fact that if we overestimate the amount of charge the vehicle needs (and we do tend to overestimate it, especially for EVSE-only integrations where we don't have state of charge information) we wouldn't want to to start charging too early and fill the vehicle up before we get to the off-peak cheaper prices.
Example: I plug in my vehicle at 8pm and the off-peak cheaper period is midnight-7am, the scheduler thinks it needs 12 hours of charging so it schedules to charge for the whole duration of the off-peak period + the last 5 hours before ready-by time. The vehicle actually just needed 4 hours of charging. In this scenario, since we prioritised the latest times, that's all good: it will still charge those 4 hours during the off-peak period. Had we prioritised earliest times though, it would have scheduled to charge for the whole duration of the off-peak period + the first 5 hours after plug-in. Since the vehicle only needed 4 hours of charge, it will get full by charging at the initial peak times and no charging will occur during the off-peak period.
Not enough time to charge before ready-by time
If, based on the estimated required charge time, there isn't enough time to charge the vehicle before the ready-by time, then the scheduler will just set all schedule slots to charging on. This is equivalent to the car charging as soon as possible.
Any price thresholds and solar-only charging will still be enforced.
What happens past the ready-by time
Similarly to the previous scenario, if we reach a user's ready-by time while smart charging and the maximum charge limit has not been reach, we will schedule full charge until the limit is reached. Any price thresholds will still be observed.
The objective of solar-only is to only charge the vehicle from solar excess generation. This is different approach to smart charging, it does not aim to fully charge the battery by the ready-by time or following any of the user settings. It will only charge the car to the extent that there is solar excess generation available.
In particular, it does this by matching the charging current to the solar excess generation. As mentioned above, the EVSE or vehicle may not be able to charge at arbitrary levels, so the available current steps for that asset are taken into account: the scheduler will aim to charge at the minimum allowed level that is higher than the excess solar generation level.
When excess solar generation is below 1.4kW, we don't charge the EV. This is considered the minimum charge level, under which the charging efficiency is too low to make it worthwhile.
In order to get an estimate of solar excess generation when we don't have any hardware integrations, we use a third-party API to get solar generation efficiencies by location (latitude and longitude). The location is based on the location set by the user. The efficiencies returned by the API represent the amount of solar generation expected at that location per kW of solar array. These are therefore multiplied by the array size in order to get a series of solar generation values for the period considered.
These are actually solar generation values, rather than excess solar generation, i.e. it does not take into account that some of the solar generation will be self-consumed in the household (and only the excess after that will be used to charge the vehicle). For this reason, we often suggest that users reduce the size of their array setting if they wish to consume solar energy for their household as well as their vehicle.
The solar + grid logic is very similar to the “generic” smart charging one. The key difference is that solar excess generation (derived, as described above, from the external forecasts) is used to “discount” the electricity prices that are then used to prioritise the schedule slots. This is meant to take into account that, when the car is charging and there is solar excess generation available, the charging power will be partly drawn from the grid (for which we pay the relevant electricity price) partly from the solar excess generation (which is free).
Example: Between 11am and 11:30am there is 4kW of solar excess generation available. The price of electricity at that time is 15p/kWh. The real price the user would pay to charge the vehicle at 7kW between 11am and 11:30am would be:
(4kW x 0p/kWh + 3kW x 15p/kWh) x 0.5 hours = 22.5p
This is equivalent to saying that the electricity price for that time is 3/7th of the original electricity price (because we're only drawing 3kW from the grid). This might make it cheaper to charge at 11am than, for example, overnight when the electricity price is 5p/kWh.
More on solar + grid can be found on our support website here.
The scheduler is run for all smart open charging sessions every half-hour, on the half-hour. In some cases, the scheduler is also run for specific sessions when conditions change, e.g. when user settings get modified or when a new grid signal is sent.
The key inputs are the current solar excess generation that the algorithm needs to match (coming from the hardware, generally a CT clamp connected to the EVSE) and the available current steps the asset supports (see above for more details on these).
The output of the load matching algorithm is not a schedule, but rather an instantaneous command (with the appropriate charging current) to be sent to the EVSE or vehicle. This allows us to immediately respond to signals from our various data sources.
In this case, we receive data on the solar excess generation through a piece of hardware, generally a CT clamp connected to the EVSE. We process this data and aim to match the charging current to it. This is done instantaneously as we receive the data from the hardware (so there is no forward-looking optimisation).
We don't manage charging ourselves in this case (added here just for completeness). In this case, the EVSE firmware automatically matches the charging current to the solar excess generation readings on their clamp. No commands are issued from our platform.
Hardware-passthrough solar-only is triggered automatically every time we receive CT clamp data from a charger.