[Ovmsdev] Wifi setup
dexter at expeedo.de
Fri Jul 10 14:57:40 HKT 2020
TL;DR: yes, I'm currently also going towards not letting
esp_wifi_connect() decide which AP to connect to.
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.
D (5034) events: Signal(system.wifi.scan.done)
V (5034) esp32wifi: ScanDone: #01 ssid='WLAN-214677'
bssid='7c:ff:4d:15:2f:86' chan=11 rssi=-64
V (5034) esp32wifi: ScanDone: #02 ssid='WLAN-214677'
bssid='94:4a:0c:c3:9e:63' chan=11 rssi=-77
I (5044) esp32wifi: Found SSID WLAN-214677 - trying to connect
I (7564) esp32wifi: STA connected with SSID: WLAN-214677, BSSID:
94:4a:0c:c3:9e:63, Channel: 11, Auth: WPA2
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.
On all following reconnects on the running system it will correctly pick
the 7c:ff AP, also if wifi is stopped & restarted.
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.
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.
Am 10.07.20 um 02:55 schrieb Mark Webb-Johnson:
> 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
> That approach might help with your other issue (recently raised in
> Regards, Mark.
>> On 10 Jul 2020, at 5:43 AM, Michael Balzer <dexter at expeedo.de> wrote:
>> Welcome Derek,
>> 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 ;-)
>> Am 09.07.20 um 20:50 schrieb Derek Caudwell:
>>> Hi devs,
>>> 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).
>>> 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.
>>> 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:
>>> - 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?
>>> - 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?
>>> - 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
>>> - 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?
>>> Thanks in advance for any pointers and background.
>>> Cheers Derek
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OvmsDev