<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Everyone,<br>
    <br>
    the wifi rework is pushed: <a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5d1f124060326b92f35887878b4d49c8012542dc">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5d1f124060326b92f35887878b4d49c8012542dc</a><br>
    …and the new edge build is on my server.<br>
    <br>
    This now allows to scan for networks in all modes without disruption
    of a running wifi network.<br>
    <br>
    I've used this to also add a network selection dialog to the setup
    wizard & wifi config.<br>
    <br>
    The apclient mode can now be started without a client SSID to let
    the module automatically connect to any network configured. The
    autostart config page now allows this setup. The special "scanning
    client" mode has been removed.<br>
    <br>
    The wifi manager will still stick to an established connection, even
    if a new network with higher signal strength becomes available. I
    thought about automatically switching networks if the signal gets
    poor, but for now decided against it to avoid frequent network
    reconfigurations in edge cases. If you want the module to explicitly
    scan for a better network, issue "wifi reconnect".<br>
    <br>
    Of course this has involved some changes to the wifi manager, so
    please test & report.<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Am 10.07.20 um 08:57 schrieb Michael
      Balzer:<br>
    </div>
    <blockquote type="cite"
      cite="mid:37f40ea3-3cad-c2af-2bed-94c736eda3f7@expeedo.de">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      TL;DR: yes, I'm currently also going towards not letting
      esp_wifi_connect() decide which AP to connect to.<br>
      <br>
      More precisely, exactly the first (!) call to esp_wifi_connect()
      after a reboot/power up seems to do a round robin scheme among all
      reachable access points of a network regardless of their signal
      strength. This even applies to the first connect() immediately
      after a scan.<br>
      <br>
      Example:<br>
      <br>
      D (5034) events: Signal(system.wifi.scan.done)<br>
      V (5034) esp32wifi: ScanDone: #01 ssid='WLAN-214677'
      bssid='7c:ff:4d:15:2f:86' chan=11 rssi=-64<br>
      V (5034) esp32wifi: ScanDone: #02 ssid='WLAN-214677'
      bssid='94:4a:0c:c3:9e:63' chan=11 rssi=-77<br>
      I (5044) esp32wifi: Found SSID WLAN-214677 - trying to connect<br>
      I (7564) esp32wifi: STA connected with SSID: WLAN-214677, BSSID:
      94:4a:0c:c3:9e:63, Channel: 11, Auth: WPA2<br>
      <br>
      The next reboot will connect to 7c:ff (despite unchanged signal
      strengths), the next again to 94:4a and so on. I've only got two
      access points, so I can't test if it's really round-robin, but
      it's wrong anyway.<br>
      <br>
      On all following reconnects on the running system it will
      correctly pick the 7c:ff AP, also if wifi is stopped &
      restarted.<br>
      <br>
      This AP switching behaviour also persists powering off the module,
      so the wifi blob seems to do this on purpose and even use some
      persistent storage to implement it. Totally undocumented and I've
      found no way to disable this and no workaround so far.<br>
      <br>
      There may be a fix for this in the current esp-idf wifi blob, but
      I've found no issues on this, and esp-idf commit comments are
      mostly not useful.<br>
      <br>
      Regards,<br>
      Michael<br>
      <br>
      <br>
      <div class="moz-cite-prefix">Am 10.07.20 um 02:55 schrieb Mark
        Webb-Johnson:<br>
      </div>
      <blockquote type="cite"
        cite="mid:CFB768E9-8101-495C-8826-085302DDB0C9@webb-johnson.net">
        <meta http-equiv="content-type" content="text/html;
          charset=UTF-8">
        <div dir="ltr">FYI:</div>
        <div dir="ltr"><br>
        </div>
        <div dir="ltr">I’ve recently done some work with the esphome
          system (based on platformio on top of esp idf), for home
          automation. They don’t seem to trust the ESP libraries
          identifying the strongest signal (in the case of two APs
          broadcasting the same SSID). They don’t blindly connect to a
          SSID, but instead first do a scan to produce an ordered list
          and then connect to the SSID+AP-MAC-Address of the AP with the
          strongest signal.</div>
        <div dir="ltr"><br>
        </div>
        <div dir="ltr">That approach might help with your other issue
          (recently raised in mantis).</div>
        <div dir="ltr"><br>
        </div>
        <div dir="ltr">Regards, Mark.</div>
        <div dir="ltr"><br>
          <blockquote type="cite">On 10 Jul 2020, at 5:43 AM, Michael
            Balzer <a class="moz-txt-link-rfc2396E"
              href="mailto:dexter@expeedo.de" moz-do-not-send="true"><dexter@expeedo.de></a>
            wrote:<br>
            <br>
          </blockquote>
        </div>
        <blockquote type="cite">
          <div dir="ltr">
            <meta http-equiv="Content-Type" content="text/html;
              charset=UTF-8">
            Welcome Derek,<br>
            <br>
            I've got a rework of the wifi component near done that
            allows to use scanning mode in apclient configuration. I
            think I can push the changes tomorrow & suggest you'll
            be my beta tester ;-)<br>
            <br>
            Regards,<br>
            Michael<br>
            <br>
            <br>
            <div class="moz-cite-prefix">Am 09.07.20 um 20:50 schrieb
              Derek Caudwell:<br>
            </div>
            <blockquote type="cite"
