[Ovmsdev] Implementing advanced charge control

[Stephen Casner]

I've been working intermittently over the past two years on
functionality to replace the ACC (advanced charge control) feature of
OVMS v2.  As an example, ACC could be configured to begin a cooldown
charge cycle upon plug-in at home.

In OVMS v3 the geofencing aspect of the ACC feature was implemented in
the "location" command to be usable more generally.  Based on design
discussions with Mark about how the charge control operations and
other functions should be attached to geolocations I have extended the
location command to allow a list of actions to be attached to a
defined location upon entering or leaving.  The initial set of actions
is:

  - acc -- initiate a charging profile (only upon entering)
  - homelink -- transmit homelink code
  - notify -- send a notification text to the app

While this activity has been in progress the OVMS scripting features
have been enhanced significantly.  It is possible to do much of what I
describe using scripts that are triggered upon entering or leaving a
location.  However, creating and installing scripts requires some
developer skills that are likely beyond the comfort zone of many OVMS
users, so I think it is still worthwhile to implement these location
actions.

At this point the homelink and notify actions are already implemented
for activation upon entering or leaving a location.  Assignment of acc
actions to locations is also implemented, but those actions have no
effect at this point.  This message describes what I propose for acc.

ACC is based on named charging profiles that specify a charge type
(on-demand, charge at time, charge by time, etc) and associated
parameters controlling the charge.  Mark suggested that at home he
might want to do a:

Type: Charge By
Cooldown on plugin
Charge limit: 90% SOC
Charge mode: Standard
Charge current: 32A
Complete charge by 7am

Another example:

Type: Charge At
Cooldown: no
Charge limit: 200km
Charge mode: Standard
Charge current: 32A
Start charge at 11pm

Charge profiles could also be activated manually or by a script.  For
example, you might arrive at a restaurant and type "charge acc
ontheroad" to select the profile ontheroad without having to set all
the individual parameters.  The "charge" command currently includes
subcommands to set the current and mode but would need to be extended
to control times and limits.

The front-end changes would be to extended the command tree as
follows:

    acc list <name>
    acc set <name> at <time>
    acc set <name> by <time>
    acc set <name> on-plugin
    acc set <name> soc <percent>
    acc set <name> range <distance>
    acc rm <name>
    acc rm <name> at <time>
    acc rm <name> by <time>
    acc rm <name> on-plugin
    acc rm <name> soc <percent>
    acc rm <name> range <distance>

    charge acc <name>
    charge at <time>
    charge by <time>
    charge on-plugin
    charge soc <percent>
    charge range <distance>

The choices at, by and on-plugin are mutually exclusive, so the last one
is effective.  The soc and range limits will stop the charge when
reached and if set together with a "by <time>" would cause charging to
continue after the specified time if the limit has not been reached.

Charge profiles would be stored in the config in a manner similar to
the way locations are stored with the name as the instance and the
list of charge parameters in the value.

I have not worked out all the backend details yet, so this is where
those of you who are more familiar with the vehicle code can provide
some guidance.

Mark's suggestion was to extend the general vehicle framework to
support the core ACC functionality; some parts might be handled
completely at the generic layer, while other parts would require
vehicle-specific implementation.  The goal is to bring a set of
advanced charge control functionality to all vehicle types (even if
the vehicle has limited support).  So long as the vehicle can start /
stop charging, we can provide things like timed charges (at or by) in
OVMS firmware.

So at a minimum the functionality we require is the vehicle ability to
start a charge, stop a charge, and provide signaling when the pilot
signal is detected.  We also need to be able to monitor the SOC and
range as they increase during charging, but I think those values are
already implemented well enough in the metrics.

Some cars might not be able to support the minimum functions, so we
may need some sort of capabilities back from the vehicle module to
know whether the acc functions can be implemented Something like
'HasChargeStop', 'HasChargeStart', 'HasTimer', etc.

Since many cars will normally start charging as soon as the charge
cable is plugged in, OVMS needs to see the pilot-signal-present
notification and stop the car from charging until the ACC conditions
dictate.  This is the case for the Tesla Roadster unless the car is at
a location where a scheduled charge time has been configured.  But
having a scheduled charge configured is not good because that may
interfere with what OVMS is trying to control.

The "charge by" operation requires using the charge time predictor to
figure the start time, then is becomes the same as "charge at".  I
have some concern that the existing CTP may not be accurate for
Roadsters with the 3.0 battery.  I don't know whether the other
vehicles have an accurate CTP.

The "charge on-plugin" operation has an associated event, but all the
other operations require use of a ticker to see if the start time has
come or the stopping condition has been reached.

Comments appreciated.

                                                        -- Steve