[Ovmsdev] Leaf 2016 30Kwh flapping SOC

[Mark Webb-Johnson]

> 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?

I wouldn’t bother with v2. Just create the v3 metric as vehicle-specific.

Over the coming months, the bluetooth GATT client will come, and v3 MQTT support, as well as App support for v3 MQTT and GATT. I’m not intending to work any more on the v2 App.

Regards, Mark.

> On 7 May 2018, at 8:03 PM, Tom Parker <tom at carrott.org> wrote:
> 
> 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?
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev