ESP32 WiFi Superstitions
71–80 of 86 posts
Re: ESP32 WiFi Superstitions
#72Earlier quoted context omitted.
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.
Good highlight. In commercial deployments absolutely, I'd even recommend going as far as hiding any SSID you don't explicitly want people to be manually clicking on with their own devices (i.e. only guest and/or byod should be visible). Not because of security (as the conversation often tangents into) but because the support tickets for "I can't connect to " just go away and it clutters screens less as you say. For h…
Thats bad for the anonymity of all your devices, though. Having a "hidden" network saved and on auto-connect means it'll be constantly broadcasting probe packets for those hidden networks.
Re: ESP32 WiFi Superstitions
#73Maybe 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.
Re: ESP32 WiFi Superstitions
#74Earlier quoted context omitted.
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
#75Earlier quoted context omitted.
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.
Use osc instead
Re: ESP32 WiFi Superstitions
#76Earlier quoted context omitted.
Yes. The proven method is to A/restrict data rates to just high ones and B/lower the transmit power of your AP so that your devices can no longer maintain high enough data rates after a given point and are forced to disconnect. I am almost certain the run of the mill stock firmware does not offer you this option. Look into installing OpenWrt. Apart from that, OpenWrt now allows you to install and use usteer which off…
I use Fresh Tomato as the firmware on my router, but I don't see anything in the documentation about "usteer". I'll search for a different term. I'm sure they have something, because they have a lot of active development.
You see, the first thing I look for when I want to buy a new AP is for it to NOT have a Broadcom chipset (https://openwrt.org/meta/infobox/broadcom_wifi)
Re: ESP32 WiFi Superstitions
#77Props 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
#78Earlier quoted context omitted.
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.
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.
Re: ESP32 WiFi Superstitions
#79Earlier quoted context omitted.
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.
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.
Re: ESP32 WiFi Superstitions
#80Earlier quoted context omitted.
> 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".
Is wood glue really not stronger than wood?
Full video: https://www.youtube.com/watch?v=qnNsE4J-udc