[Ovmsdev] ACC implementation

Mark Webb-Johnson mark at webb-johnson.net
Tue Jan 8 14:10:24 HKT 2019

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20190108/e4031667/attachment.htm>

More information about the OvmsDev mailing list