[Ovmsdev] ACC implementation

[Stephen Casner]

Mark,

After reading both of your messages and sleeping on the question, I
can see that you might object to my idea of extending the location
config with additional parameters for ACC.  I concede that this is not
a good fit architecturally because it would be a mess to try to add
other functions tied to geofencing by the same mechanism.  As I
mentioned, my motivation for the idea was a concern about an ACC
config becoming stranded if it references a location by name and the
location is then deleted.  In OVMSv2 an ACC profile could not exist
without a location, but now you are suggesting that those profiles
could be standalone.  I suppose that when listing an ACC profile that
was bound to a location subsequently deleted I can just add a note
"(deleted)" after the name.

It seemed to me that providing backwards compatibility by implementing
the OVMSv2 ACC commands would be valuable, perhaps with some
extensions to the command syntax such as to allow naming the ACC
profiles.  Of course, we don't have the SMS gateway yet so those
commands could not be used exactly as before.  I suppose now the
preferred interface would be the webserver.  That's not my forte;
perhaps Michael could add that once the infrastructure is in place.

Although homelink is irrelevant to ACC, it might have been possible
for Timothy to set up his gate and garage door geofencing using the
ACC command syntax whereas he needed my help for the current method
that requires creating a script.  There should be a command somewhere
that says "trigger homelink 1 at location foo" that automates the
creation of the script.  But then again, where and how would you go
about listing such settings?  You could have "homelink status" or have
"location status" list homelink commands that are attached to
locations, but to implement such a listing would require parsing the
scripts to determine what homelink operation is configured.  If the
user is allowed to edit the script, then we can't assume that the
format of the script is the same as when the command created it.

I agree with your suggestion to implement the ACC functions in the
base vehicle module.  Some things like charge time prediction would
have to come from the vehicle-specific modules.  Probably the "charge"
command should be expanded with something like "at" and "by"
subcommands.

                                                        -- Steve

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

> Re-reading this, I think I may not have been clear. What I mean, at a high-level, is:
>
> Have a facility to create and maintain ACC charging profiles. Make them optionally connectable to locations (so they auto-activate in that location), but also just generally available for manual activation.
>
> Ignore homelink, it is irrelevant to ACC.
>
> Implement the ACC implementation itself in the base vehicle module, in a way that vehicles can implement/override this core charging functionality, but that we can bring the power of ACC to all vehicle types. For example, if a vehicle doesn’t support timer charging, we can do it.
>
> I hope that is clearer.
>
> Regards, Mark.
>
> > On 8 Jan 2019, at 1:58 PM, Mark Webb-Johnson <mark at webb-johnson.net> 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 <mailto: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 <mailto:OvmsDev at lists.openvehicles.com>
> >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> >
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>