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:
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@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 list
OvmsDev@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@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev

_______________________________________________
OvmsDev mailing list
OvmsDev@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