[Ovmsdev] Advanced Charge Control (ACC)

Bennett Leeds bennettleeds at gmail.com
Sun Jun 2 12:22:59 HKT 2013


This is really exciting. I would request that the Charge Timer should be
based on Time Of Use periods, in order to automatically have the lowest
charging costs while still having a full vehicle when you need it.

Here in the states, many EV owners are on time of use meters. The cheapest
period times very not only by day of the week, but also by season. I'd like
to be able  "teach" the car what the TOU periods are, tell it what time I
leave each morning, and then have the car figure out the cheapest way to
get me a full charge by the time I need it given the upcoming TOU periods
between plug-in and when I need to leave.

The TOU periods could be specified in 3 levels per weekday and 3 levels per
weekend. With 2 seasons, that would be 12 fields to be entered. Time Needed
could be specified per weekday and per weekend - so 14 time fields total
for this to work.

The logic is pretty straightforward. When the car is off and plugged in,
look to see when the full charge is needed by. Either know the amperage
available, or use the cooldown to get a pilot signal. Obey any lower
current limits set by owners (which might be done due to old breakers,
etc.). Then figure out if the cheapest time period is long enough to fully
charge the car. If not, then do just enough charging in the second cheapest
time period to result is a full charge, and if that won't be enough, then
do just enough charging in the most expensive time period to result in a
full charge after the upcoming second cheapest and most cheapest periods.

I'd be happy to be a tester for whatever you come up with.

thanks
- Bennett





On Sat, Jun 1, 2013 at 9:00 PM, <ovmsdev-request at lists.teslaclub.hk> wrote:

