7 ms·

ESP32 WiFi Superstitions

141 points by supakeen 2y ago

denkmoon 2y ago
2.4Ghz WiFi networks should use 20Mhz bands generally. No idea about specifically with ESP32s, but this is good guidance for not congesting the 2.4Ghz space.
- phoronixrly 2y ago
  I second that. In my experience forcing a 40MHz channel on a 2.4g network leads to abysmal performance (never tried it with ESP32, however I can imagine it would be even worse...).
  - sieabahlpark 2y ago
    [dead]
- bobmcnamara 2y ago
  I can think of only a single time where 40 megahertz on 2.4 gigahertz was the right choice for a product (designed for outdoor use, battery powered). File download time decreased by about 40% on Android but not at all on iOS - turned out at the time they only supported 40MHz+ on 5.8GHz.
  - ryao 2y ago
    Other things using the 2.4GHz spectrum might have malfunctioned because of that and the users would have had no recourse. Even if you can, you should not do this unless there are no neighbors within range and you can ensure that you will never put anything else on 2.4GHz near it. Also, I do not believe iOS ever added support for 40MHz channels on 2.4GHz. That feature never should have been added to WiFi. It causes headaches practically everywhere it is used.
    - bobmcnamara 2y ago
      Could probably do a scan to tell if 40MHz or 20MHz was better, but practically these devices are not used in areas with neighbors. The cool part was that our noise floor was great. > It causes headaches practically everywhere it is used. It really does - we got a few complaints that the latest iPhones took twice as long to sync as crappy Android phones. Not enough that I would choose differently on the next one, but something to consider. The other wonky thing was that the usual channels 1/6/11 become 1+6 or 6+11, always up against guardband limits, but reducing power impacts bitrate across the entire bandwidth. Channel 4+9 didn't have this issue but overlaps with all 20MHz channels. I hear the newer WiFi specifications are better at managing this.
rahimnathwani 2y ago
If you have an ESP32C3 board with poor wifi performance, check if it's a boad with poor design that has the ceramic antenna is too close to the oscillator: https://roryhay.es/blog/esp32-c3-super-mini-flaw https://roryhay.es/blog/esp32-c3-super-mini-flaw YMMV but adding a loop of wire in parallel with the oscillator improved wifi performance on mine. (I first tried moving the ceramic antenna a millimeter outward, but that made no difference.)
zamadatix 2y ago
> If your network hardware allows it, you should pin the device to the closest one. In Wi-Fi it's always the client's choice on where to connect to at the end of the day and any hacks the APs try to do to steer clients are "suggestions" at best and "signal ruiners for everyone" at worst. You may be better off specifying which specific AP you want to connect to by specifying the BSSID argument in the WiFi.begin() call on the ESP32 side https://github.com/espressif/arduino-esp32/blob/master/libraries/WiFi/src/WiFiSTA.h#L132 https://github.com/espressif/arduino-esp32/blob/master/libra... Alternatively, if you REALLY want to force it, the sanest way is to use a uniquely named IoT SSID on each AP so there would be no other option for those clients to choose to latch on to (and you can leave the other SSIDs shared for normal clients). E.g. "IoT-1", "IoT-2", "IoT-3" on 3 separate APs. It may clutter up device screens more when you list available networks but it's just visual because, as far as airtime, they all beacon just as often if the names are the same or not anyways. > From what people and the internet tell me you should set the band width on the 2.4 Ghz network that your boards use to 20 Mhz, not 40, not 60, and definitely not automatic. This is spot on in that 20 MHz is the ideal channel width on 2.4, doubly so for just an ESP32. Some things to add are I'd say it should apply to any of your 2.4 GHz networks unless you live out the sticks and really want to race a few extra mbps out at the fringe of your AP coverage (and even then the wider channel width is probably going to make your SNR worse even in the sticks). Also, I don't believe the ESP32 supports 60 MHz in the 2.4 GHz space at all (it's certainly not an option in the Wi-Fi standard). I'll also tack on that the ESP32-C6 can be worth springing for if these kinds of thing are a particular concern as it support Wi-Fi 6, which has a few enhancements for connecting lots of IoT devices without so much noise.
- Vurdentium 2y ago
  Yes this is a skill issue. But Arduino ecosystem is full of superstition and bizarre hacks. It's cargo cult electronics. They will do anything to avoid reading documentation or writing robust code. Even the power saving recommendation here reeks of it. There is no effort to understand it. Someone on an Arduino forum recommends it, others start to echo it to try to appear like they know what they're talking about, it becomes lore in the Arduino world and you out yourself as a clueless newbie if you don't know to do esp_wifi_set_ps(WIFI_PS_NONE) without questioning anything because that's just the way it's done. It disables the radio in between AP beacons, so unless there's a bug in the implementation it should have no noticeable impact to a quiet WiFi station other than saving a lot of power.
