<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Mark,<br>
    <br>
    I also had quite some user feedback to process over here. I could
    get some of them to send versions, backtraces and logs, very
    helpful.<br>
    <br>
    Current remaining main issues:<br>
    <ul>
      <li>Mongoose crash after STA disconnect in AP+Client mode (issue
        #45)</li>
      <li>OTA (http download) via modem<br>
      </li>
      <li>SD logging affects overall performance badly, leading to
        failures of time critical functions</li>
      <li>Server v2 crash on modem connection loss (got two user logs on
        this today, will check this now)</li>
      <li>Memory loss can still happen (I've some new clues on this,
        will check later)<br>
      </li>
    </ul>
    Also, I'm not sure the websocket queue lock issue is solved yet. It
    didn't occur for me in a while, but I've seen it in user logs, need
    to check their circumstances.<br>
    <br>
    <br>
    I second the need for a fool proof setup procedure.<br>
    <br>
    We can track the setup state in a config instance, so it doesn't
    matter if the wifi mode switch needs a reconnect -- or the module
    crashes, or the user unplugs it in the process.<br>
    <br>
    Fools can't handle complex pages with multiple issues, so the setup
    wizard should perform the parts and tests in series if possible.
    Probably mainly a UI issue, I think about maybe an accordion for
    this.<br>
    <br>
    Do we need to include the DNS in the wizard? I think we can use a
    default and let the user change that later. Or is there no public
    DNS that is accessable from everywhere?<br>
    <br>
    Also, as the vehicle type is fundamental, it should not be under the
    "use server v2" option.<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Am 23.04.2018 um 10:44 schrieb Mark
      Webb-Johnson:<br>
    </div>
    <blockquote type="cite"
      cite="mid:8EDE0C38-692B-4FD0-808B-1B54F1EC6746@webb-johnson.net">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div class=""><br class="">
      </div>
      Well, it has been an interesting few weeks as the first production
      batch of OVMS v3 came online. I don’t know about for others
      helping out with support tickets, but I’ve sure learned a lot -
      especially about what can go wrong for inexperienced users trying
      to setup a complex product. 14 support tickets were opened, along
      with another perhaps 6 calls for help via other means, and here
      are the most common problems encountered:
      <div class=""><br class="">
      </div>
      <div class="">
        <ul class="MailOutline">
          <li class="">Switched from Access Point mode to Client mode,
            and lost access.</li>
          <li class="">Can’t get into module via USB (drivers seem ok,
            but terminal emulators, and baud rates, are beyond most
            people’s understanding).</li>
          <li class="">Too hard for most to do a factory reset.</li>
          <li class="">Can’t see modem ICCID when powered off.</li>
          <li class="">Modem powered off by default, unless the little
            tick box is clicked.</li>
          <li class="">Server v2 off by default, unless the little tick
            box is clicked.</li>
          <li class="">Upper vs lower case on command execution.</li>
          <li class="">Unable to do firmware update in Access Point
            mode.</li>
          <li class="">Password confusion (wifi client vs module vs
            server vehicle vs server account vs access point vs OVMSinit
            vs etc etc).</li>
          <li class="">wifi vs modem switches and DNS settings.</li>
          <li class="">Modem SIM registration issues (can’t see, or
            don’t know how to see, status of simcom).</li>
          <li class="">Don’t understand how to check status.</li>
        </ul>
      </div>
      <div class=""><br class="">
      </div>
      <div class="">While some of these issues have been addressed, I am
        reluctant to release a new batch of modules to the world,
        especially this time with less technically capable users coming
        online.</div>
      <div class=""><br class="">
      </div>
      <div class="">It is probably not ‘fun’ work, but I think we can
        make this much simpler for new users. We can lead them through
        the setup in the following stages:</div>
      <div class=""><br class="">
      </div>
      <div class="">
        <ol class="MailOutline">
          <li class="">Require, as a pre-requisite, users to initially
            setup the module within range of a home wifi / cellular
            hotspot connection.<br class="">
            <br class="">
          </li>
          <li class="">Factory default, use Access Point mode, SSID OVMS
            password “OVMSinit”, and no module password. Have them
            connect to the module over wifi Access Point, and <a
              href="http://192.168.4.1/" class="" moz-do-not-send="true">http://192.168.4.1/</a>.<br
              class="">
            <br class="">
          </li>
          <li class="">The web interface then shows them a list of WiFi
            access points in range, and asks them to choose one and
            enter the password for that access point (clearly labelled
            as SSID, and "<SSID> Password”).<br class="">
            <br class="">
          </li>
          <li class="">The module then reconfigures as Client + Access
            Point mode, and tries to connect to the client wifi, as well
            as keeping the access point connection open. If not ok, tell
            them and go back to #3 for them to try again.<br class="">
            <br class="">
          </li>
          <li class="">When ok, proceed to ask them to update the
            firmware. This will do a simple OTA download over HTTP, then
            reboot.<br class="">
            <br class="">
          </li>
          <li class="">When back up, in one screen ask them to enter all
            the details for their network, and configure appropriately:</li>
          <ul class="">
            <li class="">Use Wifi?</li>
            <ul class="">
              <li class="">WiFi Mode (AccessPoint+SpecificClient, or
                ScanningClient)</li>
              <li class="">OVMS Access Point SSID</li>
              <li class="">New OVMS Access Point password (as OVMSinit
                is insecure beyond initial setup)</li>
            </ul>
            <li class="">DNS (default: google, or custom)</li>
            <li class="">Module password (as default empty is insecure
              beyond initial setup)</li>
            <li class="">Use OVMS Server v2?</li>
            <ul class="">
              <li class="">Vehicle type</li>
              <li class="">Vehicle ID</li>
              <li class="">Vehicle Server password</li>
              <li class="">Vehicle server (openvehicles, dexter, or
                custom)</li>
            </ul>
            <li class="">Use modem?</li>
            <ul class="">
              <li class="">Modem APN, username and password (default:
                hologram)<br class="">
                <br class="">
              </li>
            </ul>
          </ul>
          <li class="">Test each of the above, and show them the
            results. Set auto appropriately, and disable quickstart then
            reboot.</li>
        </ol>
      </div>
      <div class=""><br class="">
      </div>
      <div class="">The point is to lead them through each of the steps,
        test each setting and show them the result.</div>
      <div class=""><br class="">
      </div>
      <div class="">Technically, my only concern is the switch from AP
        to AP+client mode and whether the existing wifi connection will
        die or survive the channel switch. We also have to do a wifi
        scan, in Access Point mode, but I think we can do that by just
        temporarily turning off access point or doing it before the
        access point is brought up. Both these will depend on how ESP32
        handles it.</div>
      <div class=""><br class="">
      </div>
      <div class="">I’m happy to do a lot (if not all) of the above, but
        will definitely need help with the web side.</div>
      <div class=""><br class="">
      </div>
      <div class="">But, first let’s agree on the proper list of
        questions to ask and flow to follow.</div>
      <div class=""><br class="">
      </div>
      <div class="">Regards, Mark.</div>
      <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>