<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
There are now two new metrics class templates:<br>
<br>
- OvmsMetricBitset<N><br>
- OvmsMetricSet<ElemType><br>
<br>
Both use the string representation as mentioned (i.e. "3,7,12"). On
the Bitset class, bit positions are numbered beginning at 1 to
provide a "human" interface.<br>
<br>
<tt>OVMS > metrics list pack</tt><tt><br>
</tt><tt>x.rt.b.pack.1.temp.alerts </tt><tt><br>
</tt><tt>x.rt.b.pack.1.temp.stddev.max 0.495093°C</tt><tt><br>
<b>
</b></tt><b><tt>x.rt.b.pack.1.temp.watches 1,3,5</tt></b><tt><br>
</tt><tt>x.rt.b.pack.1.voltage.alerts </tt><tt><br>
</tt><tt>x.rt.b.pack.1.voltage.max 56.2V</tt><tt><br>
</tt><tt>x.rt.b.pack.1.voltage.min 56.2V</tt><tt><br>
</tt><tt>x.rt.b.pack.1.voltage.stddev.max 0.00395285V</tt><tt><br>
<b>
</b></tt><b><tt>x.rt.b.pack.1.voltage.watches 1,13,14</tt></b><tt><br>
</tt><tt>x.rt.b.pack.cnt 1</tt><tt><br>
</tt><br>
<br>
I recommend using the bitset class where possible:<br>
<br>
The std::set class has a memory overhead similar to std::map, it
also uses btrees to provide fast member lookups. So any new member
added to the set will allocate a chunk of at least 16 bytes of RAM.<br>
<br>
The std::bitset class is basically just a wrap around a standard bit
field, needing no more memory than the bits + metrics overhead.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 24.10.2017 um 02:38 schrieb Mark
Webb-Johnson:<br>
</div>
<blockquote type="cite"
cite="mid:5243E001-69BF-4AF0-9861-7B20D4C3E863@webb-johnson.net">
<pre wrap="">That approach seems fine.
Regards, Mark
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap="">On 23 Oct 2017, at 10:25 PM, Michael Balzer <a class="moz-txt-link-rfc2396E" href="mailto:dexter@expeedo.de" moz-do-not-send="true"><dexter@expeedo.de></a> wrote:
Am 09.10.2017 um 03:17 schrieb Mark Webb-Johnson:
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap="">The issue is that for the MQTT and GATT protocols (generic IoT style), we need to provide granular updates. It just seems simpler to store things in that way in the first place. That way, the MQTT and GATT code in OVMS v3 can just publish all metrics in the same way - no need for per-metric logic. It is also trivial then to add per-vehicle custom metrics, as necessary.
</pre>
</blockquote>
<pre wrap="">That's clear for single flags with isolated semantics like "key on".
How about collections of semantically coupled flags?
I.e. how about battery cell voltage / temperature alert flags?
I would normally map these flags to a string metric with set syntax,
i.e. "3,7,12" to reflect active alerts on cells 3, 7 & 12.
That would still be a granularly updatable metric, happening to
transport structured information. As a client only interested in an
alert status change, I can subscribe to this single attribute.
Conversion to JSON can also be done by simply adding brackets.
If that makes sense, I'll have a look at adding some sort of
OvmsMetricsSet class for these cases -- I've been working on the metrics
module anyway.</pre>
</blockquote>
</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>