Implementing advanced charge control
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
Steve, Is there a way to secure the Homelink activation to be more than just location? It's been a while, but I just got another "possible flatbed" message earlier this month, which makes me wonder if the car's nocturnal wanderings might inadvertently trigger the garage door to open as a side effect. Security-wise, that would be bad. Greg Stephen Casner wrote:
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 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Greg, Before I implemented the Homelink activation within the location command I set up the automatic garage door opening function for a friend using a one-line script to execute the homelink command that was triggered by the location.enter event notification. Indeed there were a few instances of nocturnal garage door opening that were avoided by increasing the location radius. But your message prompts me to remember that there's an enhancement I should make in my code: the Homelink should only be triggered if the car is ON. -- Steve On Mon, 25 Jan 2021, Greg D. wrote:
Steve,
Is there a way to secure the Homelink activation to be more than just location?
It's been a while, but I just got another "possible flatbed" message earlier this month, which makes me wonder if the car's nocturnal wanderings might inadvertently trigger the garage door to open as a side effect. Security-wise, that would be bad.
Greg
Hi Steve, Gating Homelink with On would certainly solve the problem. Good thought. I've found it handy when I'm out in the yard to use the OVMS app on my cell phone as a garage door opener, telling the car to trigger Homelink. Would that still work, i.e. have the Location-based trigger be gated, but not the app? On the other hand, with the publicity of IOT hacks to electronic locks, perhaps the security of the app may not be sufficient as a remote house key. Should there be a security config flag or PIN? Greg Stephen Casner wrote:
Greg,
Before I implemented the Homelink activation within the location command I set up the automatic garage door opening function for a friend using a one-line script to execute the homelink command that was triggered by the location.enter event notification. Indeed there were a few instances of nocturnal garage door opening that were avoided by increasing the location radius.
But your message prompts me to remember that there's an enhancement I should make in my code: the Homelink should only be triggered if the car is ON.
-- Steve
On Tue, 26 Jan 2021, Greg D. wrote:
I've found it handy when I'm out in the yard to use the OVMS app on my cell phone as a garage door opener, telling the car to trigger Homelink. Would that still work, i.e. have the Location-based trigger be gated, but not the app?
Yes, the code for the location based trigger is separate from the "homelink" command and the request from the app.
On the other hand, with the publicity of IOT hacks to electronic locks, perhaps the security of the app may not be sufficient as a remote house key. Should there be a security config flag or PIN?
Good point. -- Steve
OK, here's a more specific question. To implement 'charge at <time>' I need to store the pending charge operation somewhere so that it can be examined on a ticker to see if the scheduled time has arrived. I presume the appropriate place is within the OvmsVehicle. Would that be considered in conflict with any of the state stored there now? Any specific recommendations for where it should go or what form it should take? Some vehicles have a charge timer function built in, and some allow OVMS to set that timer. So you might say that for those vehicles the 'charge at <time>' function should just set that timer. However, that timer is often a persistent setting in the vehicle, so taking it for a one-time charge event may be inappropriate. Mark also expressed a concern that for the Tesla Roadster setting the timer causes the flash in the VMS to be updated, so flash wear could be a concern. -- Steve On Sun, 24 Jan 2021, Stephen Casner wrote:
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
Steve, just a note on the ACC capabilities: the system should also support SOC and 12V level guards, i.e. start the charge when the SOC or 12V level drops below a configured threshold while parked at a charging location. In addition to that, it should be possible to set custom commands/scripts for starting and stopping the charge process depending on the location, to support controlling smart plugs or home automation systems. Regards, Michael Am 25.01.21 um 08:45 schrieb Stephen Casner:
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 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On Thu, 28 Jan 2021, Michael Balzer wrote:
just a note on the ACC capabilities: the system should also support SOC and 12V level guards, i.e. start the charge when the SOC or 12V level drops below a configured threshold while parked at a charging location.
This is an interesting concept we haven't talked about before. There could be booleans in the profile to enable those two guard conditions. I think these should also depend upon a time element, say that the the car has been connected to the charger for several hours in addition to the SOC or 12V level trigger being hit. That is because I might come home and plug in with a low state of change but not want charging to start yet because I want to to finish at a specfied time.
In addition to that, it should be possible to set custom commands/scripts for starting and stopping the charge process depending on the location, to support controlling smart plugs or home automation systems.
The profile could have members to hold the names of scripts for charge start and charge stop if set. -- Steve
participants (3)
-
Greg D. -
Michael Balzer -
Stephen Casner