> Send OvmsDev mailing list submissions to
>         ovmsdev at lists.teslaclub.hk
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> or, via email, send a message with subject or body 'help' to
>         ovmsdev-request at lists.teslaclub.hk
>
> You can reach the person managing the list at
>         ovmsdev-owner at lists.teslaclub.hk
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OvmsDev digest..."
>
>
> Today's Topics:
>
>    1. Re: Advanced Charge Control (ACC) (Tom Saxton)
>    2. Re: Advanced Charge Control (ACC) (Mark Webb-Johnson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 01 Jun 2013 12:02:41 -0700
> From: Tom Saxton <tom at idleloop.com>
> Subject: Re: [Ovmsdev] Advanced Charge Control (ACC)
> To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
> Message-ID: <CDCF9361.804A3%tom at idleloop.com>
> Content-Type: text/plain;       charset="US-ASCII"
>
> Mark,
>
> This all sounds great. It covers everything I want, and more. Personally, I
> think three zones is plenty if you want to save some parameter space.
>
>     Tom
>
> on 5/31/13 6:56 AM, Mark Webb-Johnson wrote:
>
> > I've spent some time planning this, and now have the time to try to get
> it
> > done. The observant will have noticed a new branch ACC just appeared in
> the
> > github repository.
> >
> > This is primarily for Tesla Roadster owners, but once we work out how to
> do
> > charge control in other cars, it will have use for them.
> >
> > The premise of what I'm thinking is a replacement for the limited charge
> > control in the car, to make an Advanced Charge Control:
> >
> > We have the concept of a 'charge location'. This is an area (square,
> because
> > it is easiest) around a GPS location. An area of 200m x 200m, centred on
> the
> > charge location, should be sufficient for gps inaccuracies. Up to 5 such
> > charge locations can be defined (I'm thinking home, work, and one other).
> > Once the car enters a charge location, an action can be triggered. At the
> > moment, I'm only thinking of automatic home link activation, but others
> are
> > possible.
> > When a car is turned off, while in a charge location, acc is enabled and
> > current charge settings are saved.
> > When a car is turned on, while in a charge location, acc is disabled and
> > previous charge settings are restored.
> > Features that acc should support include:
> > Homelink activation.
> > Cooldown (cool the car using a sequence of low amperage range mode
> charges) -
> > this would need a minimum temperature (don't cool down unless ESS
> temperature
> > is above this), a desired temperature (cool down until the ESS reaches
> this
> > temperature),and a time limit (stop cooling down if we've been trying
> for too
> > long).
> > Charge mode (standard, storage, range, performance).
> > Charge current limit.
> > Various charge types, including:
> > Charge on plug-in
> > Start charge at specific time
> > Complete charge by specific time
> > Desired charge limit (SOC%, ideal miles/kilometers, or full)
> > In addition to the charge locations, acc should be able to be turned on,
> > one-off, for the current location. This should be done after the car is
> turned
> > off, before plugging in. It will be effective until the car is turned on
> > again.
> > It should also be possible to use this one-off acc to override the charge
> > control for the current location. This will be effective until the car is
> > turned on again.
> > Control, and status, is possible by SMS commands.
> > Control is also possible by a new tab added to the apps. I'm going to do
> > iPhone first, with the existing charge control moved to a new "Charge"
> tab.
> >
> > I'm not sure how to do the 'specific time'. This could be
> > simple-to-ludicrously-complex. My inclination is to just put a
> day-of-week
> > filter on each charge location - with acc only being enabled if the day
> > matches. More than one location could be created for each physical gps
> > location, with different day matches, to control how that would behave.
> >
> > Changes to be made include:
> >
> > Move the roadster digital speedo experimental feature to a fully
> supported
> > features, and give it a permanent feature storage number.
> > Assign five new permanent parameters, one each for five charge locations
> > (home, work, other, or whatever they want to be known as - we just call
> them
> > #1, #2, #3, #4 and #5).
> > The parameter storage for these new locations includes the charging
> > preferences for each location.
> > We would also need a parameter for time zone.
> > Add a new module called "acc".
> > If "acc" detects we are at a known charge location, it will take over the
> > charge control from the car.
> > The "acc" will also support commands for the current location, and will
> be
> > able to take over charge control from now until the car is next driven.
> >
> > Please let me have your comments / suggestions. I'll handle the coding,
> but
> > I'll need lots of help testing.
> >
> > Regards, Mark.
> >
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.teslaclub.hk
> > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 2 Jun 2013 09:29:37 +0800
> From: Mark Webb-Johnson <mark at webb-johnson.net>
> Subject: Re: [Ovmsdev] Advanced Charge Control (ACC)
> To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
> Message-ID: <AF3A64D7-E806-4CF3-94A8-360D170626C4 at webb-johnson.net>
> Content-Type: text/plain;       charset=us-ascii
>
> Tom,
>
> My original design was 3 (home, work, other). I increased to 5 to allow
> for different schedules weekday / weekend, etc.
>
> Lets see how it works out. More would be good.
>
> Regards, Mark
>
> On 2 Jun, 2013, at 3:02 AM, Tom Saxton <tom at idleloop.com> wrote:
>
> > Mark,
> >
> > This all sounds great. It covers everything I want, and more.
> Personally, I
> > think three zones is plenty if you want to save some parameter space.
> >
> >    Tom
> >
> > on 5/31/13 6:56 AM, Mark Webb-Johnson wrote:
> >
> >> I've spent some time planning this, and now have the time to try to get
> it
> >> done. The observant will have noticed a new branch ACC just appeared in
> the
> >> github repository.
> >>
> >> This is primarily for Tesla Roadster owners, but once we work out how
> to do
> >> charge control in other cars, it will have use for them.
> >>
> >> The premise of what I'm thinking is a replacement for the limited charge
> >> control in the car, to make an Advanced Charge Control:
> >>
> >> We have the concept of a 'charge location'. This is an area (square,
> because
> >> it is easiest) around a GPS location. An area of 200m x 200m, centred
> on the
> >> charge location, should be sufficient for gps inaccuracies. Up to 5 such
> >> charge locations can be defined (I'm thinking home, work, and one
> other).
> >> Once the car enters a charge location, an action can be triggered. At
> the
> >> moment, I'm only thinking of automatic home link activation, but others
> are
> >> possible.
> >> When a car is turned off, while in a charge location, acc is enabled and
> >> current charge settings are saved.
> >> When a car is turned on, while in a charge location, acc is disabled and
> >> previous charge settings are restored.
> >> Features that acc should support include:
> >> Homelink activation.
> >> Cooldown (cool the car using a sequence of low amperage range mode
> charges) -
> >> this would need a minimum temperature (don't cool down unless ESS
> temperature
> >> is above this), a desired temperature (cool down until the ESS reaches
> this
> >> temperature),and a time limit (stop cooling down if we've been trying
> for too
> >> long).
> >> Charge mode (standard, storage, range, performance).
> >> Charge current limit.
> >> Various charge types, including:
> >> Charge on plug-in
> >> Start charge at specific time
> >> Complete charge by specific time
> >> Desired charge limit (SOC%, ideal miles/kilometers, or full)
> >> In addition to the charge locations, acc should be able to be turned on,
> >> one-off, for the current location. This should be done after the car is
> turned
> >> off, before plugging in. It will be effective until the car is turned on
> >> again.
> >> It should also be possible to use this one-off acc to override the
> charge
> >> control for the current location. This will be effective until the car
> is
> >> turned on again.
> >> Control, and status, is possible by SMS commands.
> >> Control is also possible by a new tab added to the apps. I'm going to do
> >> iPhone first, with the existing charge control moved to a new "Charge"
> tab.
> >>
> >> I'm not sure how to do the 'specific time'. This could be
> >> simple-to-ludicrously-complex. My inclination is to just put a
> day-of-week
> >> filter on each charge location - with acc only being enabled if the day
> >> matches. More than one location could be created for each physical gps
> >> location, with different day matches, to control how that would behave.
> >>
> >> Changes to be made include:
> >>
> >> Move the roadster digital speedo experimental feature to a fully
> supported
> >> features, and give it a permanent feature storage number.
> >> Assign five new permanent parameters, one each for five charge locations
> >> (home, work, other, or whatever they want to be known as - we just call
> them
> >> #1, #2, #3, #4 and #5).
> >> The parameter storage for these new locations includes the charging
> >> preferences for each location.
> >> We would also need a parameter for time zone.
> >> Add a new module called "acc".
> >> If "acc" detects we are at a known charge location, it will take over
> the
> >> charge control from the car.
> >> The "acc" will also support commands for the current location, and will
> be
> >> able to take over charge control from now until the car is next driven.
> >>
> >> Please let me have your comments / suggestions. I'll handle the coding,
> but
> >> I'll need lots of help testing.
> >>
> >> Regards, Mark.
> >>
> >> _______________________________________________
> >> OvmsDev mailing list
> >> OvmsDev at lists.teslaclub.hk
> >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> >
> >
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.teslaclub.hk
> > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
> ------------------------------
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
> End of OvmsDev Digest, Vol 17, Issue 5
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130601/79d53590/attachment.htm>


More information about the OvmsDev mailing list