<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Michael,<br>
<br>
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:<br>
<a class="moz-txt-link-freetext" href="https://docs.openvehicles.com/en/latest/userguide/scripting.html#ovmsconfig">https://docs.openvehicles.com/en/latest/userguide/scripting.html#ovmsconfig</a><br>
<br>
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.<br>
<br>
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".<br>
<br>
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…<br>
<br>
<font face="monospace">metric get v.s.seat.load[FL]</font><br>
<br>
…"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.<br>
<br>
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.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 07.11.22 um 05:58 schrieb Michael
Geddes:<br>
</div>
<blockquote type="cite"
cite="mid:CAH0p7uK49ygVyM+xw_DpyMkpHrSrm24A1MRJfXxu-pPNKHegPQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="auto">Ah. Starting to see it.
<div dir="auto"><br>
</div>
<div>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.</div>
<div>Can we return an associative array to duktape?</div>
<div><br>
</div>
<div>When I introduce 'metric get' (which is just waiting
some finessing of the Duktape code) it would be modified to
allow indexes into arrays...</div>
<div>so </div>
<div>metric get v.s.seat.load[0] </div>
<div>or</div>
<div>metric get v.s.seat.load[FL]<br>
</div>
<div><br>
</div>
<div>and </div>
<div>metric get <span style="font-family:monospace">vehicle.support[</span><span
style="font-family:monospace">info.bat]</span><br>
</div>
<div><span style="font-family:monospace"><br>
</span></div>
<div>Is that the kind of idea?</div>
<div>//.ichael</div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
</div>
<br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, 6 Nov 2022, 6:19
pm Michael Balzer, <<a href="mailto:dexter@expeedo.de"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">dexter@expeedo.de</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div> 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
href="http://lists.openvehicles.com/pipermail/ovmsdev/2021-January/015008.html"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">http://lists.openvehicles.com/pipermail/ovmsdev/2021-January/015008.html</a><br>
</li>
<li><a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/220616927e89f0109952c9056dc3f95b93c7e9fc"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">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>Am 05.11.22 um 12:11 schrieb Michael Geddes:<br>
</div>
<blockquote type="cite">
<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"
rel="noreferrer" target="_blank"
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"
rel="noreferrer" 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" rel="noreferrer" 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" rel="noreferrer" 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"
rel="noreferrer" 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 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></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" rel="noreferrer" 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" rel="noreferrer" 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"
rel="noreferrer" 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 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>
</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>