mrtesthah 2y ago
I'm sure some of these newly discovered undocumented commands could help. https://www.tarlogic.com/news/backdoor-esp32-chip-infect-ot-devices/ https://www.tarlogic.com/news/backdoor-esp32-chip-infect-ot-...
- Vurdentium 2y ago
  [dead]
phoronixrly 2y ago
Props to OP for using the term 'superstitions'. Wi-fi (and radio in general) is poorly understood even by people with engineering degrees, let alone the average Joe. This often leads to trying random stuff until an improvement is perceived (or believed to be...), then spreading this experience as proven and applicable in any context with no further research and confirmation of the results (let alone filing bug reports). The prominence and accessibility (to laymen) of wifi does not help the situation either... I mean what else CAN they do except try stuff out, how are they going to determine that it worked and why it did?... OP, yes, poorly implemented power saving has in my experience often been a culprit behind network reliability issues. That said, please consider adding a disclaimer that just disabling power saving in client devices without pinpointing the root cause of the instability or at least reporting it is exactly why we are in a situation where it is still buggy.
- pjdesno 2y ago
  I love the term "superstition". I like to refer to lab "rituals" - if something works, repeat it, and never change things around "because it ought to work just as well". Life is too short to figure out all the unknown variables that might be affecting things, so seize luck when you find it.
  - fc417fc802 2y ago
    Having a protocol for working with a black box is fine. The problem is how bad a lot of people are at differentiating between superstition, a black box, and a process with a well understood mechanism.
  - taneq 2y ago
    I’ve been referring to this kind of belief as a ‘pigeon religion.’ This one time an operator has a problem (it’s an e-stop that hasn’t been reset) and they ‘fixed it’ by switching the system into test mode and back, then pressing the e-stop reset three times. So they tell all their friends. Next time that doesn’t work (the e-stop button is still pressed in) but someone tries switching the system into test mode and back twice, slamming the control cabinet door, pressing and releasing the e-stop button three times, then pressing the e-stop reset button three times. They report their findings on the new standard procedure… And so on.
stavros 2y ago
I created some sensor boards based on the ESP8266, they worked well for a while but lately they've been getting flaky. I'm a mediocre hardware engineer at best, so if anyone has any tips on how to make my board more stable, they would be appreciated. Here's the board, it's a bit of a generic light/motion/presence sensor with an IR LED: https://gitlab.com/stavros/sensor-board https://gitlab.com/stavros/sensor-board
- taneq 2y ago
  Do you know which aspect is getting flaky? Ie. Is the wifi dropping out temporarily, or permanently, or the whole MCU locking up, or the 3.3V browning out, or…?
  - stavros 2y ago
    I'm not entirely sure, I can't debug because I don't have a serial interface to it. The board just stops responding to MQTT commands. I do see a lot of "connecting to MQTT" debug messages over the network, so I assume it does have WiFi. I should try pinging and see if it disconnects.
    - brcmthrowaway 2y ago
      Use osc instead
      - stavros 2y ago
        What's that?
        brcmthrowaway 2y ago
        OpenSoundControl Easy protocol to control devices
    - taneq 2y ago
      There’s your first lesson: Always have a debug header with serial pins on your board. ;) It should be easy enough to solder some wires onto the ESP32’s serial port… although wait, how are you programming it? It’s also good to have a couple of status LEDs and a power indicator on any custom board. Then you can add blink codes to indicate errors etc.
