<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Steve,<div class=""><br class=""></div><div class="">In v2.x, ACC handled:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">What is now ‘locations’ in v3; geofenced areas.</li><li class="">The option to fire a homelink button when entering a geofence.</li><li class="">The option to perform a cooldown when plugging in.</li><li class="">The option to charge at plugin, at a specific time, or complete by a specific time.</li><li class="">The option to limit charging to SOC% or range.</li></ol></div><div class=""><br class=""></div><div class="">The v2.x ACC was Tesla Roadster specific.</div><div class=""><br class=""></div><div class="">My thoughts:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">The #1 (locations) function has already been implemented in v3. ACC can work from that, and doesn’t need to re-implement it.<br class=""><br class=""></li><li class="">Firing a homelink can be done with scripts today, and has nothing to do with ACC anyway.<br class=""><br class=""></li><li class="">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.<br class=""><br class=""></li><li class="">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?<br class=""><br class=""></li><li class="">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.<br class=""><br class=""></li><li class="">ACC then become the language to control these functions, and perhaps something to tie a particular charge profile to a location geofence.</li></ul></div><div class=""><br class=""></div><div class="">Regards, Mark.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 5 Jan 2019, at 3:05 PM, Stephen Casner <<a href="mailto:casner@acm.org" class="">casner@acm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Mark has suggested that the "advanced charge control" (ACC) functions<br class="">of OVMSv2 could be implemented in OVMSv3 using scripting.  However,<br class="">there are some missing parts remaining in the scripting support.<br class=""><br class="">Since I have a couple of friends anxiously awaiting ACC in OVMSv3,<br class="">I'm thinking of implementing it in C++ as a command following the<br class="">previous implementation.  Is there any reason that would be a bad<br class="">idea?<br class=""><br class="">                                                        -- Steve<br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></div></blockquote></div><br class=""></div></body></html>