[Ovmsdev] 1.2.0-rc5 Notification charging/done

[Mark Webb-Johnson]

Jack,

The issue is that the SMS/PUSH notification is sent up to a second (or maybe much later if the network is not currently connected) later.

I did find another possible code path that causes these alerts to be raised - if someone telephones the module! This was an old "feature" in there to save on SMS charges - you could just telephone the module (the module would hangup the call on the first ring, so there would be no charge) to get a status SMS message. It is possible that 'someone' telephoned my module by mistake (and tried several times as all they got was a hangup). Doh!

Anyway, I disabled the 'telephone the module' feature, and added the safety code to the firmware, as it does no harm, and made 1.2.0-rc6. It is in my car now.

Regards, Mark.

On 23 Feb, 2012, at 3:55 AM, Jack West wrote:

> 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/20120223/f34b6622/attachment.htm>