[Ovmsdev] test works, what next

Mon Jan 7 22:22:21 HKT 2013

Nikolay,

> 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.

Let's divide into five parts:

Car Module Firmware

The v2 firmware has had a huge amount of work done to try to make it vehicle independent. That is the primary difference between v1 and v2 firmware.

The main thing remaining is a way for the car module to produce net_msg messages with custom types. Maybe we only need one vehicle specific message type?

Virtual Car

This impacts both the car module and apps. The protocol we are using was designed for Tesla Roadsters, and we are trying to make it carry status messages for other cars. This needs work to make it support other cars - and in particular that is going to be hard to make it backwards compatible.

This is also not well documented - which I think is a pre-requisite before changing it.

Protocol

I think this should be fine. The core protocol is vehicle agnostic and just transmits messages bi-directionally. We've recently extended this for historical data (which is good), and perhaps some more data types and conventions need to be added - but the core protocol should be able to support all vehicles.

Server

I also think this should be fine. The server just routes protocol messages, and is vehicle and app agnostic. There is some work planned for this - in particularly regarding HTTP access to vehicle data.

Apps

These will need a lot of work, as you point out. What we have now will work, but not ideal.

Your idea of using vehicle-specific config files to arrange the displays may be possible for information display. We've had a lot of issues with layout (Android specifically, but the iPad vs iPhone was tough), so this may not be so easy. Perhaps a webview would solve it?

At the moment, the Android App is still coming together and until that is done it is really hard to make any changes to the virtual car and apps. We can discuss now, and design the changes, but actual implementation will have to wait until the Android app stabilises.

> 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.

We tried this early on, but it is very very difficult. The primary problem is that the cellular networks often NAT private IPv4 addresses to public. That means you can't call the car module. It is possible to use a P2P broker (a server), but that means sending 1 UDP packet every 25 seconds to keep the NAT alive - and that is a bandwidth hog. The secondary problem is that push notifications require a server anyway.

Regards, Mark.

On 7 Jan, 2013, at 7:44 PM, Nikolay Shishkov <nshishkov at yahoo.com> wrote:

> 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
> 
> 
> _______________________________________________
> 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/6c9da7cd/attachment.htm>