[Ovmsdev] CHARGEBY / CHARGEAT timing

Wiro Zijlmans wirozijlmans at gmail.com
Fri Oct 18 14:21:38 HKT 2013


Mark,
I use the chargeat option as offered by the car itself mostly for starting the charge at a time that the electricity rate is lower which is typically around 9 pm. To support this a threshold of several hours would be useful. The build in software also uses a threshold which is at least 4 hours. Have never noticed to have gone beyond this threshold so do not know what it is. Can try it.

Groet / Regards
Wiro Zijlmans

> Op 18 okt. 2013 om 03:00 heeft Mark Webb-Johnson <mark at webb-johnson.net> het volgende geschreven:
> 
> 
> I'm seeking people's opinions for the ACC CHARGEBY / CHARGEAT timing behaviour.
> 
> The problem I have is to decide what algorithm to use for the case that people plugin after the scheduled charge time (or in the case of CHARGEBY, plugging in with a charge predicted to take to long to complete by the scheduled charge time).
> 
> For example, say I have CHARGEAT set to 19:00:00. I get home, and plugin, at 19:10:00. What should we do? Schedule the charge for 19:00:00 the next day, or charge immediately? The logical choice seems to be charge immediately, but how far do we allow that 'nice' behavior to go? 19:10:00? 20:00:00? 23:00:00? etc?
> 
> I guess we need some threshold, but what do people think is a sensible value for that threshold?
> 
> For CHARGEBY, it is slightly more complicated. Say I plugin at 18:00:00, with a CHARGEBY of 21:00:00, but the prediction says 4 hours is required? What to do? What if, for the same case, I plugin at 22:00:00?
> 
> The current algorithm in ACC does not allow any safety threshold. If CHARGEAT is 19:00:00 and you plugin at 19:01:00, tough luck - the charge will start at 19:00:00 tomorrow. For CHARGEBY, we do check if there is enough time to complete the charge before the scheduled time in the same day - if not, we send a charge alert message and start charging immediately.
> 
> What do people think? Remember that this is a small embedded processor without much ram/flash, so we need to keep things simple.
> 
> Regards, Mark.
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev



More information about the OvmsDev mailing list