<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
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:<br>
<ul>
<li><a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/pipermail/ovmsdev/2021-January/015008.html">http://lists.openvehicles.com/pipermail/ovmsdev/2021-January/015008.html</a><br>
</li>
<li><a class="moz-txt-link-freetext" href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/220616927e89f0109952c9056dc3f95b93c7e9fc">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/220616927e89f0109952c9056dc3f95b93c7e9fc</a><br>
</li>
</ul>
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.<br>
<br>
The "driver" could be the seat array index in this scheme, or -1 for
"no driver".<br>
<br>
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.<br>
<br>
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.<br>
<br>
Initial thoughts on this:<br>
<br>
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.<br>
<br>
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.<br>
<br>
Example:<br>
<br>
<font face="monospace">// 5 seat car with a driver, a small child on
the FR seat (airbag disabled) and another child on the RR:<br>
v.s.seat.load 67,12,0,0,32kg<br>
v.s.seat.belt 1,1,0,0,1<br>
v.s.seat.airbag 1,2,1,0,1<br>
<br>
// FL seat heating on level 2, RR level 1:<br>
v.e.seat.heating 2,0,0,0,1<br>
<br>
// Driver is person on FL seat:<br>
v.e.driver 0<br>
<br>
// Query vehicle configuration:<br>
OVMS# config list vehicle.config<br>
vehicle.config (readable)<br>
tpms.layout FL,FR,RL,RR<br>
seat.layout FL,FR,RL,RM,RR<br>
…<br>
<br>
</font><font face="monospace">// Query vehicle feature support:<br>
OVMS# config list vehicle.support<br>
vehicle.support (readable)<br>
ctrl.chg mode,current,start,stop,limit,timer<br>
ctrl.env climate,doors,valet,homelink<br>
ctrl.sys wakeup<br>
info.bat soc,range,soh,energy,bms<br>
info.chg mode,current,state,duration,limit<br>
info.env temps,doors,tpms<br>
…<br>
<br>
</font><br>
Comments?<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 05.11.22 um 12:11 schrieb Michael
Geddes:<br>
</div>
<blockquote type="cite"
cite="mid:CAH0p7u+FU0fLD8abhiGepeNs5LGXhCywm5kh+oPX51vq0ccqHw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">I like the idea of the v.s.* namespace.<br>
</div>
<div dir="ltr"><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>//.ichael</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, 5 Nov 2022 at 18:32,
Michael Balzer <<a href="mailto:dexter@expeedo.de"
moz-do-not-send="true" class="moz-txt-link-freetext">dexter@expeedo.de</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div> Michael,<br>
<br>
I also had some thoughts on this, some first feedback from
these on yours:<br>
<ul>
<li>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.</li>
<li>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.</li>
<li>The "driver" metric may then also be assigned to a
special value to represent autonomous driving modes.<br>
</li>
<li>I also think about arrays instead of fixed geometric
layouts, as vehicles come in a variety of door &
seat arrangements.<br>
</li>
</ul>
Regards,<br>
Michael<br>
<br>
<br>
<div>Am 05.11.22 um 11:07 schrieb Michael Geddes:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi all,
<div>I started this thought following up on my Ioniq 5
thread - but figured it might be worth a new
conversation.<br>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>The Door Locked series is obviously a good
start - the candidate names being pretty straight
forward imho.</div>
<div>v.d.l.fl<br>
<a href="http://v.d.l.fr" target="_blank"
moz-do-not-send="true">v.d.l.fr</a><br>
v.d.l.rl<br>
v.d.l.rr<br>
</div>
<div>Most cars these days would have seatbelt
sensors - so they might also be a candidate.
v.sb.fl etc.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Sooo.. I was considering some of the issues:</div>
<div><br>
</div>
<div>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.</div>
<div>2) In general scared scripts, we probably care
more about whether it is drive/passenger side
rather than left/right!</div>
<div><br>
</div>
<div>Could we have some metric alias's for
left/right metrics that would be drive/passenger
that would allow</div>
<div>* Setting via either metric</div>
<div>* Reading via either metric</div>
<div>* Adding events based on either metric.</div>
<div>For eg</div>
<div>v.d.l.fl links to<br>
</div>
<div>* v.d.l.fd (front driver) for Left-hand drive
and</div>
<div>* v.d.l.fp (front passenter) for Right-hand
drive cars.</div>
<div>I mean we could set both metrics.. but would
that work?</div>
<div><br>
</div>
<div>Thoughts on this?</div>
<div>//.ichael</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre cols="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">OvmsDev@lists.openvehicles.com</a><br>
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
</body>
</html>