I've been working intermittently over the past two years on functionality to replace the ACC (advanced charge control) feature of OVMS v2. As an example, ACC could be configured to begin a cooldown charge cycle upon plug-in at home. In OVMS v3 the geofencing aspect of the ACC feature was implemented in the "location" command to be usable more generally. Based on design discussions with Mark about how the charge control operations and other functions should be attached to geolocations I have extended the location command to allow a list of actions to be attached to a defined location upon entering or leaving. The initial set of actions is: - acc -- initiate a charging profile (only upon entering) - homelink -- transmit homelink code - notify -- send a notification text to the app While this activity has been in progress the OVMS scripting features have been enhanced significantly. It is possible to do much of what I describe using scripts that are triggered upon entering or leaving a location. However, creating and installing scripts requires some developer skills that are likely beyond the comfort zone of many OVMS users, so I think it is still worthwhile to implement these location actions. At this point the homelink and notify actions are already implemented for activation upon entering or leaving a location. Assignment of acc actions to locations is also implemented, but those actions have no effect at this point. This message describes what I propose for acc. ACC is based on named charging profiles that specify a charge type (on-demand, charge at time, charge by time, etc) and associated parameters controlling the charge. Mark suggested that at home he might want to do a: Type: Charge By Cooldown on plugin Charge limit: 90% SOC Charge mode: Standard Charge current: 32A Complete charge by 7am Another example: Type: Charge At Cooldown: no Charge limit: 200km Charge mode: Standard Charge current: 32A Start charge at 11pm Charge profiles could also be activated manually or by a script. For example, you might arrive at a restaurant and type "charge acc ontheroad" to select the profile ontheroad without having to set all the individual parameters. The "charge" command currently includes subcommands to set the current and mode but would need to be extended to control times and limits. The front-end changes would be to extended the command tree as follows: acc list <name> acc set <name> at <time> acc set <name> by <time> acc set <name> on-plugin acc set <name> soc <percent> acc set <name> range <distance> acc rm <name> acc rm <name> at <time> acc rm <name> by <time> acc rm <name> on-plugin acc rm <name> soc <percent> acc rm <name> range <distance> charge acc <name> charge at <time> charge by <time> charge on-plugin charge soc <percent> charge range <distance> The choices at, by and on-plugin are mutually exclusive, so the last one is effective. The soc and range limits will stop the charge when reached and if set together with a "by <time>" would cause charging to continue after the specified time if the limit has not been reached. Charge profiles would be stored in the config in a manner similar to the way locations are stored with the name as the instance and the list of charge parameters in the value. I have not worked out all the backend details yet, so this is where those of you who are more familiar with the vehicle code can provide some guidance. Mark's suggestion was to extend the general vehicle framework to support the core ACC functionality; some parts might be handled completely at the generic layer, while other parts would require vehicle-specific implementation. The goal is to bring a set of advanced charge control functionality to all vehicle types (even if the vehicle has limited support). So long as the vehicle can start / stop charging, we can provide things like timed charges (at or by) in OVMS firmware. So at a minimum the functionality we require is the vehicle ability to start a charge, stop a charge, and provide signaling when the pilot signal is detected. We also need to be able to monitor the SOC and range as they increase during charging, but I think those values are already implemented well enough in the metrics. Some cars might not be able to support the minimum functions, so we may need some sort of capabilities back from the vehicle module to know whether the acc functions can be implemented Something like 'HasChargeStop', 'HasChargeStart', 'HasTimer', etc. Since many cars will normally start charging as soon as the charge cable is plugged in, OVMS needs to see the pilot-signal-present notification and stop the car from charging until the ACC conditions dictate. This is the case for the Tesla Roadster unless the car is at a location where a scheduled charge time has been configured. But having a scheduled charge configured is not good because that may interfere with what OVMS is trying to control. The "charge by" operation requires using the charge time predictor to figure the start time, then is becomes the same as "charge at". I have some concern that the existing CTP may not be accurate for Roadsters with the 3.0 battery. I don't know whether the other vehicles have an accurate CTP. The "charge on-plugin" operation has an associated event, but all the other operations require use of a ticker to see if the start time has come or the stopping condition has been reached. Comments appreciated. -- Steve