Calamityjanitor 2y ago
I was having multiple ESP devices from different brands running totally different firmwares all drop out randomly when I switched to a new Asus wifi router. Came across even more 'work arounds'; No spaces in the SSID, disable IPv6 for the whole network even if the ESP ignores it. Thing is all of these settings would reboot the router and reconnect everything, so it would seemingly work until the next dropout. I found limiting them to 802.11g instead of connecting with 'n' stopped the dropouts for good. Even now I wouldn't say that is a cure-all and that any of these other recommendations don't work, I'd guess that each AP's firmware might have different conflicts with different devices.
- bobmcnamara 2y ago
  This one I've seen caused by N+ burst transmissions tanking the power rail, which causes acknowledgements to be dropped, which causes the esp to lower its TX rate so the TX takes longer...
leptons 2y ago
>It seems that when an ESP32 connects it goes straight for the first access point it sees. No matter if that access point is not the one you’ve taped it to. This can lead to bad connectivity, especially since I’ve not really observed ESP32’s moving around to other access points. This is not a characteristic of "ESP32", this is how the software running on the ESP32 is programmed to work, whatever specific program that is. And it is not my experience at all with "ESP32s". In my ESP-IDF based program, the ESP32 device connects to access points exactly how I tell it to connect with the software I wrote that deals with wifi connections. YMMV.
- masto 2y ago
  I encountered this a while back and it led me to dig into the ESP-IDF documentation to try to understand the behavior of a device I did not write the code for. Yes, it's software, but it's a footgun from the manufacturer. This in particular I find to violate the principle of least astonishment: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/wifi.html#scan-for-specific-ap-on-all-channels https://docs.espressif.com/projects/esp-idf/en/latest/esp32/... > It is a possible situation that there are multiple APs that match the target AP info, e.g., two APs with the SSID of "ap" are scanned. In this case, if the scan is WIFI_FAST_SCAN, then only the first scanned "ap" will be found. The default if esp_wifi_set_config() is not called or, as I see in almost all the sample code that comes up with a quick web search, it is left untouched in the wifi_config_t struct, appears to be WIFI_FAST_SCAN. When you're looking directly at the relevant manual section during a HN discussion of ESP WiFI behavior, it may be obvious, but for a developer focused on the main product functionality who just copies and pastes an example and moves on when it appears to work, I'm not surprised if this always-incorrect-by-default behavior makes it into the vast majority of shipped ESP-based products. And there's also https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/wifi.html#station-basic-configuration https://docs.espressif.com/projects/esp-idf/en/latest/esp32/... I could have sworn there used to be a "sort by SSID" default, as in it would do the full scan and then connect to the AP with the alphabetically earlier hardware address. In any case, the symptom I was plagued with was that this particular device would consistently connect to the furthest-away access point rather than the one in the same room, resulting in unusable dropouts.
shadowpho 2y ago
>It seems that when an ESP32 connects it goes straight for the first access point it sees. No! You as programmer control that. You can configure to connect to any AP you want. My code does a scan and save the closest AP. If it can’t connect it does another scan and saves a new AP
- deleted 2y ago
  [deleted]
- doormatt 2y ago
  I think they're claiming that it won't roam between APs with identical SSIDs.
  - shadowpho 2y ago
    It’s up to you as the programmer! The library literally gives you the power to roam/connect to whatever you want whenever you want.
  - supakeen 2y ago
    Yea, it's not super clear but that's indeed what I meant to say :)
    - shadowpho 2y ago
      Then change your code. Every AP has a bssid (MAC address) that you can use to connect to specific AP. It’s up to the code to figure out which one to connect to. The libraries have all the options. When you do a scan you get bssid of the AP and strength of each signal. You can make a determination of when to rescan and reconnect.
- ranma42 2y ago
  I do actually see the problem that the ESP32 doesn't automatically reconnect to the stronger AP. I think this gets triggered when then stronger AP is briefly unavailable (reboot or radar scan or whatever) and it switches to the weaker AP, but then once the stronger AP is back it stays connected to the weak AP. (This is with multiple APs in a mesh configuration)
