<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I totally agree with Julien, I prefer adopting the OBDII standard
units for our metrics dictionary and not add more overhead to this.<br>
<br>
If we define the units as part of our metrics dictionary
specification, we do not need to store them in the values, except
for generic value handling in the module. I currently can't think of
a generic function in the module that really needs to be unit-aware.
If (!) we find some later on, we still can add the units -- and will
have a better idea of the free space left then.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 26.10.2017 um 08:30 schrieb Julien
“JaXX” Banchet:<br>
</div>
<blockquote type="cite"
cite="mid:b8b68680-3319-42c6-8f2d-f09567257f2e@Spark">
<title></title>
<div name="messageBodySection" style="font-size: 14px;
font-family: -apple-system, BlinkMacSystemFont, sans-serif;">Hi,
<div><br>
</div>
<div>Same for me #1, or even lighter than that :-) .</div>
<div><br>
</div>
<div>Sources are mostly metric/SI (besides Tesla, which will be
among the rare exceptions hardcoded to be to converted as
early as possible)…</div>
<div>The structure would be then: the value. Point … We’d know
from the name what type of value it is air
pressure/speed/rpm/linear distance/soc/whatever/...</div>
<div><br>
</div>
<div>Showing human readable / l18n values should be kept on the
presentation layer away from the OVMS (mobile app/intelligent
cluster-hmi/etc… anywhere where processing power isn’t an
issue), eventually through a crafted function on the OVMS that
takes flash, not ram, though again, connecting to the shell is
not the day-to-day usage imho.</div>
<div><br>
</div>
<div>Yeah, I’m an SI-n*zi :)</div>
<div><br>
</div>
<div>I might be missing something important that prevents
simplifying metric storage but the lighter, the better.</div>
<div><br>
</div>
<div>Julien,</div>
<div>Who brought 10kg of electronics on vacation, OVMS included,
but forgot his laptop charger :-/</div>
</div>
<div name="messageReplySection" style="font-size: 14px;
font-family: -apple-system, BlinkMacSystemFont, sans-serif;"><br>
On 26 Oct 2017 at 08:17 +0200, Greg D.
<a class="moz-txt-link-rfc2396E" href="mailto:gregd2350@gmail.com"><gregd2350@gmail.com></a>, wrote:<br>
<blockquote type="cite" style="margin: 5px 5px; padding-left:
10px; border-left: thin solid #1abc9c;">Preference here is for
option #1. Keep it simple and standard. Elegance is costing
us RAM and CPU cycles, and neither appear to be plentiful, in
spite of the vastly improved platform.<br>
<br>
Greg<br>
<br>
<br>
<div class="moz-cite-prefix">Mark Webb-Johnson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:D56A7A4B-18A7-4D1C-9B5C-3979FEC1D35C@webb-johnson.net"
style="margin: 5px 5px; padding-left: 10px; border-left:
thin solid #e67e22;">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
To put in code the two alternative approaches being
considered:
<div class=""><br class="">
</div>
<blockquote style="margin: 5px 5px; padding-left: 10px;
border-left: thin solid #3498db;" class="">
<div class="">enum</div>
<div class="">{</div>
<div class="">other,</div>
<div class="">kilometers,</div>
<div class="">miles,</div>
<div class="">celcius,</div>
<div class="">fahrenheit,</div>
<div class="">kpa,</div>
<div class="">psi,</div>
<div class="">percentage</div>
<div class="">} unit_t;</div>
</blockquote>
<br class="">
<div class="">
<ol class="MailOutline">
<li class="">Everything metric<br class="">
<br class="">
OvmsMetric:<br class="">
unit_t m_unit;<br class="">
unit_t GetUnit();<br class="">
std::string AsStringConverted(unit_t conversion);<br
class="">
<br class="">
</li>
<li class="">Unit with the metric<br class="">
<br class="">
OvmsMetric:<br class="">
unit_t m_unit;<br class="">
unit_t GetUnit();<br class="">
std::string AsStringConverted(unit_t conversion);<br
class="">
void SetValue(std::string value, unit_t unit);<br
class="">
etc</li>
</ol>
</div>
<div class=""><br class="">
</div>
<div class="">The difference is that with [1] m_unit is
always the metric unit, and with [2] m_unit is the unit
set when the value is stored. With [1], the vehicle module
will perform any incoming conversion to metric, while with
[2], the vehicle just stores the value and unit together
(with conversion being performed, if necessary, on
retrieval).</div>
<div class=""><br class="">
</div>
<div class="">The first is simpler, but does suffer from the
double conversion issue in some cases. The second avoids
that, at the expense of complexity.</div>
<div class=""><br class="">
</div>
<div class="">How we present this to apps is really
irrelevant (or the decision at least can be put off to
later as that is a v3 protocol decision). For v2 protocol,
we have to present as per the v2 protocol specification.</div>
<div class=""><br class="">
</div>
<div class="">On review, I think my personal preference is
really for [2]. I understand it is more complex, but it is
quite elegant. Conversions are only done when absolutely
necessary. Let’s look at an extreme example of a vehicle
producing miles data, and an app requesting miles. With
[1], the vehicle would convert miles->km and store in
the metric, then ovms_server_v2 would convert km->miles
and send it out. With [2], the vehicles stores the
(value,”miles”) in the metric, and ovms_server_v2 reads
value back out (using “miles” as a selector for the
value). If a user sets his units to “km”, and does a
“metric list”, with [2], the metric itself converts
miles->km for the display. So, [2] does complicate it,
but all that complication is hidden in the standardised
metric system.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="" style="margin: 5px 5px;
padding-left: 10px; border-left: thin solid #3498db;">
<div class="">On 26 Oct 2017, at 9:51 AM, Mark
Webb-Johnson <<a
href="mailto:mark@webb-johnson.net" class=""
moz-do-not-send="true">mark@webb-johnson.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div style="word-wrap: break-word;
-webkit-nbsp-mode: space; -webkit-line-break:
after-white-space;" class="">
<div class="">I did a quick review of the way
things were done in OVMS v2. Some notes:</div>
<div class=""><br class="">
</div>
<div class="">The OVMS v2 protocol specified:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">Car Environment message 0x44 “D"<br
class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>•
Temperature of the PEM (celcius)</div>
<div class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>•
Temperature of the Motor (celcius)</div>
</div>
<div class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>•
Temperature of the Battery (celcius)</div>
</div>
<div class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>•
Car trip meter (in 1/10th of a distance
unit)</div>
</div>
<div class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>•
Car odometer (in 1/10th of a distance
unit)</div>
</div>
<div class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>•
Car speed (in distance units per hour)</div>
</div>
<div class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>•
Ambient Temperature (in Celcius)</div>
</div>
</li>
<li class="">Car state message 0x53 “S”<br
class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>•
Units ("M" for miles, "K" for kilometers)<br
class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>•
Ideal range<br class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>•
Estimated range</div>
</div>
</div>
</li>
<li class="">Registered parameter #2<br
class="">
<span class="Apple-tab-span" style="white-space: pre;"></span>•
Miles / Kilometer flag</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">The OVMS v2 net_msg code did some
conversions:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">car_tpem is always stored in
Celcius, and always sent as such</li>
<li class="">car_tmotor is always stored in
Celcius, and always sent as such</li>
<li class="">car_tbattery is always stored in
Celcius, and always sent as such</li>
<li class="">car_trip is stored in Miles, so a
KmFromMi() conversion is done if units were
“K”</li>
<li class="">car_odometer is stored in
Miles, so a KmFromMi() conversion is done if
units were “K”</li>
<li class="">car_speed is stored in user unit,
and sent as such</li>
<li class="">car_ambient_temp is always stored
in Celcius, and always sent as such</li>
<li class="">Units is stored as a parameter,
and sent as such</li>
<li class="">car_idealrange is stored in
Miles, so a KmFromMi() conversion is done if
units were “K”</li>
<li class="">car_estrange is stored in Miles,
so a KmFromMi() conversion is done if units
were “K”</li>
<li class="">tpms is stored in raw (Tesla)
format, and sent as PSI and Celcius</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">I did some quick checks against the
OVMS v2 vehicle_*.c code. Here are some notes:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">Kia Soul: Seems to have distances
in metric, and uses MiFromKm() when storing
to car_*. Temperatures in celcius, so no
conversion necessary.</li>
<li class="">Mitsubishi iMiev: MiFromKm() for
distances. Temperatures in celcius, so no
conversion necessary.</li>
<li class="">Tesla Roadster: Miles for
distances, Celcius for temperatures, so no
conversions necessary (surprise, surprise,
as OVMS v2 car model based on this car).</li>
<li class="">Nissan Leaf: MiFromKm() for
distances. Temperatures in celcius, so no
conversion necessary.</li>
<li class="">Twizy: MiFromKm() for
distances. Temperatures in celcius, so no
conversion necessary.</li>
<li class="">Renault Zoe: MiFromKm() for
distances. Seemingly no temperature support.</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">I then looked at the OBDII standard.
Here are the notes from that:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">Temperatures are stored and
transmitted in Celcius</li>
<li class="">Pressures are stored and
transmitted in Pa / kPa</li>
<li class="">Distances are stored and
transmitted in Km</li>
<li class="">Time is stored and transmitted in
Seconds</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">I looked at the Apps.</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">Configurable for temperatures:
car chooses / celcius / fahrenheit</li>
<li class="">Configurable for distances: car
chooses / miles / kilometers</li>
<li class="">No configuration for pressures</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">Overall, I would conclude:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">The OVMS v2 protocol is kind of
messy, not symmetric. It does conversions in
some place, but in others leaves it up to
the App.</li>
<li class="">It seems that almost all the
vehicles use metric units</li>
<li class="">OBDII uses metric units</li>
<li class="">We need to maintain compatibility
with OVMS v2 protocol, but can do things
differently for v3 protocol</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">I suggest the following:</div>
<div class=""><br class="">
</div>
<div class="">
<ol class="MailOutline">
<li class="">The Metrics use metric units for
their internal storage (sic).</li>
<li class="">We add units labels to the
metrics. This can be used (a) as a nice
display (SOC: 10% vs 10), and (b) as the
basis for conversion support at the metric
level.</li>
<li class="">We add units parameters to the
configuration storage (for pressure,
temperature, distance).</li>
<li class="">We make the ovms_server_v2
convert to the v2 protocol standard</li>
</ol>
</div>
<div class=""><br class="">
</div>
<div class="">Doing it that way means that most
vehicles will store in their native format
(metric) - only Tesla Roadster will incur a
Miles->KM->Miles penalty. Using ‘float’ to
some extent mitigates this.</div>
<div class=""><br class="">
</div>
<div class="">The alternative (storing the unit
with the metric, and having it passes whenever
we set/read the metric) is much more complex and
seemingly only required for one particular
vehicle (ignoring the temporary issue of v2
protocol, until we roll out v3 protocol and
apps).</div>
<div class=""><br class="">
</div>
<div class="">I do think that whatever we decide,
it needs to be decided now. We are converting
the vehicle modules over, and doing this now is
much simpler than trying to re-work it later.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
</div>
<blockquote type="cite" class="" style="margin:
5px 5px; padding-left: 10px; border-left: thin
solid #d35400;"><span style="font-family:
Menlo-Regular; font-size: 14px;" class="">Really
not a fan of this, as the app may not even
know what kind of</span><br
style="font-family: Menlo-Regular; font-size:
14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">vehicle is being
used (an attached HUD, for example). If
there's a</span><br style="font-family:
Menlo-Regular; font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">function in the
metric object that does the conversion to make
it</span><br style="font-family:
Menlo-Regular; font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">transparent, I
suppose that could work. But I'd really
prefer to have</span><br style="font-family:
Menlo-Regular; font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">at least the
standard metrics table be vehicle-independent,
and in</span><br style="font-family:
Menlo-Regular; font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">standard units.
The OBDII spec assumes this, and the devices
all have</span><br style="font-family:
Menlo-Regular; font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">Metric / Imperial
mode switches included. For common items that
may be</span><br style="font-family:
Menlo-Regular; font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">missing from a
particular vehicle (e.g. motor RPM on the
Roadster), the</span><br style="font-family:
Menlo-Regular; font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">vehicle code that
populates the metrics table should derive them
from</span><br style="font-family:
Menlo-Regular; font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">what is available.
For the Roadster example, motor RPM is
basically</span><br style="font-family:
Menlo-Regular; font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">vehicle speed times
70, so when receiving a speed CAN frame, both
the</span><br style="font-family:
Menlo-Regular; font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">v.p.speed and
v.p.rpm (new metric, please?) would be
updated.</span><br style="font-family:
Menlo-Regular; font-size: 14px;" class="">
<br style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">If there are
metrics that don't apply to multiple vehicles,
and don't</span><br style="font-family:
Menlo-Regular; font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">fit into the
standard ones, they can certainly be in
vehicle-specific</span><br style="font-family:
Menlo-Regular; font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">units. Best to
have a separate table for them, I think, with
the items</span><br style="font-family:
Menlo-Regular; font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">prefaced by the
2-letter vehicle name. I can certainly deal
with having</span><br style="font-family:
Menlo-Regular; font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">a table name as
part of the PID remapping scheme. But,
please, not on a</span><br style="font-family:
Menlo-Regular; font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">per metric basis.</span><br
style="font-family: Menlo-Regular; font-size:
14px;" class="">
<br style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">The
vehicle-specific use can also be aided by
scripting some of the</span><br
style="font-family: Menlo-Regular; font-size:
14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">conversion. Still
working on how that can be done. But again,
we</span><br style="font-family:
Menlo-Regular; font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">shouldn't need to
load in a whole library of vehicle-specific
scripts</span><br style="font-family:
Menlo-Regular; font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">just to handle the
common parameters (speed, SoC, etc.).</span><br
style="font-family: Menlo-Regular; font-size:
14px;" class="">
<br style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">My $.02,</span><br
style="font-family: Menlo-Regular; font-size:
14px;" class="">
<br style="font-family: Menlo-Regular;
font-size: 14px;" class="">
<span style="font-family: Menlo-Regular;
font-size: 14px;" class="">Greg</span></blockquote>
<div class=""><font class="" face="Menlo-Regular"><span
style="font-size: 14px;" class=""><br
class="">
</span></font>
<div class="">
<blockquote type="cite" class=""
style="margin: 5px 5px; padding-left: 10px;
border-left: thin solid #d35400;">
<div class="">On 25 Oct 2017, at 12:26 PM,
HONDA S-2000 <<a
href="mailto:s2000@audiobanshee.com"
class="" moz-do-not-send="true">s2000@audiobanshee.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">I like the concept of
storing vehicle units in the module and
letting the app sort out the
conversions. Theoretically, this allows
for alternate app front ends that might
do “something” with the additional
information in the vehicle units that
might be lost in translation
(conversion). But, I am a nerd with a
bias towards low-level details, and that
might not be the best. :-)<br class="">
<br class="">
Obviously, the down side is that each
additional vehicle unit adds to the code
in the app. My usual assumption is that
there’s more room in a front end
application for these sorts of things,
as opposed to the embedded side. To
contradict myself, though, it seems that
we’re allowing for the embedded firmware
to be compiled for a single vehicle,
meaning that none of the code needs to
carry around unused conversions.<br
class="">
<br class="">
Stepping away from my technical focus
(where I might be interested in the
exact vehicle units for, e.g., torque on
my roadster), perhaps it would be better
to design around the typical user, who
will either be interested in miles or
kilometers, foot-pounds or
Newton-meters, and basically just
English versus metric. In that case,
maybe the embedded firmware could have a
meta parameter to select English versus
metric, and then all communications with
the app would be in those units. The
down side to this idea is that the
embedded firmware would need to be
capable of two different conversions for
potentially every metric, assuming that
every electric vehicle is available in
multiple countries, both metric and
English.<br class="">
<br class="">
Sorry to throw a jumbled set of ideas at
the problem, but I wanted to share my
thoughts.<br class="">
<br class="">
Brian<br class="">
<br class="">
<br class="">
On Oct 24, 2017, at 1:08 PM, Michael
Balzer <<a
href="mailto:dexter@expeedo.de"
class="" moz-do-not-send="true">dexter@expeedo.de</a>>
wrote:<br class="">
<blockquote type="cite" class=""
style="margin: 5px 5px; padding-left:
10px; border-left: thin solid
#34495e;">I've done the int to float
changes and the temperature naming.<br
class="">
<br class="">
Not sure about the best way to solve
the units problem yet, but I guess<br
class="">
we can start with storing in vehicle
units and add the conversion later on.<br
class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
Am 24.10.2017 um 04:46 schrieb Mark
Webb-Johnson:<br class="">
<blockquote type="cite" class=""
style="margin: 5px 5px;
padding-left: 10px; border-left:
thin solid #2ecc71;">Tough
questions. Answers/comments inline.<br
class="">
<br class="">
<blockquote type="cite" class=""
style="margin: 5px 5px;
padding-left: 10px; border-left:
thin solid #9b59b6;">On 23 Oct
2017, at 9:33 PM, Michael Balzer
<<a
href="mailto:dexter@expeedo.de"
class="" moz-do-not-send="true">dexter@expeedo.de</a>>
wrote:<br class="">
<br class="">
Trying to catch up…<br class="">
<br class="">
<br class="">
a) I'd love to get rid of those
km→miles→km conversions in V3.<br
class="">
<br class="">
How about introducing a metric
"v.units" instead to hold the
units used<br class="">
by the vehicle, and make
conversions at the user level if
necessary?<br class="">
</blockquote>
I don’t have a good answer for this.
I thought to just store all the
metrics in ‘metric’ (celcius,
kilometers, etc), and let the apps
deal with it (as they do now). But,
as you say, that does lead to the
problem of km->miles->km, etc.<br
class="">
<br class="">
An alternative is to store a ‘units’
with the metric, and have the metric
deal with presentation conversion
upon retrieval. That reduces the
number of conversions.<br class="">
<br class="">
In general, having this done in the
module seems to make more sense than
doing it in the apps.<br class="">
<br class="">
<blockquote type="cite" class=""
style="margin: 5px 5px;
padding-left: 10px; border-left:
thin solid #9b59b6;">b) Regarding
the standard metrics currently
defined, I'd need to<br class="">
introduce own copies again for
higher precision. I.e. SOC, SOH,
speed<br class="">
and ranges all are integers now,
and some more I'd like to be able
to<br class="">
set at higher precision.<br
class="">
<br class="">
How about making all these be
floats now? I.e. everything that
can<br class="">
require more than integer
precision.<br class="">
<br class="">
The server_v2 can output the
values as integers for v2 client
compatibility.<br class="">
</blockquote>
OK.<br class="">
<br class="">
<blockquote type="cite" class=""
style="margin: 5px 5px;
padding-left: 10px; border-left:
thin solid #9b59b6;">c) I haven't
seen a recommendation on naming
vehicle specific metrics.<br
class="">
My proposal: use the vehicle code
as the prefix, then try to reuse<br
class="">
similar paths from the standard
metrics, adding detail as
necessary.<br class="">
<br class="">
For example, the vehicle module
version on the Twizy ("RT") is<br
class="">
"rt.m.version", and for the min
& max battery voltage I've got<br
class="">
"rt.v.b.voltage.min" &
"rt.v.b.voltage.max".<br class="">
<br class="">
OVMS > metrics list rt.<br
class="">
rt.m.version
1.0.0 Oct 23
2017 11:45:31<br class="">
rt.v.b.soc <br
class="">
rt.v.b.temp.m1 <br
class="">
rt.v.b.temp.m2 <br
class="">
rt.v.b.temp.m3 <br
class="">
rt.v.b.temp.m4 <br
class="">
rt.v.b.temp.m5 <br
class="">
rt.v.b.temp.m6 <br
class="">
rt.v.b.temp.m7 <br
class="">
rt.v.b.voltage.max 0<br
class="">
rt.v.b.voltage.min 0<br
class="">
<br class="">
That way a path component can be
used to list all related metrics:<br
class="">
<br class="">
OVMS > metrics list b.voltage<br
class="">
rt.v.b.voltage.max 0<br
class="">
rt.v.b.voltage.min 0<br
class="">
v.b.voltage <br
class="">
</blockquote>
Ok, but I would suggest an ‘x.’
prefix (seems to match many Internet
standards, such as X- headers, etc).<br
class="">
<br class="">
So: x.rt.v.b.voltage.max, etc.<br
class="">
<br class="">
<blockquote type="cite" class=""
style="margin: 5px 5px;
padding-left: 10px; border-left:
thin solid #9b59b6;">d) I think
most of the temperature metrics
have wrong names:<br class="">
<br class="">
v.b.temp.ambient <br
class="">
v.b.temp.battery <br
class="">
v.b.temp.charger <br
class="">
v.b.temp.motor <br
class="">
v.b.temp.pem <br
class="">
<br class="">
…as "b." should be reserved for
"battery".<br class="">
<br class="">
How about…<br class="">
<br class="">
v.e.temp<br class="">
v.b.temp<br class="">
v.c.temp<br class="">
v.m.temp<br class="">
v.i.temp<br class="">
<br class="">
…introducing "m." for motor and
"i." for inverter?<br class="">
</blockquote>
OK.<br class="">
<br class="">
<blockquote type="cite" class=""
style="margin: 5px 5px;
padding-left: 10px; border-left:
thin solid #9b59b6;">Regards,<br
class="">
Michael<br class="">
</blockquote>
</blockquote>
</blockquote>
<br class="">
_______________________________________________<br class="">
OvmsDev mailing list<br class="">
<a
href="mailto:OvmsDev@lists.teslaclub.hk"
class="" moz-do-not-send="true">OvmsDev@lists.teslaclub.hk</a><br
class="">
<a
href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev"
class="" moz-do-not-send="true">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk" moz-do-not-send="true">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
_______________________________________________<br>
OvmsDev mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/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>