<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    One bug just turned up: I have my module send both SMS and IP
    alerts. On charge end, the IP stat alert was correct, but the SMS
    alert was also delivered to my App, and displays as "SMS FROM:
    <nr> - MSG: <random_char_garbage>.<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Am 18.11.2012 14:14, schrieb Michael
      Balzer:<br>
    </div>
    <blockquote cite="mid:50A8DF52.2020409@expeedo.de" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      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 moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a moz-do-not-send="true" 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>
      <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>