Open kattni opened 1 month ago
There was some discussion here about the QT-Py ESP32C3 and it's antenna (similar sized). Lowering the tx-power solved the connections issues there too.
The gaierror is something I have also seen on other S3 boards. This is I think related to name resolution (DNS). It is nothing I see during productive operation, but sometimes during development with multiple restarts, e.g. due to crashes.
Adafruit CircuitPython 9.1.4 on 2024-09-17; Adafruit QT Py ESP32-S3 4MB Flash 2MB PSRAM with ESP32S3
I tried the "lowering tx_power" trick and could not connect at all.
If I hard-reset, I will usually get a connection on the first try. Interestingly, the "Unknown failure -2" alternates sometimes with "No network with that ssid".
I'm wondering if (in my case) since the connection isn't used for a long period of time, the socket appears to go "stale" (the connection is dropped at the AP).
@EAGrahamJr Could you try the "Absolute Newest" builds past beta.0, which have some further fixes: https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/adafruit_qtpy_esp32s3_4mbflash_2mbpsram/
@EAGrahamJr Could you try the "Absolute Newest" builds past beta.0, which have some further fixes: https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/adafruit_qtpy_esp32s3_4mbflash_2mbpsram/
I was just going to reply that the newest seems absolutely rock solid for 60 minutes (that's 4 HTTP requests spread out over 1 hour)...
Started a "how long will this run" test this morning. Reference code is at https://github.com/EAGrahamJr/ispy-deskie (basically it's asyncio and checks for wifi.radio.connected
every 5 seconds, then goes into a re-connect loop if necessary).
I would say it's generally stable. After about 3 hours or so, started getting more of these:
26532.219: INFO - Connecting to WiFi
26535.633: ERROR - Error connecting wifi - Unknown failure 2
26535.641: WARNING - Attempting to re-connect
26537.641: INFO - Connecting to WiFi
26540.055: ERROR - Error connecting wifi - No network with that ssid
26540.055: WARNING - Attempting to re-connect
26540.297: WARNING - Weather waiting on connection
26542.055: INFO - Connecting to WiFi
26546.500: INFO - Connected to WiFi - IP address: 192.168.1.19
with an occasional
ERROR - Error connecting wifi - Unknown failure 39
There's no pattern to when the connection drops, so it may be more of an indication of the general messiness of my current wifi environment (there's at least 20 AP's nearby) plus the relative strength (or not) of the embedded radio?
Almost all of my boards (including S3, Pico-W) need more than a single attempt to connect to my AP. wifi.radio.connect()
does have a timeout-parameter, but I don't think this is implemented in the way you expect it to work (if implemented at all). So I also use a retry loop for connecting.
Otherwise my S3 board is very stable. Running for days, connecting every 15 minutes to an URL fetching data.
If possible, you should check the logs of your AP to see if the AP actively stops the connection or if the client (i.e. the S3-board) does this. Maybe you have to turn on logging Wifi-events somewhere in the AP (that's what I have to do).
Eh, my AP logs are pretty limited -- all I can see is when the S3 gets a MAC address, which only means the AP sees a connection. I need to put a timestamp on my logs so I can correlate instead of trying to "count seconds since I plugged it in". :grinning:
Mixed results early on today, but after I moved the I2C display cable off of the chip within the enclosure, I've had 12 hours of nonstop service, which is :+1: from me.
Mixed results early on today, but after I moved the I2C display cable off of the chip within the enclosure, I've had 12 hours of nonstop service, which is 👍 from me.
This is very interesting. Do you just mean it was close to the ESP32-S3 chip or do you mean you unplugged (or disconnected) the I2C display?
Mixed results early on today, but after I moved the I2C display cable off of the chip within the enclosure, I've had 12 hours of nonstop service, which is 👍 from me.
This is very interesting. Do you just mean it was close to the ESP32-S3 chip or do you mean you unplugged (or disconnected) the I2C display?
Part of it was laying "over" the board and I managed to coil it all under the display, next to the STEMMA port. It's a bit easier to explain in relation to this picture:
It didn't appear to be triggering button presses, but now it is looking like it may have been some RF interference from the cable and/or the :hankey: :donkey: SH1106 display.
Update (5 minutes later): as I was entering this, it went AWOL again for just a couple of minutes and this time produced a new error message:
[22:35] INFO - Connecting to WiFi
[22:35] ERROR - Error connecting wifi - Unknown failure 2
[22:35] INFO - Connecting to WiFi
[22:35] ERROR - Error connecting wifi - No network with that ssid
[22:35] INFO - Connecting to WiFi
[22:35] ERROR - Error connecting wifi - Authentication failure
but did re-connect 2 seconds later, so :shrug: on that one...
CircuitPython version
Code/REPL
Behavior
If I run the code as-is, I get the following on WiFi connect:
If I add
wifi.radio.tx_power = 13
after imports, it connects successfully. Working code attached (as text file to appease GitHub). code.txtOften, once connected, I will receive the following error attempting to connect to Adafruit IO (or communicate with the web at all; I also tried with
requests.get()
and received the same result):Note this traceback is from different code, attached below. It happens intermittently even with the simple example included above.
Description
This all started when I decided to update an older project. It is running 8.1.0-rc.2 with library versions from around that time, and it connects on the same QT Py ESP32S3 successfully, and communicates with Adafruit IO successfully. (I updated CP on that board, and it experiences all of the failure explained above).
This is the project code. canary_code.txt
Additional information
I have now tried this code on three separate QT Py ESP32S3 boards, with the same results across them all. Two have LED backpacks soldered to them, the other one does not. This should not matter, but I figured it was worth noting anyway.