<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">Here is what it was in OVMS v2:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">$ fgrep '_capabilities[' ve*</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">vehicle_kiasoul.c:rom char vehicle_kiasoul_capabilities[] = "C6,C20-24";</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">vehicle_nissanleaf.c:rom char nissanleaf_capabilities[] = "C11,C24,C26";</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">vehicle_teslaroadster.c:rom char teslaroadster_capabilities[] = "C10-12,C15-24";</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">vehicle_twizy.c:rom char vehicle_twizy_capabilities[] = "C6,C20-24,C200-210";</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">vehicle_twizy.c:rom char vehicle_twizy_capabilities[] = "C6,C20-24,C200-204,C207-210";</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">vehicle_zoe.c:rom char vehicle_zoe_capabilities[] = "";</span></font></div></div></blockquote><div class=""><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">My suggestion is:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Create a standard metric ‘v.capabilities’.</li><li class="">Have the vehicle modules set that metric with their capabilities, as a comma-separated list of the commands supported:</li><ul class=""><li class="">chargemode</li><li class="">chargestart</li><li class="">chargestop</li><li class="">chargecurrent</li><li class="">chargetimer</li><li class="">wakeup</li><li class="">lock</li><li class="">valet</li><li class="">homelink</li><li class="">cooldown</li><li class="">climate</li><li class="">x*</li></ul><li class="">For server v2, generate a capabilities message (MP-0 V) based on those standardised names (no x* support), mapping names to capability numbers.</li><li class="">Server v3 doesn’t need to do anything, as that v.capabilities metric will automatically get propagated.</li><li class="">No change to the v2 protocol apps (although future apps should use these).</li></ul></div><div class=""><br class=""></div><div class="">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.</div></div><div class=""><div class=""><br class=""></div><div class="">Regards, Mark.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 12 Jul 2018, at 12:26 AM, Tom Parker <<a href="mailto:tom@carrott.org" class="">tom@carrott.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><br class="">On 11/07/18 23:25, Robin O'Leary wrote:<br class=""><blockquote type="cite" class="">On Thu, Jul 05, 2018 at 08:34:34PM +1200, Tom Parker wrote:<br class=""><blockquote type="cite" class="">You want to use the play store version. I'm running 3.12.4 from the Play<br class="">store and when connected to a Leaf, I see the AC button.<br class=""></blockquote>I updated the app to 3.12.4.(20180428), but it looks the same as before;<br class="">I don't see an AC button. What am I missing?<br class=""><br class=""></blockquote><br class="">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).<br class=""><br class="">In OVMS v2 the Nissan Leaf module has:<br class=""><br class="">// Nissan Leaf capabilities:<br class="">// - CMD_StartCharge (11)<br class="">// - CMD_Homelink (24)<br class="">// - CMD_ClimateControl (26)<br class="">rom char nissanleaf_capabilities[] = "C11,C24,C26";<br class=""><br class="">and reading the code in net_msg.c, it looks like the capabilities message for a Leaf would be<br class=""><br class="">MP-0 VC11,C24,C26,C1-6,C40-41,C49<br class=""><br class="">which is what the server sends me when I connect a client to my vehicles.<br class=""><br class="">The following untested patch should make it work, but is obviously inappropriate because the capabilities depend on the vehicle.<br class=""><br class=""><br class="">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<br class="">index faa2e6c..6e9d28f 100644<br class="">--- a/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp<br class="">+++ b/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp<br class="">@@ -1272,6 +1272,7 @@ void OvmsServerV2::TransmitMsgEnvironment(bool always)<br class=""> void OvmsServerV2::TransmitMsgCapabilities(bool always)<br class=""> {<br class=""> m_now_capabilities = false;<br class="">+ Transmit("MP-0 VC11,C24,C26,C1-6,C40-41,C49");<br class=""> }<br class=""><br class=""> void OvmsServerV2::TransmitMsgGroup(bool always)<br class=""><br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></div></blockquote></div><br class=""></div></div></body></html>