[Ovmsdev] V3 progress

Tom Parker tom at carrott.org
Sun Oct 8 17:40:02 HKT 2017

On 04/10/17 02:30, Mark Webb-Johnson wrote:
> I just added the very basic ones, as a starting point and proof of 
> concept. Hadn’t decided if I needed anything special for the bitmapped 
> ones at the time (either a new MetricBitmap type, or extend 
> MetricInt). Looking at how things have evolved, and bearing in mind 
> the GAPP bluetooth stuff, and OVMS v3 MQTT, it seems that each bit 
> should be a metric of their own. Not too hard for ovms_server_v2 to 
> convert that back to an integer bitmap, for backwards compatibility. 
> To do that, car_doors1 becomes:

I fully support the concept of storing the data in the most appropriate 
format and serializing it into the v2 message in the v2 server code. I 
like the idea of storing the bit field stuff as separate boolean 
objects. I don't know if you can do anything clever with C++ to use less 
memory while preserving a nice API within the vehicle code, but we 
probably have enough memory to not need to worry too much?

> So, if you have time, please go ahead and add the other standard ones 
> that are simple and shared across all cars.

I'll add them as I need them for porting the leaf code. I don't support 
most of the "standard" metrics in the leaf code so it won't be all of them.

>> Is anyone working on the v2 server support code to send the S and D 
>> messages?
> Nope. Not at the moment. I’ve stubbed it.

I've implemented an S message using the TPMS as an example and the few 
metrics that we already have. I found the android client can't cope with 
an empty value, so I had to modify the if undefined return the empty 
string behavior in the AsString implementations in subclasses of 
OvmsMetric. I'm currently "learning" how C++ inheritance works and am in 
a twisty maze of complier errors. I'll explain what I'm doing tomorrow 
and hopefully there is an obvious answer. Once I've sorted that out I'll 
send a pull request (I hacked it by hard coding values that work for a 
v2 android client which presumably breaks other things. What I want to 
do is replace the existing methods with ones that takes an argument to 
return as a default value, and re-implement the existing no-argument 
methods in terms of the new method).

I'm at the point where I can take it for a drive on my phone's wifi hotspot.

More information about the OvmsDev mailing list