briHass 2y ago
I've had pretty good luck with the ESP line and WiFi, even have 2 of the 32s that have the port for external antenna working in sheds about 150' from the nearest AP. I've always turned off power saving and given them hard coded IP settings (no DHCP). The only time I saw anything wonky is a short-lived experiment with the 32's deep sleep not reliably connecting on wakeup. Mostly ESPHome now, two of the basic Uniquiti pucks from a few years back, for reference.
freen 2y ago
For people who are just trying to get a sensor to work, or control some lights, most esp32 frameworks surface maximum functionality, but minimum system state and next to no detailed debugging capabilities. Combine that with very few “knobs” to turn on the esp32 framework, a router/wifi AP that is likely hostile to its owners, and well, superstition is pretty much all that is left. It’s a demon haunted world. Take note, those who dream of llms operating everything include each other: “prompt engineering” is just a fancy euphemism for grimoire, and when it’s all massive, inscrutable matrices deciding everything, well, you too might just feel it’s not a bad idea to build a shrine.
pabs3 2y ago
I note there is also an open source WiFi firmare for ESP32: https://esp32-open-mac.be/ https://esp32-open-mac.be/
yjftsjthsd-h 2y ago
I wonder if the attempts to replace parts of the network stack with FOSS ( https://news.ycombinator.com/item?id=38550026 https://news.ycombinator.com/item?id=38550026 ) would help with this? At the very least it would let you get more visibility into what's going on when things don't work, and in the best case it'd let you replace the firmware that's creating problems with firmware that doesn't have those problems. (I think.) Of course this depends on the bits you replace being the parts in play.
maujim 2y ago
@supakeen found a spelling mistake at the end of the first para > seriously, open up a device and changes are relatively large that you’ll find one s/changes/chances
- supakeen 2y ago
  Thanks, fixed!
riobard 2y ago
One of the culprits I encountered is that some of the IoT WiFi chips cannot do proper authentication if the AP is using WPA2/WPA3 mixed mode (very common for WiFi6 to increase security with modern devices while keeping backwards-compatibility). The flawed chips can initially connect successfully but disconnect after a few days. Solved it by creating a dedicated IoT SSID advertising just WPA2 w/ AES and only on 2.4GHz w/ 20MHz (you shouldn't use 40MHz on 2.4GHz anyway for god's sake). Here're some useful tips to tune WiFi for IoT https://www.wiisfi.com/#iotconnect https://www.wiisfi.com/#iotconnect
- supakeen 2y ago
  Thanks, I've written that one down in my notes as well it definitely fits the superstitions because it sounds like it should work well.
ryao 2y ago
> Set your APs to use 20 Mhz wide channels This is not a superstition for 2.4GHz. Other devices sharing 2.4ghz tend to malfunction when 40MHz channels are in use. This is a well known phenomenon. I have been able to reproduce it in my household by enabling 40MHz channel support for 2.4GHz on my ruckus APs while listening to audio from a Bluetooth speaker. The Bluetooth speaker will start having discontinuities in the audio stream that disappear when 40MHz support in the APs is disabled.
sourtrident 2y ago
Funny how tweaking modern tech can still feel like adjusting rabbit ears on grandma's old TV - I swear my ESP32 runs better when it's cloudy outside or the microwave’s off.
rkunde 2y ago
This isn’t my area of expertise but I’m surprised there’s no mention of errata. Is that just not a factor at this point because the firmware is assumed to be mature enough?
JKCalhoun 2y ago
I did a little dabbling in code for the ESP32 so I can't speak authoritatively at all, but I found that if your project does not require Wi-Fi, it was kind of annoying that the ESP32 would rob me of background cycles that, for example, the Teensy did not. Maybe there was a way to turn off the Wi-Fi stack. But I suppose the general point still stands — that there are plenty of other small devices without Wi-Fi if that is not a requirement.
eternityforest 2y ago
Mine is to manually poll every once and a while and restart the WiFi if it's not connected. I generally find ESP32 WiFi to be very reliable. I wonder if there's some special high security setting or OpenWRT router or something that they don't like? Whenever tech people say something is unreliable, I sometimes wonder if they're using it in a non-stock way, and if that is part of what causes the issues.

141 points by supakeen 2y ago

2.4Ghz WiFi networks should use 20Mhz bands generally. No idea about specifically with ESP32s, but this is good guidance for not congesting the 2.4Ghz space.

phoronixrly 2y ago
I second that. In my experience forcing a 40MHz channel on a 2.4g network leads to abysmal performance (never tried it with ESP32, however I can imagine it would be even worse...).
- sieabahlpark 2y ago
  [dead]
bobmcnamara 2y ago
I can think of only a single time where 40 megahertz on 2.4 gigahertz was the right choice for a product (designed for outdoor use, battery powered). File download time decreased by about 40% on Android but not at all on iOS - turned out at the time they only supported 40MHz+ on 5.8GHz.
- ryao 2y ago
  Other things using the 2.4GHz spectrum might have malfunctioned because of that and the users would have had no recourse. Even if you can, you should not do this unless there are no neighbors within range and you can ensure that you will never put anything else on 2.4GHz near it. Also, I do not believe iOS ever added support for 40MHz channels on 2.4GHz. That feature never should have been added to WiFi. It causes headaches practically everywhere it is used.
  - bobmcnamara 2y ago
    Could probably do a scan to tell if 40MHz or 20MHz was better, but practically these devices are not used in areas with neighbors. The cool part was that our noise floor was great. > It causes headaches practically everywhere it is used. It really does - we got a few complaints that the latest iPhones took twice as long to sync as crappy Android phones. Not enough that I would choose differently on the next one, but something to consider. The other wonky thing was that the usual channels 1/6/11 become 1+6 or 6+11, always up against guardband limits, but reducing power impacts bitrate across the entire bandwidth. Channel 4+9 didn't have this issue but overlaps with all 20MHz channels. I hear the newer WiFi specifications are better at managing this.

rahimnathwani 2y ago

If you have an ESP32C3 board with poor wifi performance, check if it's a boad with poor design that has the ceramic antenna is too close to the oscillator: https://roryhay.es/blog/esp32-c3-super-mini-flaw https://roryhay.es/blog/esp32-c3-super-mini-flaw YMMV but adding a loop of wire in parallel with the oscillator improved wifi performance on mine. (I first tried moving the ceramic antenna a millimeter outward, but that made no difference.)

zamadatix 2y ago

> If your network hardware allows it, you should pin the device to the closest one. In Wi-Fi it's always the client's choice on where to connect to at the end of the day and any hacks the APs try to do to steer clients are "suggestions" at best and "signal ruiners for everyone" at worst. You may be better off specifying which specific AP you want to connect to by specifying the BSSID argument in the WiFi.begin() call on the ESP32 side https://github.com/espressif/arduino-esp32/blob/master/libraries/WiFi/src/WiFiSTA.h#L132 https://github.com/espressif/arduino-esp32/blob/master/libra... Alternatively, if you REALLY want to force it, the sanest way is to use a uniquely named IoT SSID on each AP so there would be no other option for those clients to choose to latch on to (and you can leave the other SSIDs shared for normal clients). E.g. "IoT-1", "IoT-2", "IoT-3" on 3 separate APs. It may clutter up device screens more when you list available networks but it's just visual because, as far as airtime, they all beacon just as often if the names are the same or not anyways. > From what people and the internet tell me you should set the band width on the 2.4 Ghz network that your boards use to 20 Mhz, not 40, not 60, and definitely not automatic. This is spot on in that 20 MHz is the ideal channel width on 2.4, doubly so for just an ESP32. Some things to add are I'd say it should apply to any of your 2.4 GHz networks unless you live out the sticks and really want to race a few extra mbps out at the fringe of your AP coverage (and even then the wider channel width is probably going to make your SNR worse even in the sticks). Also, I don't believe the ESP32 supports 60 MHz in the 2.4 GHz space at all (it's certainly not an option in the Wi-Fi standard). I'll also tack on that the ESP32-C6 can be worth springing for if these kinds of thing are a particular concern as it support Wi-Fi 6, which has a few enhancements for connecting lots of IoT devices without so much noise.

Vurdentium 2y ago
Yes this is a skill issue. But Arduino ecosystem is full of superstition and bizarre hacks. It's cargo cult electronics. They will do anything to avoid reading documentation or writing robust code. Even the power saving recommendation here reeks of it. There is no effort to understand it. Someone on an Arduino forum recommends it, others start to echo it to try to appear like they know what they're talking about, it becomes lore in the Arduino world and you out yourself as a clueless newbie if you don't know to do esp_wifi_set_ps(WIFI_PS_NONE) without questioning anything because that's just the way it's done. It disables the radio in between AP beacons, so unless there's a bug in the implementation it should have no noticeable impact to a quiet WiFi station other than saving a lot of power.

mrtesthah 2y ago

I'm sure some of these newly discovered undocumented commands could help. https://www.tarlogic.com/news/backdoor-esp32-chip-infect-ot-devices/ https://www.tarlogic.com/news/backdoor-esp32-chip-infect-ot-...

Vurdentium 2y ago
[dead]

phoronixrly 2y ago

Props to OP for using the term 'superstitions'. Wi-fi (and radio in general) is poorly understood even by people with engineering degrees, let alone the average Joe. This often leads to trying random stuff until an improvement is perceived (or believed to be...), then spreading this experience as proven and applicable in any context with no further research and confirmation of the results (let alone filing bug reports). The prominence and accessibility (to laymen) of wifi does not help the situation either... I mean what else CAN they do except try stuff out, how are they going to determine that it worked and why it did?... OP, yes, poorly implemented power saving has in my experience often been a culprit behind network reliability issues. That said, please consider adding a disclaimer that just disabling power saving in client devices without pinpointing the root cause of the instability or at least reporting it is exactly why we are in a situation where it is still buggy.

pjdesno 2y ago
I love the term "superstition". I like to refer to lab "rituals" - if something works, repeat it, and never change things around "because it ought to work just as well". Life is too short to figure out all the unknown variables that might be affecting things, so seize luck when you find it.
- fc417fc802 2y ago
  Having a protocol for working with a black box is fine. The problem is how bad a lot of people are at differentiating between superstition, a black box, and a process with a well understood mechanism.
- taneq 2y ago
  I’ve been referring to this kind of belief as a ‘pigeon religion.’ This one time an operator has a problem (it’s an e-stop that hasn’t been reset) and they ‘fixed it’ by switching the system into test mode and back, then pressing the e-stop reset three times. So they tell all their friends. Next time that doesn’t work (the e-stop button is still pressed in) but someone tries switching the system into test mode and back twice, slamming the control cabinet door, pressing and releasing the e-stop button three times, then pressing the e-stop reset button three times. They report their findings on the new standard procedure… And so on.

stavros 2y ago

I created some sensor boards based on the ESP8266, they worked well for a while but lately they've been getting flaky. I'm a mediocre hardware engineer at best, so if anyone has any tips on how to make my board more stable, they would be appreciated. Here's the board, it's a bit of a generic light/motion/presence sensor with an IR LED: https://gitlab.com/stavros/sensor-board https://gitlab.com/stavros/sensor-board

taneq 2y ago
Do you know which aspect is getting flaky? Ie. Is the wifi dropping out temporarily, or permanently, or the whole MCU locking up, or the 3.3V browning out, or…?
- stavros 2y ago
  I'm not entirely sure, I can't debug because I don't have a serial interface to it. The board just stops responding to MQTT commands. I do see a lot of "connecting to MQTT" debug messages over the network, so I assume it does have WiFi. I should try pinging and see if it disconnects.
  - brcmthrowaway 2y ago
    Use osc instead
    - stavros 2y ago
      What's that?
      - brcmthrowaway 2y ago
        OpenSoundControl Easy protocol to control devices
  - taneq 2y ago
    There’s your first lesson: Always have a debug header with serial pins on your board. ;) It should be easy enough to solder some wires onto the ESP32’s serial port… although wait, how are you programming it? It’s also good to have a couple of status LEDs and a power indicator on any custom board. Then you can add blink codes to indicate errors etc.

