[Ovmsdev] Implementing advanced charge control

[Greg D.]

Steve,

Is there a way to secure the Homelink activation to be more than just
location? 

It's been a while, but I just got another "possible flatbed" message
earlier this month, which makes me wonder if the car's nocturnal
wanderings might inadvertently trigger the garage door to open as a side
effect.  Security-wise, that would be bad.

Greg


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
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev