You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Nano Connect has a shorter range than some other boards I use and I sometimes have connection failures only because my office is at the edge of it's range from the access point. Recently while testing connection_manager this error was raised during a connection_manager.get_socket call:
Traceback (most recent call last):
File "/lib/adafruit_connection_manager.py", line 301, in get_socket
File "/lib/adafruit_connection_manager.py", line 65, in connect
File "adafruit_esp32spi/adafruit_esp32spi_socket.py", line 88, in connect
File "adafruit_esp32spi/adafruit_esp32spi.py", line 819, in socket_connect
File "adafruit_esp32spi/adafruit_esp32spi.py", line 715, in socket_open
File "adafruit_esp32spi/adafruit_esp32spi.py", line 341, in _send_command_get_response
File "adafruit_esp32spi/adafruit_esp32spi.py", line 297, in _wait_response_cmd
File "adafruit_esp32spi/adafruit_esp32spi.py", line 206, in _wait_for_ready
TimeoutError: ESP32 not responding
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "<stdin>", line 23, in <module>
File "adafruit_requests.py", line 591, in get
File "adafruit_requests.py", line 525, in request
File "/lib/adafruit_connection_manager.py", line 312, in get_socket
RuntimeError: Error connecting socket: ESP32 not responding
It's not really practical for me to test this since the range connection issues are hard to reproduce and when they occur throw exceptions at different points in the process, however this error stood out to me because it suggested something other than a typical connection difficulty. In looking at the code I see that get_socket tries twice to make the connection and I think, at least with the ESP32SPI hardware, if the first connection attempt fails the hardware is left in an unresponsive state which would explain the error message. I suppose it's possible there is a way to reset and try again but I don't think that's worth it, especially if we could display a more appropriate message. I'm thinking that the error returned from the first attempt might be better so I was wondering what you thought about only setting the last_exc variable on the first try?
Given the difficulty testing this and that I could be wrong about exactly what's happening in this case, I'm not convinced a change makes sense, but figured I'd bring it up, just in case you look it over and say "Oh yea, that makes perfect sense" 😁
The text was updated successfully, but these errors were encountered:
@RetiredWizard interesting timing... On another thing Dan is working on, he pointed out the requests does a double check on failure, and pointed to some code that would cause it. But it actually was the double hit in connection_manager Info here: adafruit/Adafruit_CircuitPython_Requests#191
I think catching that ESP32 not responding and not trying again also makes sense...
The Nano Connect has a shorter range than some other boards I use and I sometimes have connection failures only because my office is at the edge of it's range from the access point. Recently while testing connection_manager this error was raised during a connection_manager.get_socket call:
It's not really practical for me to test this since the range connection issues are hard to reproduce and when they occur throw exceptions at different points in the process, however this error stood out to me because it suggested something other than a typical connection difficulty. In looking at the code I see that get_socket tries twice to make the connection and I think, at least with the ESP32SPI hardware, if the first connection attempt fails the hardware is left in an unresponsive state which would explain the error message. I suppose it's possible there is a way to reset and try again but I don't think that's worth it, especially if we could display a more appropriate message. I'm thinking that the error returned from the first attempt might be better so I was wondering what you thought about only setting the last_exc variable on the first try?
Given the difficulty testing this and that I could be wrong about exactly what's happening in this case, I'm not convinced a change makes sense, but figured I'd bring it up, just in case you look it over and say "Oh yea, that makes perfect sense" 😁
The text was updated successfully, but these errors were encountered: