[Ovmsdev] New Metric Units
Michael Geddes
frog at bunyip.wheelycreek.net
Tue Nov 8 20:46:36 HKT 2022
Ah yes. Arrays - will check those. Yeah, how about we add a 'IsDefined'
method to metrics instead of the null thing (it does sound like it will
upset too many applecarts).
//.
On Tue, 8 Nov 2022 at 20:35, Michael Balzer <dexter at expeedo.de> wrote:
> Michael,
>
> looks all good to me, once again nice find with the decode argument.
> Adding decode to the Value() call was only for symmetry IIRC, the main use
> was with GetValues() (
> https://docs.openvehicles.com/en/latest/userguide/scripting.html#ovmsmetrics
> ).
>
> Don't forget to test arrays, e.g. "v.t.pressure" & "v.t.temp".
>
> Returning null for an undefined metric seems like a natural choice, but is
> a rather deep change, as for consistency not only the Duktape metrics API
> but also the Web UI metrics API would need to be changed accordingly.
> Unless you've got a real use case that needs that, we should be careful.
>
> Regards,
> Michael
>
>
> Am 07.11.22 um 15:00 schrieb Michael Geddes:
>
> I have figured out a bunch of stuff and have implemented the following:
> (having done away with needing AsFloatUnit)
>
> OvmsMetrics.Value( {metric} [, {decode}])
> OvmsMetrics.Value( {metric}, {unit} [,{decode}])
>
> It turns out that the [decode] flag wasn't working anyway (since the
> function was being registered as only having 1 param)...
> This way it is still really 1 function.. but I check it the second
> parameter is a 'boolean', and if not.. try the second form.
>
> OvmsMetrics.AsFloat( {metric} [,{unit}] )
>
> and add the function
>
> Ovms.Metrics.ValueUnit( {metric} [,{unit}])
> This prints the value and the unit.
>
> Here's a sample function and the output! This also shows the types of the
> output.
>
> (function() {
> x = OvmsMetrics.Value("xiq.v.trip.consumption");
> print( (typeof x) + ": "+ x+"\n" );
> x = OvmsMetrics.Value("xiq.v.trip.consumption", false);
> print( (typeof x) + ": "+ x +"\n" );
> x = OvmsMetrics.Value("xiq.v.trip.consumption","kmpkwh")
> print( (typeof x) + ": "+ x +"\n");
> x = OvmsMetrics.Value("xiq.v.trip.consumption", "mipkwh", false)
> print( (typeof x) + ": "+ x +"\n");
> x = OvmsMetrics.ValueUnit("xiq.v.trip.consumption")
> print( (typeof x) + ": "+ x +"\n");
> x = OvmsMetrics.ValueUnit("xiq.v.trip.consumption","mipkwh")
> print( (typeof x) + ": "+ x +"\n");
> x = OvmsMetrics.AsFloat("xiq.v.trip.consumption")
> print( (typeof x) + ": "+ x +"\n");
> x = OvmsMetrics.AsFloat("xiq.v.trip.consumption","kmpkwh")
> print( (typeof x) + ": "+ x +"\n");
> })();
>
> number: 17.0582
> string: 17.0582
> number: 5.86227
> string: 3.64264
> string: 17.0582kWh/100km
> string: 3.64264mi/kWh
> number: 17.0582
> number: 5.86227
>
>
>
> It still might be an idea to use 'null' as a return value if the metrics is
> !IsDefined() but that would be changing the existing behaviour slightly.
>
> //.ichael
>
> On Mon, 7 Nov 2022 at 08:12, Michael Geddes <frog at bunyip.wheelycreek.net>
> wrote:
>
>> I've worked out what the decode flag is for and how it works, and I think
>> how optional params work.
>> I'm pretty sure I won't need the 'AsFloatUnit' function; the unit would
>> be an option to AsFloat(); I'll know that soon.
>>
>> The 'Value' function is more complicated because of the optional decode
>> bool. I guess I could add the Unit to the end of that.
>>
>> ValueUnit could be still useful then to provide a 'Value + Unit'.
>>
>> Question: Is there a reason we shouldn't be returning with
>> duk_push_null if the metric !IsDefined() in both AsFloat() and
>> Value(metric,true) cases?
>>
>> //.ichael
>>
>> On Sun, 6 Nov 2022 at 11:22, Michael Geddes <frog at bunyip.wheelycreek.net>
>> wrote:
>>
>>> Right, so I've implemented some stuff that seems to work quite well.
>>>
>>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/764
>>> should be ready now after a couple of stupid mistakes slipped through.
>>> This absolutely needs somebody to review it please! (There's a reason why
>>> I've converted some if()'s to switch() - which is that it will be used in
>>> the follow-up commit).
>>>
>>> The commit that will follow on from that it implements the new Units:
>>> kWh/100km, km/kWh and mi/kWh.
>>>
>>> This is a summary of what I've implemented for scripting - including
>>> showing the unit codes I have so far. I've considered a few things:
>>> * Should some of the longer unit codes be shortened (eg mi, mins, m,
>>> ft, deg, perc)
>>> * The unit codes could be much more regular and separated by dots
>>> eg:
>>> watthours -> w.h
>>> kwhp100km -> kw.h_100km or kw.h/100km
>>> miph -> mi_h or mi/h (or should it be mph).
>>> psi -> p_in.in or p/in.in or lb_in.in (yes, slightly weird, but
>>> predictable)
>>>
>>> *OVMS# metric units*
>>> km : km
>>> miles : M
>>> meters : m
>>> feet : ft
>>> celcius : °C
>>> fahrenheit : °F
>>> kpa : kPa
>>> pa : Pa
>>> psi : psi
>>> volts : V
>>> amps : A
>>> amphours : Ah
>>> kw : kW
>>> kwh : kWh
>>> watts : W
>>> watthours : Wh
>>> seconds : Sec
>>> minutes : Min
>>> hours : Hour
>>> utc : UTC
>>> degrees : °
>>> kmph : km/h
>>> miph : Mph
>>> kmphps : km/h/s
>>> miphps : Mph/s
>>> mpss : m/s²
>>> dbm : dBm
>>> sq : sq
>>> percent : %
>>> whpkm : Wh/km
>>> whpmi : Wh/mi
>>> kwhp100km : kWh/100km
>>> kmpkwh : km/kWh
>>> mipkwh : mi/kWh
>>> nm : Nm
>>>
>>> *OVMS# metric unit mi*
>>> miles : M
>>> minutes : Min
>>> miph : Mph
>>> miphps : Mph/s
>>> whpmi : Wh/mi
>>> mipkwh : mi/kWh
>>>
>>>
>>> *OVMS# metric get xiq.v.trip.consumption *17.0597kWh/100km
>>>
>>> *OVMS# metric get xiq.v.trip.consumption kpkwh *5.86177km/kWh
>>>
>>> *OVMS# metric get xiq.v.trip.consumption mpkwh *3.64233mi/kWh
>>>
>>>
>>> *OVMS# metric set xiq.c.speed 5 miph *Metric set
>>>
>>> *OVMS# metric get xiq.c.speed *8.04673km/h
>>>
>>> *OVMS# metric get xiq.c.speed miph *5Mph
>>>
>>> And then in DukTape - there are some questions I have about the
>>> implementation:
>>> * Names of functions? Better ideas?
>>> * Should ValueUnit output the units?
>>> * In Value() there is the line bool decode = duk_opt_boolean(ctx, 1,
>>> true);
>>> * What does 'decode' mean here?
>>> * Do I need it for ValueUnit() ?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> * (function() { print( OvmsMetrics.Value("xiq.v.trip.consumption"));
>>> print("\n") print(
>>> OvmsMetrics.ValueUnit("xiq.v.trip.consumption","")); print("\n")
>>> print( OvmsMetrics.ValueUnit("xiq.v.trip.consumption","mipkwh"));
>>> print("\n") print(
>>> OvmsMetrics.AsFloatUnit("xiq.v.trip.consumption","kmpkwh")); })();*
>>> --- Output ---
>>> 17.0597
>>> 17.0597kWh/100km
>>> 3.64233mi/kWh
>>> 5.86177
>>> ------
>>>
>>> The basic stuff all works - it's just quibbling over the details.. but
>>> let's get them right!
>>>
>>> //.ichael
>>>
>>> On Sat, 5 Nov 2022 at 20:09, Michael Geddes <frog at bunyip.wheelycreek.net>
>>> wrote:
>>>
>>>> Yeah - this was copied code from kia/kona and is what triggered these
>>>> ideas; I totally agree this shouldn't be doubled up on.
>>>>
>>>> I've got some commits centred round Metrics that I'll just check over
>>>> and push up ... and then I'll just have the single xiq.v.
>>>> trip.consumption metric (unless you have some ideas for the namespace)
>>>> which will be much neater.
>>>>
>>>> If it's ok with you then I might do that unit conversion proposal.
>>>> Would it ok if the unit specifications were the same as to the
>>>> programatic codes in ovms_metrics.h?
>>>> (kWh, WattHours , MetersPSS )
>>>> I would probably add a command
>>>> metric units <spec>
>>>> to list all (matching) units and their associated Labels.
>>>>
>>>> //.ichael
>>>>
>>>> On Sat, 5 Nov 2022 at 18:48, Michael Balzer <dexter at expeedo.de> wrote:
>>>>
>>>>> Michael,
>>>>>
>>>>> adding unit conversion support to the shell and Duktape commands is a
>>>>> good idea.
>>>>>
>>>>> Metrics are not meant to provide a user interface, they should be
>>>>> defined to be efficient and non-redundant.
>>>>>
>>>>> Btw, metrics names also shall not use upper case characters, and shall
>>>>> only use "." as a separator.
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>>
>>>>> Am 05.11.22 um 11:22 schrieb Michael Geddes:
>>>>>
>>>>> Hi all,
>>>>> Some of the code I copied from Kona/Kia code had both kwh/100km and
>>>>> km/kwh metrics in the code as 'Other'.
>>>>> Adding the various power consumption Units is not particularly hard (I
>>>>> will have a pull-request soon) - though the conversions between them all
>>>>> required some thought!
>>>>> ... but it also made me think these two metrics that are (with the
>>>>> consumption units added) defined like this:
>>>>> m_v_trip_consumption1 =
>>>>> MyMetrics.InitFloat("xiq.v.trip.consumption.KWh/100km", 10, 0, kWHP100K);
>>>>> m_v_trip_consumption2 = MyMetrics.InitFloat("
>>>>> xiq.v.trip.consumption.km/kWh", 10, 0, kPkWH);
>>>>>
>>>>> These are effectively the same metric but in different units!
>>>>> I'm wondering if we would be better to have scripting and Duktape
>>>>> support for converting metrics to different unit! This might be also quite
>>>>> useful for those strange countries that insist on using miles as a
>>>>> measurement.
>>>>>
>>>>> On top of the 'metric list' and 'metric set' we could add a 'metric
>>>>> get' which gets a single value.. and add unit support for get/set.
>>>>>
>>>>> I've also got a pull request that improves the precision of the
>>>>> km<->mi conversions and factors it out.
>>>>>
>>>>> //.ichael
>>>>>
>>>>> _______________________________________________
>>>>> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>
>>>>>
>>>>> --
>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>>
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>
>>>>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20221108/58568ffa/attachment-0001.htm>
More information about the OvmsDev
mailing list