If the cars have some messages in common, then best to use one module for both and switch the vehicle type either specifically in config (carbits) or dynamically at runtime (by looking at the messages). That is the way we handled the differences between v1 and v2 Tesla Roadsters. For the roadster, we looked at the VIN message, and automatically switch v1 or v2 support based on the vehicle type identified by the VIN.

In that case, I think vehicle_thinkcity.* is fine, but vehicle id TCMS and TCEL would differentiate the two. The vehicle module identified can simply be "TC". The vehicle type is a variable in memory, and purely informative.

Let's try it that way to start, but if the modules really differ too much then we can split later. Perhaps start with just one variant?

Regards, Mark.

On 28 Dec, 2012, at 9:57 AM, Nikolay Shishkov wrote:

Thanks Mark, 

I may need two stubs - one for the model with Zebra (molten salt) batteries, and the other one for the enerdel li-ion batteries.
They have different battery systems with different can bus messages, and I think it may be easier to have the code separate?
Most of the other systems are the same...so some kind of inheritance or common stub maybe more appropriate?

Nikolay

From: Mark Webb-Johnson <mark@webb-johnson.net>
To: OVMS Developers <ovmsdev@lists.teslaclub.hk>
Sent: Friday, December 28, 2012 1:47 AM
Subject: [Ovmsdev] Think City EV


Nikolay,

I'll create the stub vehicle code for Think City EV for you.

We'll need a vehicle name and ID. I suggest:

Module: vehicle_thinkcity.*
ID: TCEV

Is that ok? If so, I'll create it today.

Regards, Mark.


_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev


_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev