[Ovmsdev] ACC implementation

[Stephen Casner]

Mark,

Welcome back to the list, and thanks for your reply.

My thought was that having the ACC functionality available using the
same command language as in OVMSv2 would provide helpful backwards
compatibility for users making a transition and would not "cost" that
much.  There may be functions beyond the previous ACC that are
subsequently implemented with scripts, and that's fine.

Indeed, the implementation I have been exploring is to build on the
'locations' feature.  What I did as a first step was add a new
component for ACC and within it implement the command hierarchy as in
OVMSv2 with empty action functions.  Then I started with implementing
the action function for the HERE subcommand basically as a synonym for
"location set".  My first approach was to factor out a few lines of
code in ovms_locations to call as a global function.  The plan was to
write a separate config parameter for ACC that would not store the
lat/lon itself but would link to a location parameter by name.

However, I realized that this could get messy if the location is
removed but the ACC entry still references it, etc.  So I think it
would be better to store the extra few parameters for ACC as
additional fields in the location config.

So now the idea that I am exploring is to have the ACC code subclass
the OvmsLocation class and move some of the code into those classes
with virtual functions as needed.  Then I think I could get away with
just one instance of conditional on OVMS_COMP_ACC in
ovms_location.cpp.

The hiccup for this idea is that the "location set" command doesn't
create an OvmsLocation object directly but instead just modifies the
config and relies on ReloadMap to create the object.  That means I
would not have an object available to use its member functions.  So
I'm studying whether there would be a clean way to go ahead and create
the object and update the map at the time of the command.

                                                        -- Steve

On Tue, 8 Jan 2019, Mark Webb-Johnson wrote:

> Steve,
>
> In v2.x, ACC handled:
>
> What is now ‘locations’ in v3; geofenced areas.
> The option to fire a homelink button when entering a geofence.
> The option to perform a cooldown when plugging in.
> The option to charge at plugin, at a specific time, or complete by a specific time.
> The option to limit charging to SOC% or range.
>
> The v2.x ACC was Tesla Roadster specific.
>
> My thoughts:
>
> The #1 (locations) function has already been implemented in v3. ACC can work from that, and doesn’t need to re-implement it.
>
> Firing a homelink can be done with scripts today, and has nothing to do with ACC anyway.
>
> The core function of ACC should be Advanced Charge Control - provide a high level of charge control, in a flexible way, to vehicle types that don’t have that functionality.
>
> While this can be done in scripting, perhaps a simpler interface does make sense? Then have scripting able to override this for more advanced functionality?
>
> I think this can sit on the base vehicle module, and control the vehicle implementation beneath it. For example, have functions to set the charge type (on-plugin, at a specific time, complete by time, etc) and have a base implementation that does it from ovms if the vehicle implementation can’t. So long as the base vehicle implementation can do ChargeStart and ChargeStop, the rest can be built on top.
>
> ACC then become the language to control these functions, and perhaps something to tie a particular charge profile to a location geofence.
>
> Regards, Mark.
>
> > On 5 Jan 2019, at 3:05 PM, Stephen Casner <casner at acm.org> wrote:
> >
> > Mark has suggested that the "advanced charge control" (ACC) functions
> > of OVMSv2 could be implemented in OVMSv3 using scripting.  However,
> > there are some missing parts remaining in the scripting support.
> >
> > Since I have a couple of friends anxiously awaiting ACC in OVMSv3,
> > I'm thinking of implementing it in C++ as a command following the
> > previous implementation.  Is there any reason that would be a bad
> > idea?
> >
> >                                                        -- Steve
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev