[Ovmsdev] Implementing advanced charge control

[Stephen Casner]

OK, here's a more specific question.  To implement 'charge at <time>'
I need to store the pending charge operation somewhere so that it can
be examined on a ticker to see if the scheduled time has arrived.  I
presume the appropriate place is within the OvmsVehicle.  Would that
be considered in conflict with any of the state stored there now?  Any
specific recommendations for where it should go or what form it should
take?

Some vehicles have a charge timer function built in, and some allow
OVMS to set that timer.  So you might say that for those vehicles the
'charge at <time>' function should just set that timer.  However, that
timer is often a persistent setting in the vehicle, so taking it for a
one-time charge event may be inappropriate.  Mark also expressed a
concern that for the Tesla Roadster setting the timer causes the flash
in the VMS to be updated, so flash wear could be a concern.

                                                        -- Steve

On Sun, 24 Jan 2021, Stephen Casner wrote:

> 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