<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Fixed: was a ROM/RAM thing.<br>
    <br>
    Not really looking like good code now though:<br>
    <br>
                  {<br>
                    char cmd[5];<br>
                    strcpypgm2ram(cmd, "STAT");<br>
                    net_sms_in(p, cmd, 4);<br>
                  }<br>
    <br>
    Maybe there's a common better way for this? If we need more internal
    commands to be routed through the dispatcher, a net_sms_in_rom()
    function could make it nice again.<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    PS: the first bug fix (previous commit) still makes sense.<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Am 18.11.2012 16:56, schrieb Michael
      Balzer:<br>
    </div>
    <blockquote cite="mid:50A90513.9050808@expeedo.de" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      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 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>