<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Probably best to double-check in the iOS and Android Apps for what they use.<div class=""><br class=""></div><div class="">For iOS, all I see is a check for chargesubstate == 0x07. Same for Android.</div><div class=""><br class=""></div><div class="">I think it is ok just to use those substates for the moment. Long-term, we don’t really want/need this substate metric anyway.</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 7 Nov 2017, at 6:01 AM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252" class="">
  
  <div text="#000000" bgcolor="#FFFFFF" class="">
    I've just pushed a rework of the v2 stat message including some more
    metrics and automatic code/key translations for charge state &
    mode.<br class="">
    <br class="">
    It works well on my test vehicle. The translation utilities can also
    be used to set the code metrics if you stick to the integer keys
    internally.<br class="">
    <br class="">
    Still missing is the substate. From the v2 code it can have these
    values:<br class="">
    <br class="">
    - 0 = undefined<br class="">
    - 1 = charge stop request<br class="">
    - 3 = charging by request<br class="">
    - 7 = cable not connected<br class="">
    - 14 = charge interrupted<br class="">
    <br class="">
    That's a bit mixed scope… are these all substates to support?<br class="">
    <br class="">
    Regards,<br class="">
    Michael<br class="">
    <br class="">
    <br class="">
    <div class="moz-cite-prefix">Am 06.11.2017 um 18:37 schrieb Michael
      Balzer:<br class="">
    </div>
    <blockquote type="cite" cite="mid:defb3376-1a32-7aaf-395a-1691be9305f4@expeedo.de" class="">
      <blockquote type="cite" style="color: #333333;" class="">
        <blockquote type="cite" style="color: #333333;" class="">
          <blockquote type="cite" style="color: #333333;" class="">
            <pre wrap="" class="">I also sent another pull request for a minimal implementation of the charger state related values in the v2 protocol, and some small leaf fixes.
</pre>
          </blockquote>
        </blockquote>
        <pre wrap="" class="">This pull request ( <a class="moz-txt-link-freetext" href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/7" moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/7</a> ) is still outstanding
</pre>
      </blockquote>
      <pre wrap="" class="">I think deriving the car_chargestate string from the charge flags is not correct. We've currently got…

    OvmsMetricString* ms_v_charge_state;      // charging, topoff, done, preparing, heating, stopped
    OvmsMetricString* ms_v_charge_mode;       // standard, range, performance, storage
    OvmsMetricString* ms_v_charge_substate;   // tba...

…but no longer their numerical equivalences as metrics -- assuming they are no longer necessary. Are they? I.e. do we need the numerical values other than for
the old V2 protocol?

I'd else translate the old codes to their old numerical values just for the "S" msg.

</pre>
    </blockquote>
    <br class="">
    <pre class="moz-signature" cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
  </div>

_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></div></body></html>