<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=""><blockquote type="cite" class="">Are you proposing that those actions be stored in the location config?</blockquote><br class=""></div><div class="">Yes, I’m thinking these actions could be associated with each location (and direction - ‘enter’ or ‘leave’). Configuration of the locations page of the web ui makes sense.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">I suppose we could define a syntax to allow appending a chain of actions<br class="">after the basic location config.</blockquote><br class=""></div><div class="">Yep, exactly. I was thinking before of a generic ’tag:value’ list for location, but now this new approach seems more sensible. Make it a list of type:actions:param. Something like enter:homelink:1, enter:acc:home, etc. The list goes into class OvmsLocation and can be persisted to config in the normal way.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">I'm still a bit unclear on how much an "ACC profile" could specify.</blockquote><br class=""></div><div class="">The idea is to model a charge profile. For example, at home I might want to do a:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Type: Charge By</li><li class="">Cooldown on plugin</li><li class="">Charge limit: 90% SOC</li><li class="">Charge mode: Standard</li><li class="">Charge current: 32A</li><li class="">Complete charge by 7am</li></ul></div><div class=""><br class=""></div><div class="">Another example:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Type: Charge At</li><li class="">Cooldown: no</li><li class="">Charge limit: 200km</li><li class="">Charge mode: Standard</li><li class="">Charge current: 32A</li><li class="">Start charge at 11pm</li></ul></div><div class=""><br class=""></div><div class="">The ACC profiles are a charge type (on-demand, charge at, charge by, etc) and associated parameters controlling the charge.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">But would users really want to<br class="">access those profiles for a manual charge (not associated with a<br class="">location) as opposed to just giving the charge command(s)?</blockquote><br class=""></div><div class="">I’m thinking something like ‘charge profile home’ to activate that profile for the duration the car is plugged in. But you could get to a restaurant, and type ‘charge profile ontheroad’ to set a profile without having to set all the individual parameters.</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 11 Jan 2019, at 3:55 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,<br class=""><br class="">Along the same lines, when I poked around the web UI it occurred to me<br class="">that it would be a logical (and I think intuitive) extension to the<br class="">location configuation page to allow specifying some actions to be<br class="">associated with a location.<br class=""><br class="">Are you proposing that those actions be stored in the location config?<br class="">That's where I was heading with the ACC feature when I began to wonder<br class="">whether that would be considered inappropriate.<br class=""><br class="">I suppose we could define a syntax to allow appending a chain of actions<br class="">after the basic location config.<br class=""><br class="">I'm still a bit unclear on how much an "ACC profile" could specify.<br class="">In the OVMSv2 ACC command, it was just the combination of a mode<br class="">(standard or range), start time (on plug-in, at a time, or as<br class="">appropriate to end at a particular time), and optionally an ending<br class="">condition (SOC or range) other than what the car's algorithm would<br class="">normally do. I suppose the option to do cooldown on plug-in could<br class="">also be considered part of a profile. But would users really want to<br class="">access those profiles for a manual charge (not associated with a<br class="">location) as opposed to just giving the charge command(s)?<br class=""><br class=""> -- Steve<br class=""><br class="">On Fri, 11 Jan 2019, Mark Webb-Johnson wrote:<br class=""><br class=""><blockquote type="cite" class="">Steve,<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">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).<br class=""><br class="">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:<br class="">On demand<br class="">On plug-in<br class="">On timer<br class="">ACC profile<br class="">etc<br class=""><br class="">Does that solve the problem, and provide a general enough framework?<br class=""><br class="">Regards, Mark.<br class=""><br class=""><blockquote type="cite" class="">On 9 Jan 2019, at 6:55 AM, Stephen Casner <<a href="mailto:casner@acm.org" class="">casner@acm.org</a>> wrote:<br class=""><br class="">Mark,<br class=""><br class="">After reading both of your messages and sleeping on the question, I<br class="">can see that you might object to my idea of extending the location<br class="">config with additional parameters for ACC. I concede that this is not<br class="">a good fit architecturally because it would be a mess to try to add<br class="">other functions tied to geofencing by the same mechanism. As I<br class="">mentioned, my motivation for the idea was a concern about an ACC<br class="">config becoming stranded if it references a location by name and the<br class="">location is then deleted. In OVMSv2 an ACC profile could not exist<br class="">without a location, but now you are suggesting that those profiles<br class="">could be standalone. I suppose that when listing an ACC profile that<br class="">was bound to a location subsequently deleted I can just add a note<br class="">"(deleted)" after the name.<br class=""><br class="">It seemed to me that providing backwards compatibility by implementing<br class="">the OVMSv2 ACC commands would be valuable, perhaps with some<br class="">extensions to the command syntax such as to allow naming the ACC<br class="">profiles. Of course, we don't have the SMS gateway yet so those<br class="">commands could not be used exactly as before. I suppose now the<br class="">preferred interface would be the webserver. That's not my forte;<br class="">perhaps Michael could add that once the infrastructure is in place.<br class=""><br class="">Although homelink is irrelevant to ACC, it might have been possible<br class="">for Timothy to set up his gate and garage door geofencing using the<br class="">ACC command syntax whereas he needed my help for the current method<br class="">that requires creating a script. There should be a command somewhere<br class="">that says "trigger homelink 1 at location foo" that automates the<br class="">creation of the script. But then again, where and how would you go<br class="">about listing such settings? You could have "homelink status" or have<br class="">"location status" list homelink commands that are attached to<br class="">locations, but to implement such a listing would require parsing the<br class="">scripts to determine what homelink operation is configured. If the<br class="">user is allowed to edit the script, then we can't assume that the<br class="">format of the script is the same as when the command created it.<br class=""><br class="">I agree with your suggestion to implement the ACC functions in the<br class="">base vehicle module. Some things like charge time prediction would<br class="">have to come from the vehicle-specific modules. Probably the "charge"<br class="">command should be expanded with something like "at" and "by"<br class="">subcommands.<br class=""><br class=""> -- Steve<br class=""><br class="">On Tue, 8 Jan 2019, Mark Webb-Johnson wrote:<br class=""><br class=""><blockquote type="cite" class="">Re-reading this, I think I may not have been clear. What I mean, at a high-level, is:<br class=""><br class="">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.<br class=""><br class="">Ignore homelink, it is irrelevant to ACC.<br class=""><br class="">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.<br class=""><br class="">I hope that is clearer.<br class=""><br class="">Regards, Mark.<br class=""><br class=""><blockquote type="cite" class="">On 8 Jan 2019, at 1:58 PM, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" class="">mark@webb-johnson.net</a>> wrote:<br class=""><br class="">Steve,<br class=""><br class="">In v2.x, ACC handled:<br class=""><br class="">What is now ‘locations’ in v3; geofenced areas.<br class="">The option to fire a homelink button when entering a geofence.<br class="">The option to perform a cooldown when plugging in.<br class="">The option to charge at plugin, at a specific time, or complete by a specific time.<br class="">The option to limit charging to SOC% or range.<br class=""><br class="">The v2.x ACC was Tesla Roadster specific.<br class=""><br class="">My thoughts:<br class=""><br 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="">Firing a homelink can be done with scripts today, and has nothing to do with ACC anyway.<br class=""><br 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="">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="">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="">ACC then become the language to control these functions, and perhaps something to tie a particular charge profile to a location geofence.<br class=""><br class="">Regards, Mark.<br class=""><br class=""><blockquote type="cite" class="">On 5 Jan 2019, at 3:05 PM, Stephen Casner <<a href="mailto:casner@acm.org" class="">casner@acm.org</a> <<a href="mailto:casner@acm.org" class="">mailto:casner@acm.org</a>>> wrote:<br class=""><br 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> <<a href="mailto:OvmsDev@lists.openvehicles.com" class="">mailto:OvmsDev@lists.openvehicles.com</a>><br class=""><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br class=""></blockquote><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=""></blockquote><br class=""></blockquote>_______________________________________________<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=""></blockquote><br class=""></blockquote>_______________________________________________<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>