<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Mark,<br>
    <br>
    merged & checked & flashed & works :-)<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Am 18.11.2012 13:38, schrieb Mark
      Webb-Johnson:<br>
    </div>
    <blockquote
      cite="mid:068C2C4F-8DE2-4011-9C2F-0AA522CFC218@webb-johnson.net"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      Michael,
      <div><br>
      </div>
      <div>I've just pushed my last set of changes. It seems ok from my
        end now. The code runs and sms commands function as expected.
        I've added a capabilities message that is sent
        car->server->apps and will be useful to tailor the app
        functions to what the car can do.</div>
      <div><br>
      </div>
      <div>Can you merge mine in with yours, and check if it all looks
        ok to you?</div>
      <div><br>
      </div>
      <div>I'm now going to flash this firmware into my car to see how
        it behaves.</div>
      <div><br>
      </div>
      <div>Regards, Mark.</div>
      <div><br>
        <div>
          <div>On 18 Nov, 2012, at 8:11 PM, Michael Balzer <<a
              moz-do-not-send="true" href="mailto:dexter@expeedo.de">dexter@expeedo.de</a>>
            wrote:</div>
          <br class="Apple-interchange-newline">
          <blockquote type="cite">
            <meta content="text/html; charset=ISO-8859-1"
              http-equiv="Content-Type">
            <div bgcolor="#FFFFFF" text="#000000"> Mark,<br>
              <br>
              I reworked my command dispatcher according to the new
              hook:<br>
              <br>
              <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/ca453ca07714ec43bc884e9598d781a0e2af4f3f">https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/ca453ca07714ec43bc884e9598d781a0e2af4f3f</a><br>
              <br>
              ...it works, but I'm not totally happy with it. To me it
              looks like there should be no need for two hooks.
              Basically the only difference between them now is, if the
              vehicle handler has to do the auth check or not. So I
              internally already use one dispatcher and a control
              parameter for this. If it needs to do the auth check, I
              use the same mode control scheme like you do. Please have
              a look at it, maybe we can reduce this to one hook.<br>
              <br>
              My STAT command drops the charge mode (the Twizy does not
              have this) and inserts SOC min+max after current SOC, so
              that's a replacement case. But I added another command
              handler that's clearly an extension (HELP), and with my
              new specific DEBUG command we now have all three cases,
              and all work as designed (at least in diag mode, have to
              test live mode yet).<br>
              <br>
              Regards,<br>
              Michael<br>
              <br>
              <br>
              <div class="moz-cite-prefix">Am 18.11.2012 09:49, schrieb
                Mark Webb-Johnson:<br>
              </div>
              <blockquote
                cite="mid:75818E41-1A24-4A10-BEBB-212AD57104E7@webb-johnson.net"
                type="cite">
                <meta http-equiv="Content-Type" content="text/html;
                  charset=ISO-8859-1">
                Michael,
                <div><br>
                </div>
                <div>I think there is a confusion around the use
                  of vehicle_fn_smshandler - that is to override
                  (premsg) or extend (!premsg) an existing SMS command.
                  I hadn't thought about the vehicle module wanting its
                  own SMS messages.</div>
                <div><br>
                </div>
                <div>We can do this in two ways: (1) expose a vehicle
                  sms handler table to the net_sms code and have it look
                  there, or (2) just hook in to the vehicle and let it
                  handle sms messages itself. For the moment, I've
                  chosen (2) as I think there will be relatively few
                  vehicle-specific sms messages. The old way we did this
                  was just 'strcmp' for each possible SMS commands. If
                  there are not too many, that is fine and probably more
                  efficient than having a dispatch table. Anyway, I've
                  added a vehicle_fn_smsextensions now, which is called
                  if the incoming sms is not recognised by net_sms and
                  allows the vehicle to look.</div>
                <div><br>
                </div>
                <div>Michael B: can you try to migrate your Twizy code
                  to this new vehicle_fn_smsextensions framework for
                  Twizy-specific sms messages, and vehicle_fn_smshandler
                  for the extension to the STAT command? Regarding
                  your vehicle_twizy_sms_handle_stat() function, is it
                  not possible to just extend (add a couple of lines)
                  the SMS reply, rather than replace the entire command?</div>
                <div><br>
                </div>
                <div>I also tested the new net_sms arrangement, found a
                  few bugs, and fixed them. Code is on github now.</div>
                <div><br>
                </div>
                <div>I'm now looking at implementing a registration
                  mechanism so that the vehicle modules can register the
                  commands they implement, as well as other parameters
                  for what they support, and we can push this in net_msg
                  when we connect to the server.</div>
                <div><br>
                </div>
                <div>Regards, Mark.</div>
                <div><br>
                  <div>
                    <div>On 18 Nov, 2012, at 4:38 AM, Michael Balzer
                      <<a moz-do-not-send="true"
                        href="mailto:dexter@expeedo.de">dexter@expeedo.de</a>>

                      wrote:</div>
                    <br class="Apple-interchange-newline">
                    <blockquote type="cite">
                      <meta content="text/html; charset=ISO-8859-1"
                        http-equiv="Content-Type">
                      <div bgcolor="#FFFFFF" text="#000000"> Mark,<br>
                        <br>
                        I ported my STAT changes to the new framework
                        and tried to prepare it for my first specific
                        commands as well:<br>
                        <br>
                        <a moz-do-not-send="true"
                          class="moz-txt-link-freetext"
href="https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/7b050c4dd92045d62bce3315122ac496c5d305c6">https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/7b050c4dd92045d62bce3315122ac496c5d305c6</a><br>
                        <br>
                        Haven't tested yet, but the vehicle / framework
                        distinction becomes very clean now I think.<br>
                        <br>
                        Regarding hooking in the vehicle cmdtable: I now
                        think that was nonsense, as the vehicle
                        dispatcher will need to parse the command
                        itself. I'll wait for your thoughts on if/how to
                        integrate the common auth stuff with this.<br>
                        <br>
                        To get internal net_sms_stat() calls to use the
                        overloaded function, I suggest to inject the
                        call through the SMS dispatcher as shown in my
                        commit. There's only one call outside net_sms,
                        and that's not time critical and using fixed
                        (no) arguments. I also think STAT is the only
                        SMS we need to route like this (?)<br>
                        <br>
                        Regards,<br>
                        Michael<br>
                        <br>
                      </div>
                    </blockquote>
                  </div>
                </div>
              </blockquote>
              <br>
              <pre class="moz-signature" cols="72">-- 
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
</pre>
            </div>
            <span><dexter.vcf></span>_______________________________________________<br>
            OvmsDev mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>
            <a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
</pre>
  </body>
</html>