Mark, Along the same lines, when I poked around the web UI it occurred to me that it would be a logical (and I think intuitive) extension to the location configuation page to allow specifying some actions to be associated with a location. Are you proposing that those actions be stored in the location config? That's where I was heading with the ACC feature when I began to wonder whether that would be considered inappropriate. I suppose we could define a syntax to allow appending a chain of actions after the basic location config. I'm still a bit unclear on how much an "ACC profile" could specify. In the OVMSv2 ACC command, it was just the combination of a mode (standard or range), start time (on plug-in, at a time, or as appropriate to end at a particular time), and optionally an ending condition (SOC or range) other than what the car's algorithm would normally do. I suppose the option to do cooldown on plug-in could also be considered part of a profile. But would users really want to access those profiles for a manual charge (not associated with a location) as opposed to just giving the charge command(s)? -- Steve On Fri, 11 Jan 2019, Mark Webb-Johnson wrote:
Steve,
I haven’t had much time to think about this, so putting this out just for comment. Not really sure the best way, but this does seem to be narrowing down to something quite useful.
I agree that there is value for a simplified system (configured by command and/or web interface). Scripting is certainly not for the novice user.
Brian’s comments (and the issue of Homelink), coupled with the above ’novice’ user requirement, has made me think about this from another direction. Perhaps we need a simple mechanism for a location to have ‘actions’. Like activate homelink, send a textual notification, activate an ACC profile, etc. Those actions can be chosen from a hard-coded extensible set, and config can be via web or commands. Each location would have both enter and exit actions. This connects locations to ACC, but in a general way (allowing for other simple location actions such as homelink activation).
Then we come to ACC. I’m still thinking this should be on the vehicle side. Have the ability to define smart ACC charge profiles, and choose one as the active one (or otherwise one of the other charge modes). So, our charge types become one of: On demand On plug-in On timer ACC profile etc
Does that solve the problem, and provide a general enough framework?
Regards, Mark.
On 9 Jan 2019, at 6:55 AM, Stephen Casner <casner@acm.org> wrote:
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@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@acm.org <mailto: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 <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev