[Ovmsdev] Nissan Leaf Support Request

Mark Webb-Johnson mark at webb-johnson.net
Thu Jul 12 08:56:25 HKT 2018


I think the capabilities are useful, but need to be done in a better, more future-proof, way. Relying on protocol v2 commands is limited.

Here is what it was in OVMS v2:

$ fgrep '_capabilities[' ve*
vehicle_kiasoul.c:rom char vehicle_kiasoul_capabilities[] = "C6,C20-24";
vehicle_nissanleaf.c:rom char nissanleaf_capabilities[] = "C11,C24,C26";
vehicle_teslaroadster.c:rom char teslaroadster_capabilities[] = "C10-12,C15-24";
vehicle_twizy.c:rom char vehicle_twizy_capabilities[] = "C6,C20-24,C200-210";
vehicle_twizy.c:rom char vehicle_twizy_capabilities[] = "C6,C20-24,C200-204,C207-210";
vehicle_zoe.c:rom char vehicle_zoe_capabilities[] = "";

The iOS App doesn’t seem to use them at all, but Android App has some support. From what I can see, the Android App stores the capabilities in a boolean array, and then exposes a hasCommand() function to check a particular capability. But a fgrep for hasCommand in the Android App only shows one pCarData.hasCommand(26), which is what is controlling this remote climate control. I don’t think any capability other than C26 is currently used by the standard Apps.

Capabilities should probably be published as a metric, with a textual representation of commands supported. We could convert those standard commands quite easily (so for example ‘valet’ would translate to ‘C21,C23’ for protocol vs, and ‘homelink’ to C24, etc). I don’t think we need to handle the non-standard ones like C200-210’ for protocol v2.

My suggestion is:

Create a standard metric ‘v.capabilities’.
Have the vehicle modules set that metric with their capabilities, as a comma-separated list of the commands supported:
chargemode
chargestart
chargestop
chargecurrent
chargetimer
wakeup
lock
valet
homelink
cooldown
climate
x*
For server v2, generate a capabilities message (MP-0 V) based on those standardised names (no x* support), mapping names to capability numbers.
Server v3 doesn’t need to do anything, as that v.capabilities metric will automatically get propagated.
No change to the v2 protocol apps (although future apps should use these).

Is that ok? If no objections, I can make these (relatively simple) changes and then the cars themselves can implement. For the current Apps, only C26 is needed anyway, and that is only used by the Nissan Leaf (which would just need to set StandardMetrics.ms_v_capabilities during vehicle module initialisation, or more smartly based on model year, etc). The other vehicles can change at a later time (no hurry), or I can just change them based on the v2 capabilities.

Regards, Mark.

> On 12 Jul 2018, at 12:26 AM, Tom Parker <tom at carrott.org> wrote:
> 
> 
> 
> On 11/07/18 23:25, Robin O'Leary wrote:
>> On Thu, Jul 05, 2018 at 08:34:34PM +1200, Tom Parker wrote:
>>> You want to use the play store version. I'm running 3.12.4 from the Play
>>> store and when connected to a Leaf, I see the AC button.
>> I updated the app to 3.12.4.(20180428), but it looks the same as before;
>> I don't see an AC button.  What am I missing?
>> 
> 
> The AC button is controlled by the capabilities message which, it turns out, isn't implemented in OVMS v3. I think the server is sending _my_ clients a capabilities message because, I guess, at one stage I sent one to the server (probably by connecting an OVMS v2 module).
> 
> In OVMS v2 the Nissan Leaf module has:
> 
> // Nissan Leaf capabilities:
> // - CMD_StartCharge (11)
> // - CMD_Homelink (24)
> // - CMD_ClimateControl (26)
> rom char nissanleaf_capabilities[] = "C11,C24,C26";
> 
> and reading the code in net_msg.c, it looks like the capabilities message for a Leaf would be
> 
> MP-0 VC11,C24,C26,C1-6,C40-41,C49
> 
> which is what the server sends me when I connect a client to my vehicles.
> 
> The following untested patch should make it work, but is obviously inappropriate because the capabilities depend on the vehicle.
> 
> 
> diff --git a/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp b/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp
> index faa2e6c..6e9d28f 100644
> --- a/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp
> +++ b/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp
> @@ -1272,6 +1272,7 @@ void OvmsServerV2::TransmitMsgEnvironment(bool always)
>  void OvmsServerV2::TransmitMsgCapabilities(bool always)
>    {
>    m_now_capabilities = false;
> +  Transmit("MP-0 VC11,C24,C26,C1-6,C40-41,C49");
>    }
> 
>  void OvmsServerV2::TransmitMsgGroup(bool always)
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180712/da8565b3/attachment.html>


More information about the OvmsDev mailing list