<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="">The order I suggested was loosely based on trying to maintain connectivity (even if a module is causing a crash). I’ve put the least used modules (or those not related to connectivity) at the bottom of the list, and the most critical modules (but hopefully most reliable) at the top.<div class=""><br class=""></div><div class="">Currently, Server V3 should be at the bottom, but I am hoping it will improve in reliability. Perhaps it should be after SIMCOM for the moment.</div><div class=""><br class=""></div><div class="">The idea behind putting external 12v reasonable high (before vehicle) was (a) it is highly unlikely to cause us any issues, and (b) external displays may provide status and other indications useful to identify problems. It could probably swap with ‘vehicle’, without much impact.</div><div class=""><br class=""></div><div class="">Regards, Mark.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 28 Aug 2018, at 1:45 AM, Greg D. <<a href="mailto:gregd2350@gmail.com" class="">gregd2350@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
  
  <div text="#000000" bgcolor="#FFFFFF" class="">
    Hi Mark,<br class="">
    <br class="">
    The new proposal sounds like a good idea (in spite of putting
    OBD2ECU at the bottom {sniff} ).  If we someday get the ability to
    configure the module from the Modem, would it be a good idea to move
    SIMCOM up in the priority chain, to allow for remote repair if
    either of the servers is causing the trouble?  The V2 server has
    been pretty stable for a long time, but I wonder about V3.<br class="">
    <br class="">
    Curious why you put External 12v above OBD2ECU.  I'd move 12v to the
    bottom, so you don't turn on the external device until the server is
    running.  What else is dependent on the external 12v supply?<br class="">
    <br class="">
    Greg<br class="">
    <br class="">
    <br class="">
    <div class="moz-cite-prefix">Mark Webb-Johnson wrote:<br class="">
    </div>
    <blockquote type="cite" cite="mid:83CF5C1A-C18D-4791-961F-529144DD4A31@webb-johnson.net" class="">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
      Last week’s 3.1.009 issue with Tesla Roadsters was interesting.
      Looking at the car I saw with the problem, it was booting,
      crashing when the vehicle module received a certain CAN bus
      message (triggering the issue), and rebooting. It would do this 5
      times, until it his the AUTO_INIT_INHIBIT_CRASHCOUNT count, and
      then AutoInit inhibit would kick in, and it would end up sitting
      idle with nothing loaded (and no network connection). The approach
      worked very well, and prevented an endless reboot loop.
      <div class=""><br class="">
        <div class="">However, we ended up with a car unable to connect
          to the network, and requiring a console cable and laptop to
          recover. I’ve been thinking about bluetooth (which is intended
          to provide a smartphone connection irrespective of wifi
          configuration), how that might work with a completely
          unconfigured module (for initial configuration), and I can
          suggest a workaround to try to improve this…</div>
      </div>
      <div class=""><br class="">
      </div>
      <div class="">At the moment, the order of autoinit is:</div>
      <div class=""><br class="">
      </div>
      <div class="">
        <ol class="MailOutline">
          <li class="">External 12V</li>
          <li class="">Wifi</li>
          <li class="">Modem SIMCOM</li>
          <li class="">Vehicle</li>
          <li class="">OBD2ECU</li>
          <li class="">Server V2</li>
          <li class="">Server V3</li>
        </ol>
      </div>
      <div class=""><br class="">
      </div>
      <div class="">None of those run if the early crash count >
        AUTO_INIT_INHIBIT_CRASHCOUNT (coded as a constant 5).</div>
      <div class=""><br class="">
      </div>
      <div class="">My suggestion is to change this as follows:</div>
      <div class=""><br class="">
      </div>
      <div class="">
        <ol class="MailOutline">
          <li class="">Wifi</li>
          <li class="">Bluetooth</li>
          <li class="">Server V2</li>
          <li class="">Server V3</li>
          <li class="">Modem SIMCOM</li>
          <li class="">External 12V</li>
          <li class="">Vehicle</li>
          <li class="">ODB2ECU</li>
        </ol>
      </div>
      <div class=""><br class="">
      </div>
      <div class="">But also to change that logic that:</div>
      <div class="">
        <ul class="MailOutline">
          <li class="">#8 will start if early crash count >
            AUTO_INIT_INHIBIT_CRASHCOUNT</li>
          <li class="">#7 will start if early crash count >
            AUTO_INIT_INHIBIT_CRASHCOUNT+1</li>
          <li class="">#6 will start if early crash count >
            AUTO_INIT_INHIBIT_CRASHCOUNT+2</li>
          <li class="">etc.</li>
        </ul>
      </div>
      <div class=""><br class="">
      </div>
      <div class="">This will mean that once we hit the
        AUTO_INIT_INHIBIT_CRASHCOUNT limit, we turn off the least
        required module (OBD2ECU), then continue to see if that solves
        the problem. If not (ie; we crash and reboot), then we try
        turning off the Vehicle module and OBD2ECU, then continue to see
        if that solves the problem. etc.</div>
      <div class=""><br class="">
      </div>
      <div class="">In the example case of the Tesla Roadster vehicle
        module causing the issue, this revised approach would leave us
        up and running with Wifi and a Server Connection (but no vehicle
        data). Checking the module would identify the problem quite
        quickly (and remotely). Starting the vehicle module manually
        would presumably result in a crash and we would pretty quickly
        get an idea of the cause (especially if we added a command to
        show the status of AutoInit, what was started, and what wasn’t
        because it is causing a crash). I think we could even issue an
        Alert notification in the case where autoinit recovered after
        inhibiting certain modules (but not all).</div>
      <div class=""><br class="">
      </div>
      <div class="">The disadvantage is that we would crash more (up to
        13 times, vs 5) in the case the system is badly messed up.</div>
      <div class=""><br class="">
      </div>
      <div class="">What do people think? Does this make sense?</div>
      <div class=""><br class="">
      </div>
      <div class="">Regards, Mark.</div>
      <div class=""><br class="">
      </div>
      <br class="">
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br class="">
      <pre wrap="" class="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
    </blockquote>
    <br class="">
  </div>

_______________________________________________<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></blockquote></div><br class=""></div></body></html>