[Ovmsdev] Thoughts on Metrics - new 'standard metric' candidates and right drive cars
Michael Geddes
frog at bunyip.wheelycreek.net
Mon Nov 7 12:58:53 HKT 2022
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
>> 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 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/20221107/c509d88b/attachment-0001.htm>
More information about the OvmsDev
mailing list