[Ovmsdev] V3 set metrics

[Michael Balzer]

There are now two new metrics class templates:

- OvmsMetricBitset<N>
- OvmsMetricSet<ElemType>

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.

OVMS > metrics list pack
x.rt.b.pack.1.temp.alerts              
x.rt.b.pack.1.temp.stddev.max            0.495093°C
***x.rt.b.pack.1.temp.watches               1,3,5*
x.rt.b.pack.1.voltage.alerts           
x.rt.b.pack.1.voltage.max                56.2V
x.rt.b.pack.1.voltage.min                56.2V
x.rt.b.pack.1.voltage.stddev.max         0.00395285V
***x.rt.b.pack.1.voltage.watches            1,13,14*
x.rt.b.pack.cnt                          1


I recommend using the bitset class where possible:

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.

The std::bitset class is basically just a wrap around a standard bit
field, needing no more memory than the bits + metrics overhead.

Regards,
Michael


Am 24.10.2017 um 02:38 schrieb Mark Webb-Johnson:
> That approach seems fine.
>
> Regards, Mark
>
>> On 23 Oct 2017, at 10:25 PM, Michael Balzer <dexter at expeedo.de> wrote:
>>
>>
>> Am 09.10.2017 um 03:17 schrieb Mark Webb-Johnson:
>>> 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.
>> 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.

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20171029/48a35331/attachment.htm>