cite="mid:CAKUcfWFUou6q-PGaZGxJh2iZa48=Lyho-ehfOBGyqQ37C7S4Wg@mail.gmail.com">
              <meta http-equiv="content-type" content="text/html;
                charset=UTF-8">
              <div dir="ltr">Hi devs,
                <div><br>
                </div>
                <div>I recently received the ovms hardware and have been
                  trying to setup the unit so I can solely use the wifi
                  AP+client. In NZ 3G is soon to be sunset and for my
                  needs I don't really need a connection when I'm
                  driving (and want to make sure everything is behaving
                  nicely on the can bus before I do). </div>
                <div><br>
                </div>
                <div>I realise AP+client brings it limitations however
                  hopefully some of these can be worked around as I want
                  to be able to use the dashboard/plugins as well as the
                  mobile app. I am new to C/ESP32 programming and the
                  code base so I thought it best to ask a few questions
                  before I begin tinkering with it.</div>
                <div><br>
                </div>
                <div>Ideally I want the unit on loss of connection to an
                  AP to try and find another AP that has been set in the
                  wifi config and connect. The parts I am not too sure
                  are as follows:</div>
                <div> - on boot the code uses the default wifi ssid, if
                  the default is not available how does the code try and
                  switch to one of the other saved APs?</div>
                <div>    - can multiple APs be saved to the wifi config
                  memory and handled by ESP32? or do they need to be
                  retrieved from ovms config, wifi client details set,
                  try connect and enumerated through?</div>
                <div> - I assume EventTimer10 is the logical place to
                  add extra code if required to enumerate through APs
                  and try to connect? similar to EventScanWifiDone when
                  in SClient mode</div>
                <div> - What is the reason scanning mode is unavailable
                  for AP+client mode in auto init, from the ESP32
                  documentation it appeared to be usable still but with
                  limitations? </div>
                <div><br>
                </div>
                <div>Thanks in advance for any pointers and background.</div>
                <div><br>
                </div>
                <div>Cheers Derek</div>
              </div>
              <br>
              <fieldset class="mimeAttachmentHeader"></fieldset>
              <pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
            </blockquote>
            <br>
            <pre class="moz-signature" cols="72">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
            <span>_______________________________________________</span><br>
            <span>OvmsDev mailing list</span><br>
            <span><a class="moz-txt-link-abbreviated"
                href="mailto:OvmsDev@lists.openvehicles.com"
                moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a></span><br>
            <span><a class="moz-txt-link-freetext"
                href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
                moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a></span><br>
          </div>
        </blockquote>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
      </blockquote>
      <br>
      <pre class="moz-signature" cols="72">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-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="72">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
  </body>
</html>