[Ovmsdev] Strange preparing, connect-pwr-cable state

[Jack West]

I agree.  Losing the last charge data will not be that big a deal.  Under normal circumstances when you unplug and close the charge port door you are at the car and can look at the VDS charge history right?  Only if someone is messing with your car and you want to check remotely might this be a issue.  I say carry on with the fix to SMS STAT.

Jack

On Feb 26, 2012, at 1:21 AM, Sonny <email at sonnychen.com> wrote:

> Mark,
> 
> Great find.
> 
> I like the determine-by-charge-port-status method. Coincidentally, the Android app has already been doing it that way.
> 
> Best regards,
> 
> Sonny
> 
> On Feb 25, 2012 10:51 PM, "Mark Webb-Johnson" <mark at webb-johnson.net> wrote:
> 
> I think I now understand what is happening.
> 
> The 0x95 message is the charge status for the current charge. For a normal charge in progress, that is fine. When the charge completes, the charge door is closed, and we are still ok. We still show the last charge status.
> 
> Now, the opening of the charge door signals the car to start a new charge, and the old data is lost. Hence 'preparing to charge'. Even closing the charge door leaves the charge status as 'preparing to charge'. That was the last charge status.
> 
> For the SMS STAT command, I think we're going to have to deal with this by if the car charge port is closed, then not showing any charge in progress (as opposed to the last charge status that we currently show).
> 
> From the App point of view, if the charge port door is closed, then we also won't show any current charge status
> 
> What we lose here is the status of the last charge, once the charge port is closed. But, perhaps that is the best way of doing things.
> 
> Thoughts?
> 
> Regards, Mark.
> 
> On 25 Feb, 2012, at 11:51 AM, Mark Webb-Johnson wrote:
> 
>> 
>> I'm seeing something strange, that I'd like to know if it is repeatable for others. I previously thought this was some sequence problem with the messages we were sending (specifically, sending a start charge command when the charge port is closed or cable not plugged in), but I can now repeat it with just a normal idle car.
>> 
>> Steps to reproduce:
>> 
>> Charge the car as normal, and wait for "Charge done".
>> Remove the charge plug+cable and close the charge port door.
>> SMS STAT the car and you should get "Standard - Charging done" as the status. All good.
>> Now, with the car still off, open the charge port door, wait a few seconds, then close it.
>> SMS STAT the car and now we seem to get "Standard - Charging, Preparing". A check on the can bus shows charge state 13, sub-state 7 (preparing-to-charge, connect-pwr-cable). The iPhone App will show the battery with copper-coloured tops, as it seems to be expecting the car to be charging.
>> 
>> This doesn't seem to happen with a car in 'stopped charge' state. The VDS shows nothing unusual (which implies that Tesla treat it specially, based on the charge door status).
>> 
>> Can some other people try this, and let me know what you get? If you can have an App connected at the time of your test (so the server gets the logs), then let me know your vehicle ID, the time you did the test and what the result was, that would be helpful.
>> 
>> It is not hard to handle as a special case in the code (both firmware and apps, or hacked in the firmware to detect the issue and put the state back to something more meaningful), but just seems a bit strange, as the state does not accurately reflect the car status.
>> 
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20120226/cc7d5490/attachment.htm>