ESP32-CAM socket.connect() problem

[davefes]

Trying to send an image over a 50 metre path and when it fails to connect, after awhile the board appears to do a machine.reset(). Unfortunately, this leaves the camera in a bad state, so no more images after that.

I have tried many different solutions to attempt raising an error when the socket fails, without success. For example:

def send_file(filename, host, port):
 #  create the client socket
    s = usocket.socket(usocket.AF_INET, usocket.SOCK_STREAM)

    print(f'[+] Connecting to {host}:{port}')

    s.connect((host, port))

    print(f'[+] Connected to server')

 #  try select.poll ... didn't work
#    poller = select.poll()
#    poller.register(s, select.POLLIN)
#    res = poller.poll(5000) #  5 seconds
#    print (f'{res}')

#    if not res: #  didn't work
#    if bool (res):
#        print (f'no connection to the server')
#        utime.sleep(0.1)
#        s.close()
#        config.poweron_reset.on()

I can see res is an empty list but I don't seem to be able to test for it. That snippet is straight from the docs.

Are there other setup conditions for this "sending" socket that I haven't done.

Thanks.

[karfas]

Trying to send an image over a 50 metre path and when it fails to connect

I am pretty sure you are mixing 2-3 mostly unrelated things here.

• given the target host/port is listening, and we are talking about TCP here, connect() should not fail.
• a failed connect() call should not cause a reboot.
• in your code, you poll for POLLIN.
  Depending upon the protocol used (if any), this might never return anything else than false (the empty tuple).
  I would poll for POLLOUT, as you want to send data over the link.
  In my opinion, after connect() succeeds, a check using poll() is useless, anyway. Just write() your data. You need poll() if you want to avoid blocking write() and read() calls, of course.

I have no idea why the check for the empty tuple is not working in your case.

Regarding the camera in an invalid state after reboot, you should find a way to reset it (maybe additional hardware like a transistor to cut it's power supply?).

[davefes]

Thanks for the reply.

The main problem I am having is that the socket connection hangs "waiting for data" at low-signal level conditions. Hours of Googling has not revealed anything I can do when the socket is connected and then fails before all the data has been processed.

What I have noticed is that sometimes the WiFi connects and then I get a "low RSSI" message, in the code below. This seems to coincide with the socket hanging. What I do now is a poweron_reset() if either the WiFi does not connect or the signal level is too low. BTW, I can see -95dBm and barely get all the data thru. See https://github.com/orgs/micropython/discussions/9345

The faulty camera init seems to be some "timeout", at ESP-IDF level, to do with the faulty socket connection? This only seems to give a machine.reset().

I could do a test on the RSSI level and only send the file when it is better than, ie -90dBm or -85dBm.

    if (count == 5): 
        try:
            with open('errors.txt', 'a') as outfile:
                outfile.write('failed to connect after 5 tries' + '\n')
        except Exception as e:
            pass

        disconnect() # WiFi or you could get errors
        print (f'poweron reset')
        utime.sleep(0.1)

        config.poweron_reset.on() #  start from scratch

    try:
        rssi = sta_if.status('rssi')
        print ('RSSI = ' + str(rssi) + 'dBm')
    except Exception as e:
        print ('signal level too low')
        utime.sleep(0.1)
        
        disconnect() # WiFi or you could get errors
        print (f'poweron reset')
        utime.sleep(0.1)
        
        config.power_reset.on()

[davefes]

Gave up trying to get socket.connect() or sendall() to throw any errors on the sending-end.

I have noticed that the device starts to struggle sending packets through in a timely manner below -93dBm. So, my solution for now is to not connect to WiFi if the RSSI is less than -90dBm.

[karfas]

Great if this works for you!

But in my opinion, TCP is not very well suited for bad or intermittent WIFI coverage. Even mqtt struggles with this - the resilient mqtt implementation "lives" from frequent WLAN reconnects.

The search for a simple UDP file transfer protocol is on my to-do list, anyway.

[davefes]

The apparent behaviour of the ESP32 being able to connect to WiFi then return a message that the RSSI is too low to display a value and then stay connected (?) seems a bit suspect to me. Then again I have heard stories about the ESP32 automagically going through a re-connect sequence.

I use UDP to talk to a 3 remote devices, but that is only for simple 10-20 byte messages. For longer-range comms ESP-Now does the job.

[karfas]

Then again I have heard stories about the ESP32 automagically going through a re-connect sequence.

The automatic reconnect (I think this exists only for the ESP32 port) is the default built in micropython. I still think this is a bug, as micropython here does things the user/programmer/application should handle.
Other platforms (ESP8266 ?) might reconnect on their own or automatically after reboot.
The WLAN.config(reconnects=N) option from #7348 allows to control this behavior.