[Ovmsdev] Battery capacity metrics (for the Leaf, and in general)

[Robin O'Leary]

On Tue, Feb 26, 2019 at 05:29:18AM +0000, Anko Hanse wrote:
> Good news: retested after a drive and the xnl.v.b.e.available corrected itself to the expected 30kwh !
> Will keep an eye on it over the next weeks to make sure it is not one of these multiplexed thingies that switches in and out of the expected value....

Thanks for the feedback; it is interesting.  It gives me confidence that
xnl.v.b.e.available is useful for both battery sizes, but unfortunately
xnl.v.b.e.capacity is not.  We should continue looking for something
better in the voluminous data returned by 79b/7bb queries.

> Bad news: the xnl.v.c.duration.range still are at 4095min for me, even though the SOC has now dropped below 80%. This is on a Dec-2015 30kwh model.

Does your car offer the option to turn "Long life mode (80% charge)"
on and off?  If that is not implemented, it would make sense that the
corresponding estimates are not either.  I'll add a check to ignore
'4095' as an invalid value  ...which reminds me of a coding question
I've been meaning to ask those more familiar with the "metrics" mechanism:

The vehicle modules, including the leaf, create their own metrics
with code like this:

  m_charge_duration_full_l2 = MyMetrics.InitFloat("xnl.v.c.duration.full.l2", SM_STALE_HIGH, 0, Minutes);

However, this also sets an initial value, which may give the false
impression of knowledge where none exists (as with the 30kWh "range"
estimates).  Standard metrics are created differently, with no initial
value:

  ms_v_charge_duration_full = new OvmsMetricInt(MS_V_CHARGE_DURATION_FULL, SM_STALE_MID, Minutes);

Is there any reason why vehicle modules shouldn't also do it this way,
leaving metrics in state NeverDefined until a real value is known?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20190226/c2d49b17/attachment-0002.sig>