Calamityjanitor 2y ago

I was having multiple ESP devices from different brands running totally different firmwares all drop out randomly when I switched to a new Asus wifi router. Came across even more 'work arounds'; No spaces in the SSID, disable IPv6 for the whole network even if the ESP ignores it. Thing is all of these settings would reboot the router and reconnect everything, so it would seemingly work until the next dropout. I found limiting them to 802.11g instead of connecting with 'n' stopped the dropouts for good. Even now I wouldn't say that is a cure-all and that any of these other recommendations don't work, I'd guess that each AP's firmware might have different conflicts with different devices.

bobmcnamara 2y ago
This one I've seen caused by N+ burst transmissions tanking the power rail, which causes acknowledgements to be dropped, which causes the esp to lower its TX rate so the TX takes longer...

leptons 2y ago

>It seems that when an ESP32 connects it goes straight for the first access point it sees. No matter if that access point is not the one you’ve taped it to. This can lead to bad connectivity, especially since I’ve not really observed ESP32’s moving around to other access points. This is not a characteristic of "ESP32", this is how the software running on the ESP32 is programmed to work, whatever specific program that is. And it is not my experience at all with "ESP32s". In my ESP-IDF based program, the ESP32 device connects to access points exactly how I tell it to connect with the software I wrote that deals with wifi connections. YMMV.

