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

51–60 of 86 posts

Re: ESP32 WiFi Superstitions

#51

Post by jalk »

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.

Same as Cargo Cult programming: https://en.wikipedia.org/wiki/Cargo_cult_programming

Re: ESP32 WiFi Superstitions

#52

Post by vachina »

Vurdentium wrote: post #18
serviceberry wrote: post #12

Earlier quoted context omitted.

I used to say things like that, but come on: Arduino is targeted at hobbyists. More specifically, it's targeted at hobbyists who don't want to spend too much time learning hardware . If they did, they would be using a "bare" microcontroller better suited for their needs and costing one tenth the price. But they're not interested in microcontroller programming, they just want to get their art project done. It's the sa…

The problem isn't with the artist doing a one-off project involving a microcontroller. It's the Arduino "experts" who write blogs, create videos, and dominate forums with their accumulated nonsense. They posit themselves as authorities in the space, newbies adopt and echo whatever rubbish they make up, and the cycle continues. They get very defensive if you try to correct them, even linking directly to documentation…

I know what you mean haha.

Instead of spending x2 the initial effort to fix the root cause, you spend x1 the initial effort to implement jank and then spend x10 the effort down the line maintaining the jank.

Re: ESP32 WiFi Superstitions

#53

Post by mort96 »

Vurdentium wrote: post #6
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…

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…

To be fair, the API people typically use in hobbyist contexts is literally a single call to 'WiFi.begin(ssid, password)'. There's not exactly any obvious room for error here, and any details which may or may not have been implemented incorrectly are so deep inside abstraction layers as to be inaccessible. There's little apparent room for making the code more robust (other than "workarounds" like application level health checks + reboot on error), because everything is supposed to have been taken care of by the abstraction.

If I can disable PM and then my ESP stops disconnecting from WiFi, I'm happy. There's not much more I can do without re-implementing what 'WiFi.begin()' does myself, and I usually have better things to do with my time.

Re: ESP32 WiFi Superstitions

#54

Post by taneq »

stavros wrote: post #9

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

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

Re: ESP32 WiFi Superstitions

#55

Post by ranma42 »

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

Re: ESP32 WiFi Superstitions

#56

Post by stavros »

taneq wrote: post #54
stavros wrote: post #9

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

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

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.

Re: ESP32 WiFi Superstitions

#57

Post by deskr »

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…

> then spreading this experience as proven and applicable in any context

It's worse. People don't even need to have personal experience to spread misinformation. They just read it online and then spread it like gospel.

Misinformation in the likes of "Wood glue it stronger than wood", "Burning Diesel/Kerosine can't reach temperatures required to melt steel".

Re: ESP32 WiFi Superstitions

#58

Post by RockRobotRock »

Vurdentium wrote: post #40
RockRobotRock wrote: post #36

Earlier quoted context omitted.

Personally, I don't use multiple APs with overlapping SSIDs, but if I did than I can see how it would be easier to deal with the logic from the AP management side rather than the client. It's also nice to not have to re-connect IoT things if/when you add or change your APs.

I'm not sure we're understanding each other so just to be clear, my suggestion is to change from this (pseudo) C: wifi_connection_config_t config = { .ssid = "my_home_wifi", .password = "secret123", /* implicitly initialised to default: .method = CONNECT_TO_THE_FIRST_AP_THAT_RESPONDS, */ } to wifi_connection_config_t config = { .ssid = "my_home_wifi", .password = "secret123", /* explicitly initialise: */ .method = CO…

I think I understand you. That functionality doesn't exist in ESP32 Arduino tool chain without more work/more code. Their hobby level perspective is valuable to other hobby level engineers who want a solution.

Re: ESP32 WiFi Superstitions

#59

Post by [deleted] »

vachina wrote: post #52
Vurdentium wrote: post #18

Earlier quoted context omitted.

The problem isn't with the artist doing a one-off project involving a microcontroller. It's the Arduino "experts" who write blogs, create videos, and dominate forums with their accumulated nonsense. They posit themselves as authorities in the space, newbies adopt and echo whatever rubbish they make up, and the cycle continues. They get very defensive if you try to correct them, even linking directly to documentation…

I know what you mean haha. Instead of spending x2 the initial effort to fix the root cause, you spend x1 the initial effort to implement jank and then spend x10 the effort down the line maintaining the jank.

[deleted]

Re: ESP32 WiFi Superstitions

#60

Post by masto »

leptons wrote: post #19

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

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

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

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.

Post reply on HN