[Ovmsdev] Thoughts on Metrics - new 'standard metric' candidates and right drive cars
Michael Balzer
dexter at expeedo.de
Sun Nov 6 18:18:45 HKT 2022
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20221106/41bc56be/attachment.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/20221106/41bc56be/attachment.sig>
More information about the OvmsDev
mailing list