<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    As those users also will not be able to enter "config" commands, I
    don't see another option than to enable wifi AP mode with a default
    password.<br>
    <br>
    We can read the "factoryreset.txt" file contents and use the first
    line as the module password, but that doesn't catch the factory
    reset by S2.<br>
    <br>
    I have pushed the change. After a factory reset the module now
    starts with wifi mode AP, network "OVMS" and password "OVMSinit".<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Am 15.04.2018 um 17:24 schrieb Michael
      Balzer:<br>
    </div>
    <blockquote type="cite"
      cite="mid:11c6f668-ab53-f537-2b28-7194dc70f897@expeedo.de">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      Reality has proven we need some simple way to do a factory reset,
      we've got users that don't know how to use a serial USB terminal.<br>
      <br>
      I've implemented the button and SD card methods discussed earlier.<br>
      <br>
      To do a factory reset you can now alternatively to using "module
      factory reset"…<br>
      <ul>
        <li>a) Insert an SD card that has a file "factoryreset.txt" in
          the root directory. The file will be erased, as will be your
          configuration.<br>
        </li>
        <li>b) Open the module, remove any SD card, power the module up,
          wait for 2-3 seconds until boot has finished, then push and
          hold SW2 for 10 seconds.<br>
        </li>
      </ul>
      The SD card needs to be remove for method b because SW2 grounds
      SD_DATA0 as well. Besides the slight chance to trigger 10 false
      readings from a running transmission, I also found the SD driver
      to be unforgiving about pushing SW2 during a transfer. It will
      eventually lock up the module completely needing a hard reboot. So
      it's better to require SD removal for this method.<br>
      <br>
      Regards,<br>
      Michael<br>
      <br>
      <br>
      <div class="moz-cite-prefix">Am 22.02.2018 um 07:30 schrieb Greg
        D.:<br>
      </div>
      <blockquote type="cite"
        cite="mid:eec7772b-b475-e638-d814-aecd8a5dee68@gmail.com">
        <pre wrap="">Ha, good thought!  Put a text file in the root directory named
"factoryreset.txt" containing "OVMSv3" as a key, stick it in, and power
up.  Done.  Brilliant.

It probably should remove said file once the config is cleared, as a
fail-safe.  Don't want it to act as a poison pill.

Only "gotcha" is that finding things that can write to a micro SD card
is becoming harder.  No to the iPhone.  Also my latest Android, though
it does have an OTG adapter so I can get there with a USB reader.  The
ecosystem is trying to force storage to a (paid, data mine-able) cloud,
I think, using space and cost savings as a ruse.

Greg


Mark Webb-Johnson wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">The other option is SD CARD.

Firmware update can work that way. Put an ovms3.bin in the root of an SD card, plug it in, and it will be auto-flashed to update firmware.

We could have special files on SD CARD doing certain things. Like safe boot. Factory reset. Wifi AP. etc.

Can we write an SD CARD from an iPad? :-)

Regards, Mark.

</pre>
        </blockquote>
      </blockquote>
      <br>
      <div class="moz-cite-prefix">Am 22.02.2018 um 06:22 schrieb Greg
        D.:<br>
      </div>
      <blockquote type="cite"
        cite="mid:0256a229-23a7-71bb-58a4-82bf8fc90f87@gmail.com"> We
        have two buttons:
        <blockquote type="cite"
          cite="mid:381BD9B8-E1AE-425A-BD22-44550737E7A7@webb-johnson.net">
          <div class="">
            <ol class="MailOutline">
              <li class="">Hardwired RESET. That resets the chip.</li>
              <li class="">IO0 BOOT. If held during BOOT, that goes into
                firmware download mode.</li>
            </ol>
            So, only #2 is usable, and that only after boot. I guess we
            could have a boot delay to allow time for it to be pressed
            after power up. </div>
        </blockquote>
        Yes, something like that.  I've worked on products where holding
        button #2 after releasing #1 would first take the product into a
        reset-to-defaults mode for about 10 seconds, then if you kept
        holding it after that, would take you to the downloader.<br>
        <blockquote type="cite"
          cite="mid:381BD9B8-E1AE-425A-BD22-44550737E7A7@webb-johnson.net">
          <div class="">
            <div><br class="">
            </div>
            <div>But, that would require opening up the case to get to
              the button. Nasty. Plugging it into a PC is probably
              easier?</div>
          </div>
        </blockquote>
        Hooking to a PC wouldn't necessarily be easier, but certainly
        safer.  I take it that the buttons on the 3.1 hardware aren't
        anywhere that can be accessed through a proverbial paper
        clip-sized hole, nor in such a way that a metal paper clip
        wouldn't be in danger of hitting something live.  Opening my
        box, I see the 3.0 hardware is not set up that way.  The
        switches would need to be moved to the back side of the board
        for that, and the holes put in the case.  Are we too late?<br>
        <br>
        I guess we can assume that our customers are at least somewhat
        technology-literate, and in the event that they lose their AP
        pass key, a USB serial console might be a reasonable way to
        reset things.  But if the only "PCs" they own are a smart phone
        and tablet, or in the event that the module is password
        protected too, use of the buttons would still be required.  Or,
        they can cash in their "phone a friend" token.  :)  PCs aren't
        totally obsolete, yet. </blockquote>
      <br>
      <br>
      <pre class="moz-signature" cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * 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.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>
    <pre class="moz-signature" cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
  </body>
</html>