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

Mark Webb-Johnson mark at webb-johnson.net
Sat Feb 25 22:51:34 HKT 2012

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.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20120225/12f6ad83/attachment.htm>

More information about the OvmsDev mailing list