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? 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. 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 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? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26