[Ovmsdev] V3 distance/speed units

Michael Balzer dexter at expeedo.de
Wed Oct 25 04:08:52 HKT 2017


I've done the int to float changes and the temperature naming.

Not sure about the best way to solve the units problem yet, but I guess
we can start with storing in vehicle units and add the conversion later on.

Regards,
Michael


Am 24.10.2017 um 04:46 schrieb Mark Webb-Johnson:
> Tough questions. Answers/comments inline.
>
>> On 23 Oct 2017, at 9:33 PM, Michael Balzer <dexter at expeedo.de> wrote:
>>
>> Trying to catch up…
>>
>>
>> a) I'd love to get rid of those km→miles→km conversions in V3.
>>
>> How about introducing a metric "v.units" instead to hold the units used
>> by the vehicle, and make conversions at the user level if necessary?
> I don’t have a good answer for this. I thought to just store all the metrics in ‘metric’ (celcius, kilometers, etc), and let the apps deal with it (as they do now). But, as you say, that does lead to the problem of km->miles->km, etc.
>
> An alternative is to store a ‘units’ with the metric, and have the metric deal with presentation conversion upon retrieval. That reduces the number of conversions.
>
> In general, having this done in the module seems to make more sense than doing it in the apps.
>
>> b) Regarding the standard metrics currently defined, I'd need to
>> introduce own copies again for higher precision. I.e. SOC, SOH, speed
>> and ranges all are integers now, and some more I'd like to be able to
>> set at higher precision.
>>
>> How about making all these be floats now? I.e. everything that can
>> require more than integer precision.
>>
>> The server_v2 can output the values as integers for v2 client compatibility.
> OK.
>
>> c) I haven't seen a recommendation on naming vehicle specific metrics.
>> My proposal: use the vehicle code as the prefix, then try to reuse
>> similar paths from the standard metrics, adding detail as necessary.
>>
>> For example, the vehicle module version on the Twizy ("RT") is
>> "rt.m.version", and for the min & max battery voltage I've got
>> "rt.v.b.voltage.min" & "rt.v.b.voltage.max".
>>
>> OVMS > metrics list rt.
>> rt.m.version                   1.0.0 Oct 23 2017 11:45:31
>> rt.v.b.soc                    
>> rt.v.b.temp.m1                
>> rt.v.b.temp.m2                
>> rt.v.b.temp.m3                
>> rt.v.b.temp.m4                
>> rt.v.b.temp.m5                
>> rt.v.b.temp.m6                
>> rt.v.b.temp.m7                
>> rt.v.b.voltage.max             0
>> rt.v.b.voltage.min             0
>>
>> That way a path component can be used to list all related metrics:
>>
>> OVMS > metrics list b.voltage
>> rt.v.b.voltage.max             0
>> rt.v.b.voltage.min             0
>> v.b.voltage                   
> Ok, but I would suggest an ‘x.’ prefix (seems to match many Internet standards, such as X- headers, etc).
>
> So: x.rt.v.b.voltage.max, etc.
>
>> d) I think most of the temperature metrics have wrong names:
>>
>> v.b.temp.ambient              
>> v.b.temp.battery              
>> v.b.temp.charger              
>> v.b.temp.motor                
>> v.b.temp.pem                  
>>
>> …as "b." should be reserved for "battery".
>>
>> How about…
>>
>> v.e.temp
>> v.b.temp
>> v.c.temp
>> v.m.temp
>> v.i.temp
>>
>> …introducing "m." for motor and "i." for inverter?
> OK.
>
>> Regards,
>> Michael
>>
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26




More information about the OvmsDev mailing list