masto 2y ago
I encountered this a while back and it led me to dig into the ESP-IDF documentation to try to understand the behavior of a device I did not write the code for. Yes, it's software, but it's a footgun from the manufacturer. This in particular I find to violate the principle of least astonishment: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/wifi.html#scan-for-specific-ap-on-all-channels https://docs.espressif.com/projects/esp-idf/en/latest/esp32/... > It is a possible situation that there are multiple APs that match the target AP info, e.g., two APs with the SSID of "ap" are scanned. In this case, if the scan is WIFI_FAST_SCAN, then only the first scanned "ap" will be found. The default if esp_wifi_set_config() is not called or, as I see in almost all the sample code that comes up with a quick web search, it is left untouched in the wifi_config_t struct, appears to be WIFI_FAST_SCAN. When you're looking directly at the relevant manual section during a HN discussion of ESP WiFI behavior, it may be obvious, but for a developer focused on the main product functionality who just copies and pastes an example and moves on when it appears to work, I'm not surprised if this always-incorrect-by-default behavior makes it into the vast majority of shipped ESP-based products. And there's also https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/wifi.html#station-basic-configuration https://docs.espressif.com/projects/esp-idf/en/latest/esp32/... I could have sworn there used to be a "sort by SSID" default, as in it would do the full scan and then connect to the AP with the alphabetically earlier hardware address. In any case, the symptom I was plagued with was that this particular device would consistently connect to the furthest-away access point rather than the one in the same room, resulting in unusable dropouts.

shadowpho 2y ago

>It seems that when an ESP32 connects it goes straight for the first access point it sees. No! You as programmer control that. You can configure to connect to any AP you want. My code does a scan and save the closest AP. If it can’t connect it does another scan and saves a new AP

deleted 2y ago
[deleted]
doormatt 2y ago
I think they're claiming that it won't roam between APs with identical SSIDs.
- shadowpho 2y ago
  It’s up to you as the programmer! The library literally gives you the power to roam/connect to whatever you want whenever you want.
- supakeen 2y ago
  Yea, it's not super clear but that's indeed what I meant to say :)
  - shadowpho 2y ago
    Then change your code. Every AP has a bssid (MAC address) that you can use to connect to specific AP. It’s up to the code to figure out which one to connect to. The libraries have all the options. When you do a scan you get bssid of the AP and strength of each signal. You can make a determination of when to rescan and reconnect.
ranma42 2y ago
I do actually see the problem that the ESP32 doesn't automatically reconnect to the stronger AP. I think this gets triggered when then stronger AP is briefly unavailable (reboot or radar scan or whatever) and it switches to the weaker AP, but then once the stronger AP is back it stays connected to the weak AP. (This is with multiple APs in a mesh configuration)

briHass 2y ago

I've had pretty good luck with the ESP line and WiFi, even have 2 of the 32s that have the port for external antenna working in sheds about 150' from the nearest AP. I've always turned off power saving and given them hard coded IP settings (no DHCP). The only time I saw anything wonky is a short-lived experiment with the 32's deep sleep not reliably connecting on wakeup. Mostly ESPHome now, two of the basic Uniquiti pucks from a few years back, for reference.

