[Ovmsdev] test works, what next

[Mark Webb-Johnson]

Nikolay, Michael B,

There are some global parameters that can be easily extended, in a backwards compatible manner. For example, battery temp should be easy to change from byte to int16. I think there will be zero impact on the Apps, as the change can be made in a backwards-compatible manner. It is also easy to test.

There are some global parameters that are harder to change, because it will break the apps, and the apps will thus have to be changed to cope with both old and new formats co-existing. The example there is change of odometers from miles to vehicle-units.

There are some parameters that are vehicle specific, and some that are candidates for 'globalisation' :-) For those, I think it best to just publish to the list what individual cars are offering that are not handled by the existing globals, and we'll extend as necessary. An example of this would be 2 more doors (for 4 door cars). Until that is done, the parameters should be implemented as vehicle-specific and obtained via command calls or historical data.

Interesting discussion, and glad we're having it.

Regards, Mark.

On 7 Jan, 2013, at 3:41 PM, Michael Balzer wrote:

> Nikolay,
> 
> OK, a bit more detail :-)
> 
> 
> Am 07.01.2013 08:05, schrieb Nikolay Shishkov:
>> In the simplest form I would like to have at least SOC, Temperature, Pack voltage, Pack current, a some kind of text or bit map for state (like charged, charging enabled, plugged, waiting temp) there are some more states, some additional parameters like PWM signal for charge power, and eventual errors and warnings - there is a warning "please charge to full soon" for example. These can also be bits or text.
> 
> Use the standard "STAT" message (overloaded) for charge state notifies.
> 
> Send other text messages by SMS or by "MP-0 PA...". See Twizy notification system on how to do this.
> 
> 
>> What "car_" variables I should use for the pack voltage and pack current?
> None, those currently are no common properties.
> 
>> What "car_" variables I should use for statuses that are not available as a car_variables?
> None, use vehicle specific variables until at least Mark agrees on adding them to the common set.
> 
>> Also the nominal pack temperatures (for the zebra battery) are around 270C (two hundred and seventy Celsius) - any idea if this would be a problem with the current setup?
> That's a definite yes, as the temperature vars are currently bytes. That also may need to be changed in the common variables. Until then, you could do a workaround by re-basing your App readings at e.g. 200 °C, so 270 can be displayed as 70.
> 
>> Eventhough the Tesla and Think are both EVs, they have some significant differences in technology and thus significant differences at what drivers would be interested in seeing.
>> 
>> So should I define my own handling and "think_" parameters, or should I add more "car_" ones?
> Add them as "think" vars first, upload your code, then post a suggestion what to include into the common set, so we can discuss it.
> 
> The common set of properties can be extended and refined, but there basically needs to be vehicle specific support in the Apps anyway, and that in turn could eliminate the need for most extensions to the common set. IMO the common set should cover just the basic functions that can be supported by most vehicles. It currently already contains more properties than really are common (from the Twizy point of view), so the App already will need at least some vehicle feature support matrix.
> 
> Regards,
> Michael
> 
> -- 
> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
> 
> <dexter.vcf>_______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev