[Ovmsdev] New Metric Units
Michael Geddes
frog at bunyip.wheelycreek.net
Mon Nov 7 08:12:45 HKT 2022
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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20221107/155dddee/attachment-0001.htm>
More information about the OvmsDev
mailing list