[Ovmsdev] Implementing advanced charge control

[Michael Balzer]

Steve,

just a note on the ACC capabilities: the system should also support SOC 
and 12V level guards, i.e. start the charge when the SOC or 12V level 
drops below a configured threshold while parked at a charging location.

In addition to that, it should be possible to set custom 
commands/scripts for starting and stopping the charge process depending 
on the location, to support controlling smart plugs or home automation 
systems.

Regards,
Michael


Am 25.01.21 um 08:45 schrieb 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
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210128/ed39ed25/attachment.sig>