[Ovmsdev] Leaf 2016 30Kwh flapping SOC

[Tom Parker]

On 07/05/18 00:43, Robin O'Leary wrote:
> What particularly got me thinking along these lines is that I have been
> reading some other metrics directly from the Leaf's own instruments,
> like the distance range and time-to-charge estimates, and again I have
> the problem of where to put them.  There is already code to calculate
> these values independently, and I am sure some people will again prefer
> the results of those calulations over the car's "guess-o-meter".  But it
> seems increasingly ridiculous to repeat the same pattern for every one
> (having two local metrics and a config option for which to display).
> Surely the job of the vehicle code is just to accurately report what
> the car says.

I agree. (Although in the case of the range calculation, the metrics in 
v3 are influenced by those in v2 which are heavily influenced by the 
Tesla Roadster so there are two range metrics displayed in the app: 
estimated and ideal. I put my calculation into one of them and never got 
round to fishing the guess-o-meter off the can bus and putting it into 
the other.)

> If we want to calculate better estimates, that doesn't seem to belong
> in each vehicle module.  For example, both the Kia Soul and Twizy have
> code to apply a temperature correction to the range, but they do it
> differently.  Which way is better?  Is that really a vehicle-specific
> difference, or is it just two independent tries at solving the same
> tricky problem?  I suspect the latter, and that should be done in a more
> centralized place where better techniques can be shared and more easily
> fine tuned.

Agreed. There should be a general algorithm that works for all vehicles 
and if the vehicle is special or to be compatible with some other part 
of the ecosystem (eg to be identical to some aspect of LeafSpy) it can 
be overridden by the vehicle module. Other things that spring to mind 
that might benefit from a shared implementation are Wh/km, charge time 
remaining, trip & charge session statistics.

> Would I be right to think that the original justification for making the
> SOC behaviour configurable is so the scaled-to-new-SOC can be seen on
> the phone app?   If so, then maybe what we are really missing is a way
> to customise which metric(s) should be displayed on the phone app (and
> perhaps other user interfaces like the web status page and dashboard,
> which may have different capablilites).  Looking at a way to add that
> seems like a better way to go than trying to narrowly solve each display
> selection issue one by one in the vehicle code.

Yes, it's working around limitations in the v2 server architecture. 
While it's relatively easy to add new metrics to the v2 protocol, adding 
a vehicle specific metric isn't so easy, as it introduces a dependency 
between the v2 server code and the vehicle module. The v3 server looks 
like it solves this problem as it can send all the metrics regardless of 
whether they are contributed by a vehicle module or are part of the core 
metrics list.

Are we better to wait for the v3 server/client ecosystem and then move 
the configuration from the car module to the client application, or 
should we add a leaf specific metric to the v2 protocol now and put the 
configuration in the client?