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@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev