Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ESP32 WiFi Superstitions

supakeen.com

Post reply on HN
Print view View original

41–50 of 86 posts

Re: ESP32 WiFi Superstitions

#41

Post by Liftyee »

zamadatix wrote: post #4

> 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…

If it's mainly (largely) static IoT devices connecting to an SSID, why not make the SSID hidden so it doesn't fill device screens (controlled by humans who probably don't want the IoT network)? Most commercial IoT products I've used have an option to type a hidden SSID, and your own C++ code definitely can do that.

Re: ESP32 WiFi Superstitions

#42

Post by fadedsignal »

venusenvy47 wrote: post #11
zamadatix wrote: post #4

> 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…

Do you know of something that could get my Android tablet to switch between two AP's in my house? When I change locations in the house, it will never change to the stronger one if it has even the weakest signal that it was connected to. I can't find any Android app that tells the device to "change to a new AP if it is stronger than the current one".

Search for Wifi roaming. To support Wifi roaming you need a wifi mesh though.

Re: ESP32 WiFi Superstitions

#43

Post by riobard »

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

Re: ESP32 WiFi Superstitions

#44

Post by taneq »

pjdesno wrote: post #32
phoronixrly wrote: post #8

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 report…

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.

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.

Re: ESP32 WiFi Superstitions

#45

Post by gblargg »

taneq wrote: post #44
pjdesno wrote: post #32

Earlier quoted context omitted.

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.

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 ba…

I caught a friend's mother going through a ritual like this with the dishwasher. She had to press the heat mode or something on the dishwasher four times in a row before starting it (so it toggled it on and off twice). Who knows how this got started, but she was adamant that it had to be done before starting it.

Re: ESP32 WiFi Superstitions

#46

Post by ryao »

> 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.

Re: ESP32 WiFi Superstitions

#47

Post by ryao »

bobmcnamara wrote: post #26
denkmoon wrote: post #2

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.

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.

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.

Re: ESP32 WiFi Superstitions

#48

Post by supakeen »

doormatt wrote: post #34
shadowpho wrote: post #21

>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

I think they're claiming that it won't roam between APs with identical SSIDs.

Yea, it's not super clear but that's indeed what I meant to say :)

Re: ESP32 WiFi Superstitions

#49

Post by supakeen »

riobard wrote: post #43

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…

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.
Post reply on HN