[Ovmsdev] 1.2.0-rc5 Notification charging/done

[Jack West]

If I'm understanding what your saying:
Looking at can.c

case 0x95:
    if((car_chargestate < 0x15) &&     // old state was not stopped (including "done")
       (can_databuffer[1] >= 0x15) &&. // new state is stopped
       (can_databuffer[2] != 0x03)).      // not by request

This causes changes from done to stopped to be reported.  Then the next message comes through and changes back to done before the report is completed

Maybe we should remove "done" from the first test?  In other words, don't report changes from done to stopped.

if (((car_chargestate < 0x15) &&(car_chargestate != 0x04)) && // old state not stopped or done
     (can_databuffer[1].....

Jack


On Feb 22, 2012, at 3:29 AM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:

> 
> Guys,
> 
> I just got these notifications this afternoon:
> 
> 2012-02-22 16:25:30.157145 +0800 info  main: #9 C EV915 rx msg P AStandard - Charging Done^MIdeal Range: 298 Km SOC: 96%
> 2012-02-22 16:25:48.572604 +0800 info  main: #9 C EV915 rx msg P AStandard - Charging Done^MIdeal Range: 298 Km SOC: 96%
> 2012-02-22 16:26:02.984595 +0800 info  main: #9 C EV915 rx msg P AStandard - Charging Done^MIdeal Range: 298 Km SOC: 96%
> 2012-02-22 16:26:12.055064 +0800 info  main: #9 C EV915 rx msg P AStandard - Charging Done^MIdeal Range: 298 Km SOC: 96%
> 2012-02-22 16:26:48.951721 +0800 info  main: #9 C EV915 rx msg P AStandard - Charging Done^MIdeal Range: 298 Km SOC: 96%
> 
> Not good.
> 
> The only way that is happening is if the charge state of the car is flipping between done and stopped. The problem is that the reported states around the time of the problem are:
> 
> 2012-02-22 16:15:03.765201 +0800 info  main: #9 C EV915 rx msg S 96,K,-1,127,done,standard,298,262,70,65535,100,3,9,4,0
> 2012-02-22 16:25:02.540923 +0800 info  main: #9 C EV915 rx msg S 96,K,-1,127,done,standard,298,262,70,65535,100,3,9,4,0
> 2012-02-22 16:35:09.175980 +0800 info  main: #9 C EV915 rx msg S 96,K,-1,127,done,standard,298,262,70,65535,100,3,9,4,0
> 2012-02-22 16:45:30.941930 +0800 info  main: #9 C EV915 rx msg S 96,K,-1,127,done,standard,298,262,70,65535,100,3,9,4,0
> 
> And, as the notification said 'Charging done', it is clear that between the alert being requested and raised (a split second), the charge state flipped from stopped to done.
> 
> The car has been sitting idle for a couple of days, without being driven, but has been plugged in continuously during this time.
> 
> I'm guessing that sometimes we get spurious messages on the can bus, perhaps when the car wakes up once a day to check its charge state, and that is causing the problem.
> 
> I looked through the logs for the past few days, for any similar alerts from other users, but can't find any. I did have one report of a user getting three or four sms messages in a row, a month or so ago, but suspected at the time the charging point was having problems and restarting the charging.
> 
> I don't think this is easy to solve. Trying to catch with a can log is going to be next to impossible.
> 
> One workaround I can think of is in net.c in the handling of net_msg_notify and net_sms_notify - add checks there that (((car_chargestate >= 0x15) || (car_chargestate == 0x0d))&&(car_chargesubstate != 0x03)) - in other words the conditions that we should be alerting on. This would have the affect of filtering out these spurious alerts.
> 
> Thoughts?
> 
> Mark.
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20120222/3a99b870/attachment.htm>