freen 2y ago

For people who are just trying to get a sensor to work, or control some lights, most esp32 frameworks surface maximum functionality, but minimum system state and next to no detailed debugging capabilities. Combine that with very few “knobs” to turn on the esp32 framework, a router/wifi AP that is likely hostile to its owners, and well, superstition is pretty much all that is left. It’s a demon haunted world. Take note, those who dream of llms operating everything include each other: “prompt engineering” is just a fancy euphemism for grimoire, and when it’s all massive, inscrutable matrices deciding everything, well, you too might just feel it’s not a bad idea to build a shrine.

pabs3 2y ago

I note there is also an open source WiFi firmare for ESP32: https://esp32-open-mac.be/ https://esp32-open-mac.be/

yjftsjthsd-h 2y ago

I wonder if the attempts to replace parts of the network stack with FOSS ( https://news.ycombinator.com/item?id=38550026 https://news.ycombinator.com/item?id=38550026 ) would help with this? At the very least it would let you get more visibility into what's going on when things don't work, and in the best case it'd let you replace the firmware that's creating problems with firmware that doesn't have those problems. (I think.) Of course this depends on the bits you replace being the parts in play.

maujim 2y ago

@supakeen found a spelling mistake at the end of the first para > seriously, open up a device and changes are relatively large that you’ll find one s/changes/chances

supakeen 2y ago
Thanks, fixed!

riobard 2y ago

One of the culprits I encountered is that some of the IoT WiFi chips cannot do proper authentication if the AP is using WPA2/WPA3 mixed mode (very common for WiFi6 to increase security with modern devices while keeping backwards-compatibility). The flawed chips can initially connect successfully but disconnect after a few days. Solved it by creating a dedicated IoT SSID advertising just WPA2 w/ AES and only on 2.4GHz w/ 20MHz (you shouldn't use 40MHz on 2.4GHz anyway for god's sake). Here're some useful tips to tune WiFi for IoT https://www.wiisfi.com/#iotconnect https://www.wiisfi.com/#iotconnect

supakeen 2y ago
Thanks, I've written that one down in my notes as well it definitely fits the superstitions because it sounds like it should work well.

ryao 2y ago

> Set your APs to use 20 Mhz wide channels This is not a superstition for 2.4GHz. Other devices sharing 2.4ghz tend to malfunction when 40MHz channels are in use. This is a well known phenomenon. I have been able to reproduce it in my household by enabling 40MHz channel support for 2.4GHz on my ruckus APs while listening to audio from a Bluetooth speaker. The Bluetooth speaker will start having discontinuities in the audio stream that disappear when 40MHz support in the APs is disabled.

sourtrident 2y ago

Funny how tweaking modern tech can still feel like adjusting rabbit ears on grandma's old TV - I swear my ESP32 runs better when it's cloudy outside or the microwave’s off.

rkunde 2y ago

This isn’t my area of expertise but I’m surprised there’s no mention of errata. Is that just not a factor at this point because the firmware is assumed to be mature enough?

JKCalhoun 2y ago

I did a little dabbling in code for the ESP32 so I can't speak authoritatively at all, but I found that if your project does not require Wi-Fi, it was kind of annoying that the ESP32 would rob me of background cycles that, for example, the Teensy did not. Maybe there was a way to turn off the Wi-Fi stack. But I suppose the general point still stands — that there are plenty of other small devices without Wi-Fi if that is not a requirement.

eternityforest 2y ago

Mine is to manually poll every once and a while and restart the WiFi if it's not connected. I generally find ESP32 WiFi to be very reliable. I wonder if there's some special high security setting or OpenWRT router or something that they don't like? Whenever tech people say something is unreliable, I sometimes wonder if they're using it in a non-stock way, and if that is part of what causes the issues.