<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Mark,<br>
    <br>
    I like the idea of a configurable fail-over to GSM in the event the
    WiFi is not working, even if / when we get the root cause of the
    outages fixed.  But, yes, make it configurable.  WiFi is generally
    free, and GSM is generally not.  It's not going to make the evening
    financial news, but I wouldn't want a wonky WiFi connection to
    trigger a financial surprise or lockout of the GSM account without
    having the user actively decide this is what they want to do.<br>
    <br>
    I've generally had good luck with the WiFi getting and staying
    connected as the car comes and goes.  The AP is about 10m and one
    wall thickness from the car, and the OVMS module is in the passenger
    foot well, under the dash, but I generally get a pair of
    notifications on a roughly daily basis that the top-off charge is
    taking place.  The car is only driven once or twice a week.<br>
    <br>
    Greg<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Mark Webb-Johnson wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:CA9A7141-F2D9-4DF9-A887-4374F978FFE0@webb-johnson.net">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      The core issue here (wifi connection being lost, but ESP stack not
      able to report that to the application - us) is the real culprit.
      I, like Michael, hope that later versions of the ESP IDF can solve
      this. Once the wear levelling version upgrade bug is fixed,
      perhaps we can try? I do see this in my home (despite the wifi
      access point being about 2metres from the car), so suspect it is
      more related to a timeout / interference. For me, it only happens
      once every few weeks.
      <div class=""><br class="">
      </div>
      <div class="">Implementing a facility for fallback to modem even
        if wifi is up (in the case of connections over wifi failing) is
        probably a sensible feature. I think we would need:</div>
      <div class=""><br class="">
      </div>
      <div class="">
        <ol class="MailOutline">
          <li class="">A way for connection success / failure over a
            particular transport to be reported to the network layer. Or
            some way for network layer to access historical statistics.<br
              class="">
            <br class="">
          </li>
          <li class="">Some logic in the network layer to determine wifi
            is unreliable (presumably based on sequential connections
            failures without success, over time).<br class="">
            <br class="">
          </li>
          <li class="">Some logic in the network layer to determine wifi
            is reliable again. Perhaps after some time (hours) on modem
            failover, it could switch back to wifi and try again.<br
              class="">
            <br class="">
          </li>
          <li class="">The switch is done in the network layer itself,
            and our current default route switching mechanism should
            support that just fine.</li>
        </ol>
        <div class=""><br class="">
        </div>
        <div class="">I guess a config to enable/disable this as a
          feature.</div>
        <div class=""><br class="">
        </div>
        <div class="">But, I would really much rather ‘fix’ the wifi in
          the first place. It is certainly easier to see if any fix is
          effective at the moment, with the wifi unreliable, than if we
          had some automatic failover to modem situation.</div>
        <div class=""><br class="">
        </div>
        <div class="">Regards, Mark.<br class="">
          <div><br class="">
            <blockquote type="cite" class="">
              <div class="">On 5 Jan 2019, at 2:56 PM, Stephen Casner
                <<a href="mailto:casner@acm.org" class=""
                  moz-do-not-send="true">casner@acm.org</a>> wrote:</div>
              <br class="Apple-interchange-newline">
              <div class="">
                <div class="">Michael,<br class="">
                  <br class="">
                  You're right that we can't depend on the websocket job
                  queue overflow<br class="">
                  to detect loss of wifi connectivity.  If the
                  improvements in the wifi<br class="">
                  driver make it sufficiently robust to detect
                  disassociation, then we<br class="">
                  may not need to do anything else to work around that
                  problem.<br class="">
                  <br class="">
                  However, there may well be situations where wifi is
                  able to associate<br class="">
                  just fine, but there is no connectivity upstream from
                  that point to<br class="">
                  the server.  To handle such cases I think it would be
                  a good idea to<br class="">
                  have a signal that both the websocket and server-v[23]
                  can send to<br class="">
                  netmanager to trigger switching to another path.<br
                    class="">
                  <br class="">
                                                       -- Steve<br
                    class="">
                  <br class="">
                  On Fri, 4 Jan 2019, Michael Balzer wrote:<br class="">
                  <br class="">
                  <blockquote type="cite" class="">Steve,<br class="">
                    <br class="">
                    you could have enabled event logging additionally,
                    but there clearly is no event from the wifi driver
                    on the disassociation, or the netmanager would have
                    logged<br class="">
                    this as well.<br class="">
                    <br class="">
                    You're probably right in the websocket job queue
                    overflow indicating the loss, but that won't fit as
                    a general canary, as it's only active while at least
                    one<br class="">
                    web client is connected.<br class="">
                    <br class="">
                    Another thing you could monitor is the signal
                    quality, or maybe check for a lack of update
                    callbacks? That's CSIRxCallback in esp32wifi.<br
                      class="">
                    <br class="">
                    But that's all working around the underlying wifi
                    blob bug. We first should check if the current IDF
                    blob does a better job.<br class="">
                    <br class="">
                    Regards,<br class="">
                    Michael<br class="">
                    <br class="">
                    <br class="">
                    Am 04.01.19 um 06:15 schrieb Stephen Casner:<br
                      class="">
                    <blockquote type="cite" class="">Yesterday I found
                      another instance where I could not ssh to OVMS nor<br
                        class="">
                      ping it.  This time I verified in my router status
                      that the wifi<br class="">
                      association with OVMS was "inactive" (down).  The
                      iPhone app said that<br class="">
                      server-v2 was not hear for 108 minutes.  This time
                      I have a full log<br class="">
                      file covering back to the previous day, which is
                      attached.<br class="">
                      <br class="">
                      I connected to OVMS with the serial console and
                      the output from the<br class="">
                      serial monitor is appended to the attached log
                      file.  The "wifi stat"<br class="">
                      and "net stat" commands both indicated that the
                      wifi connection was up<br class="">
                      when all the external indications were to the
                      contrary.  Going back<br class="">
                      108 minutes in the log file corresponds roughly to
                      the first instance<br class="">
                      of "job queue overflow detected".  Perhaps the web
                      server can act as<br class="">
                      the canary in the coal mine?  There is no
                      indication that the wifi<br class="">
                      driver signaled any problem at that time.<br
                        class="">
                      <br class="">
                      Diagnosing this problem is difficult because the
                      loss of connectivity<br class="">
                      occurs after a day or a few days of operation.  I
                      have not tried the<br class="">
                      current esp-idf yet; I may do that, but I'm not
                      sure how long that<br class="">
                      would need to operate without loss to determine
                      success.<br class="">
                      <br class="">
                                                       -- Steve<br
                        class="">
                    </blockquote>
                  </blockquote>
                  _______________________________________________<br
                    class="">
                  OvmsDev mailing list<br class="">
                  <a href="mailto:OvmsDev@lists.openvehicles.com"
                    class="" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
                    class="">
                  <a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
                    class="">
                </div>
              </div>
            </blockquote>
          </div>
          <br class="">
        </div>
      </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>
  </body>
</html>