[Ovmsdev] test works, what next

Mon Jan 7 19:44:49 HKT 2013

Ok, I get the current situation and will go ahead with stat command override. I will also look at "command calls" and "historical data". I remember reading some discussion on the list regarding this with the Twizy. 

Having a working app for the Think is going to be a big +, and I can probably help with that too.

In general this may be a good time (having twizy, ampera and think) to reevaluate the architecture and implement changes so new features/parameters/cars could seamlessly be integrated in the ovms/server/app ecosystem.
I would imagine that the sooner the better.

On the app side the interface may be abstracted in a such a way that each info screen of the app can be composed of background (the car or system illustration) and a list of parameters with their locations on the screen. Each parameter may have associated rendering UI component. There could be dial rendering component, thermometer rendering component, simple number and unit in a box component, etc. 
This all can be done in xml or json, and then the app can be generic - pulling up new backgrounds, and parameter lists on startup. This would allow to extend the apps with new vehicles or new parameters without changing anything in the code or redeploying on the google play /apple appstore. Also would allow for "pushing" new visuals, and revisions in parameter descriptions.

Maybe something similar can workout on the server side - if it is not working like that already.

On a second thought - would it possible (or make sense) to have a direct connection between the app and the car? So the server would in a sense run on the mobile platform, and there could be an UI on top. Far more complex though and some limitations like uptime, historical data, etc.

Regards,
Nikolay

________________________________
 From: Mark Webb-Johnson <mark at webb-johnson.net>
To: OVMS Developers <ovmsdev at lists.teslaclub.hk> 
Sent: Monday, January 7, 2013 8:56 AM
Subject: Re: [Ovmsdev] test works, what next

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

_______________________________________________
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/20130107/78b5dfed/attachment.htm>