[Ovmsdev] Thoughts on Metrics - new 'standard metric' candidates and right drive cars
Michael Balzer
dexter at expeedo.de
Wed Nov 9 01:21:38 HKT 2022
Michael,
configs are no metrics, access would be by "config" / 'OvmsConfig', but
yes, there are API calls there as well to retrieve sets of entries as
objects:
https://docs.openvehicles.com/en/latest/userguide/scripting.html#ovmsconfig
The config registry already provides read-only params. These could still
be written to internally, i.e. by the vehicle module, or be completely
under control of the vehicle module -- details need to be cleared.
The main question is if this scheme fits from the system design
perspective, or if we should add something like a dedicated vehicle
config/features registry with a separate set of commands & APIs. The
question here is, if we define "configuration" strictly as "module
configuration", or if we extend that to "module & vehicle configuration".
If read-only config params fit, the next question is if the proposed
naming & value scheme would be OK. Functional coverage e.g. could also
be spread out into single boolean instances, and for…
metric get v.s.seat.load[FL]
…"metric get" would either need to know the config instances defining
names for metrics, or the instances would need to imply their metrics
association somehow (by their name?), so this can be done in a generic way.
OTOH, I don't think accessing metric values and especially array
elements from the shell will become common, listing metrics is normally
all you need on the shell. If you're working with specific metric
values, you'll rather use Javascript.
Regards,
Michael
Am 07.11.22 um 05:58 schrieb Michael Geddes:
> Ah. Starting to see it.
>
> So you are having the whole of vehicle.config as returning an
> associative array of config values? I guess that keeps that bit of
> it separate. makes sense even if a bit of work.
> Can we return an associative array to duktape?
>
> When I introduce 'metric get' (which is just waiting some finessing
> of the Duktape code) it would be modified to allow indexes into arrays...
> so
> metric get v.s.seat.load[0]
> or
> metric get v.s.seat.load[FL]
>
> and
> metric get vehicle.support[info.bat]
>
> Is that the kind of idea?
> //.ichael
>
>
>
>
> On Sun, 6 Nov 2022, 6:19 pm Michael Balzer, <dexter at expeedo.de> wrote:
>
> The arrays would go along the scheme of the recent similar
> transition for the TPMS, with the names factored out into a common
> vehicle configuration:
>
> * http://lists.openvehicles.com/pipermail/ovmsdev/2021-January/015008.html
> * https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/220616927e89f0109952c9056dc3f95b93c7e9fc
>
> Factoring out the configuration solves the need for metric value
> structures getting more complex than arrays. In this scheme, more
> properties can be added simply by additional array metrics (as was
> needed by the TPMS extension), and a runtime configuration change
> (e.g. when towing a trailer or reconfiguring a family van seat
> rows) is a simple array size change.
>
> The "driver" could be the seat array index in this scheme, or -1
> for "no driver".
>
> There is an open todo regarding a general query scheme for vehicle
> configurations like these. This also applies to e.g. the battery
> pack layout, and also to the features / commands supported etc..
> We formerly called these "capabilities" (in the OVMS V2
> framework), but the capabilities data model was too limited for V3.
>
> There was no real need to implement a V3 approach for this
> previously, but as we're now about to extend the metrics / vehicle
> configuration dependencies, this should maybe addressed now as well.
>
> Initial thoughts on this:
>
> In the V3 scheme, vehicle configurations & features could be seen
> & implemented as read-only configuration instances, i.e. reusing
> the existing naming & querying & API scheme for user configurations.
>
> The user interface would be a read-only config parameter
> "vehicle.config" (or "vehicle.features" or "vehicle.support" for
> the functional coverage?) for standard configurations, likewise
> vehicle specific ones as "<vehicleprefix>.config" as needed.
>
> Example:
>
> // 5 seat car with a driver, a small child on the FR seat (airbag
> disabled) and another child on the RR:
> v.s.seat.load 67,12,0,0,32kg
> v.s.seat.belt 1,1,0,0,1
> v.s.seat.airbag 1,2,1,0,1
>
> // FL seat heating on level 2, RR level 1:
> v.e.seat.heating 2,0,0,0,1
>
> // Driver is person on FL seat:
> v.e.driver 0
>
> // Query vehicle configuration:
> OVMS# config list vehicle.config
> vehicle.config (readable)
> tpms.layout FL,FR,RL,RR
> seat.layout FL,FR,RL,RM,RR
> …
>
> // Query vehicle feature support:
> OVMS# config list vehicle.support
> vehicle.support (readable)
> ctrl.chg mode,current,start,stop,limit,timer
> ctrl.env climate,doors,valet,homelink
> ctrl.sys wakeup
> info.bat soc,range,soh,energy,bms
> info.chg mode,current,state,duration,limit
> info.env temps,doors,tpms
> …
>
>
> Comments?
>
> Regards,
> Michael
>
>
> Am 05.11.22 um 12:11 schrieb Michael Geddes:
>> I like the idea of the v.s.* namespace.
>>
>> We could just have 'v.driver' = Left/Right/Auto - since really
>> it's the Driver roll that is possibly the one that would be
>> scripted on. I'm still not sure how you would then easily get at
>> the 'driver-side-door' or 'driver-side-seatbelt' values.
>>
>> How would you manage the arrays and make it easy to work with in
>> extracting left/right/centre front/back etc? Associative array
>> could work .. though that's not that different from the current
>> *.fl *.fr etc.
>>
>> //.ichael
>>
>> On Sat, 5 Nov 2022 at 18:32, Michael Balzer <dexter at expeedo.de>
>> wrote:
>>
>> Michael,
>>
>> I also had some thoughts on this, some first feedback from
>> these on yours:
>>
>> * I'd place seatbelt sensors in a new name space "v.s." for
>> vehicle safety & security related metrics. That would
>> also become the place for airbag & emergency braking
>> sensors, traction control & emergency lights and the like.
>> * I'd decouple the "driver" & "passenger" roles from the
>> physical allocation, because this may become a property
>> that can be changed on the fly even during driving, as
>> soon as all vehicle controls are digital.
>> * The "driver" metric may then also be assigned to a
>> special value to represent autonomous driving modes.
>> * I also think about arrays instead of fixed geometric
>> layouts, as vehicles come in a variety of door & seat
>> arrangements.
>>
>> Regards,
>> Michael
>>
>>
>> Am 05.11.22 um 11:07 schrieb Michael Geddes:
>>> Hi all,
>>> I started this thought following up on my Ioniq 5 thread -
>>> but figured it might be worth a new conversation.
>>>
>>> Michael B talked about having some new standard metrics (and
>>> also some consistent metric names in my i5 code: patch
>>> coming now that I understand a bit better why those exist).
>>>
>>> The Door Locked series is obviously a good start - the
>>> candidate names being pretty straight forward imho.
>>> v.d.l.fl
>>> v.d.l.fr <http://v.d.l.fr>
>>> v.d.l.rl
>>> v.d.l.rr
>>> Most cars these days would have seatbelt sensors - so they
>>> might also be a candidate. v.sb.fl etc.
>>>
>>> That being said, I have some issues related to
>>> 'right-hand-drive' vehicles which are quite popular in
>>> Australia ;). For a start, there's no metric for it;
>>> obviously some cars implementations will have a setting. For
>>> the Hyundai this is important as it seems many left/right
>>> settings are actually based on drive/passenger side in the
>>> OBD bits.
>>>
>>> Sooo.. I was considering some of the issues:
>>>
>>> 1) When it's on a diagram or in a user message, we want
>>> left/right because that's how we want to deal with it.
>>> 2) In general scared scripts, we probably care more about
>>> whether it is drive/passenger side rather than left/right!
>>>
>>> Could we have some metric alias's for left/right metrics
>>> that would be drive/passenger that would allow
>>> * Setting via either metric
>>> * Reading via either metric
>>> * Adding events based on either metric.
>>> For eg
>>> v.d.l.fl links to
>>> * v.d.l.fd (front driver) for Left-hand drive and
>>> * v.d.l.fp (front passenter) for Right-hand drive cars.
>>> I mean we could set both metrics.. but would that work?
>>>
>>> Thoughts on this?
>>> //.ichael
>>>
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://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 list
>> OvmsDev at lists.openvehicles.com
>> http://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 list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20221108/909e9d44/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20221108/909e9d44/attachment-0001.sig>
More information about the OvmsDev
mailing list