OSError 104 is ECONNRESET. Which can be caused by one end or the other closing a socket too soon.
But one should usually enclose network functions in try/except blocks anyway:

url = "https://api.ecobee.com/1/thermostatSummary?format=json&body={\"selection\":{\"selectionType\":\"registered\",\"selectionMatch\":\"\",\"includeEquipmentStatus\":true}}"
headers = {
        'Content-Type': 'text/json',
        'Authorization': f'Bearer {accessToken}'
}
try:
    response = urequests.get(url, headers=headers)
    rstatus = response.status_code
    data = response.json()
    response.close()
except OSError, ValueError:
    data = None
    rstatus = 500

Hi Ned,

Thanks for the reply. I am already doing that and catching the OSError so I
can restart. OCError 104 is not too bad, but sometimes I get OSError 103
which occasionally can become sticky, where every following
urequest.get call will get the OSError 103. I increased the calls to
gc.collect() to free up memory in my loop. It reduced the frequency of
these errors, but they still pop up once every few hours and within a day,
it will turn sticky. Only way out was to do a machine.reset() and restart
the program after a soft boot.

It would be much easier to handle if urequest.get just returned with a
status code indicating the error instead of crashing with an exception 103
or 104.

Sammy

On Thu, Jan 18, 2024 at 3:14 PM Ned Konz @.***> wrote:

OSError 104 is ECONNRESET. Which can be caused by one end or the other
closing a socket too soon.
But one should usually enclose network functions in try/except blocks
anyway:

url = "https://api.ecobee.com/1/thermostatSummary?format=json&body={"selection":{"selectionType":"registered","selectionMatch":"","includeEquipmentStatus":true}}"headers = {
'Content-Type': 'text/json',
'Authorization': f'Bearer {accessToken}'
}try:
response = urequests.get(url, headers=headers)
rstatus = response.status_code
data = response.json()
response.close()except OSError, ValueError:
data = None
rstatus = 500

—
Reply to this email directly, view it on GitHub
https://github.com/micropython/micropython-lib/issues/785#issuecomment-1899366761,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOBUR45SMZETAHI3OAVQYI3YPGUGRAVCNFSM6AAAAABBOA546CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJZGM3DMNZWGE
.
You are receiving this because you authored the thread.Message ID:
@.***>

Hi Sammy,

I'm also seeing a very similar problem and I can't figure it out. I'm new to MicroPython so I'm still leaning the ropes, so please forgive me.
I'm also using urequest but a post(), not a get() and see very similar occasional OSError 103 errors. I also see the same "stickiness", where it sometimes starts to always respond like this and doesn't stop. When the OSError occurs there's a long delay after the request.post(). I have the post happening in an asyncio function. When the post works, it's super fast, but when it doesn't, it take anywhere from 5-20 seconds to respond with the error. I've only seen the OSError 104 once in my days of testing, but that could have just been a momentary wifi/internet connection issue. My internet and Wifi are pretty solid. Using Postman the API always responds instantly. I'm posting to a very simple self hosted PHP script right now. I can see the apache logs and there's nothing obviously wrong with the requests (that I can see).

I'm pretty sure it was working reliably at one point, though I could have been wrong. I'm going to strip my program back to just the absolute essentials and see if I can get the posts to be reliable again.

Have you discovered anything since your last post?

Hi Josh,

Sorry, it has been a long time since I had that problem, and I have
forgotten exactly what I did. But I know I did get over that problem so I
no longer get those errors. Just cannot remember exactly what I did. Sorry.

Sammy

On Mon, Jan 13, 2025 at 6:25 PM joshunagy @.***> wrote:

Hi Sammy,

I'm also seeing a very similar problem and I can't figure it out. I'm new
to MicroPython so I'm still leaning the ropes, so please forgive me.
I'm also using urequest but a post(), not a get() and see very similar
occasional OSError 103 errors. I also see the same "stickiness", where it
sometimes starts to always respond like this and doesn't stop. When the
OSError occurs there's a long delay after the request.post(). I have the
post happening in an asyncio function. When the post works, it's super
fast, but when it doesn't, it take anywhere from 5-20 seconds to respond
with the error. I've only seen the OSError 104 once in my days of testing,
but that could have just been a momentary wifi/internet connection issue.
My internet and Wifi are pretty solid. Using Postman the API always
responds instantly. I'm posting to a very simple self hosted PHP script
right now. I can see the apache logs and there's nothing obviously wrong
with the requests (that I can see).

I'm pretty sure it was working reliably at one point, though I could have
been wrong. I'm going to strip my program back to just the absolute
essentials and see if I can get the posts to be reliable again.

Have you discovered anything since your last post, forgive the pun :)

—
Reply to this email directly, view it on GitHub
https://github.com/micropython/micropython-lib/issues/785#issuecomment-2588720534,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOBUR47SB472ZP6Q2I3UJGL2KRYTLAVCNFSM6AAAAABVD4XNRKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBYG4ZDANJTGQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

No problem, I get it. But thanks for the quick response!
I "feel" like it's resource issue, almost like my urequest.close() isn't isn't actually closing the sockets and they're building up, or some resource leak like that, or the async function is trying to grab a resource at the same time as another async function. Anyways, I'll keep stripping down my app until I find it and I'll post it if I figure it out.

So I've stripped by script down to the basics and I'm still having the issue.

`import urequests
import network
import time

ssid="MySSID"
password="MyKey"

url = "http://mydomain.com/api.php"
data = {"mac_addr": "aabbccddee"}
headers = {"Content-Type": "application/json"}

fail_count = 0
success_count = 0

wlan = network.WLAN(network.STA_IF)
wlan.active(True)

print("Starting")

while True:

while wlan.isconnected() == False:
    print("Connecting to Wifi...")
    wlan.connect(ssid, password)
    
    
    time.sleep(3)
    if wlan.isconnected() == True:
        print("WiFi Manager: Connected")


if wlan.isconnected() == True:

    try:
        print("Sending POST Request")
        response = urequests.post(url, json=data, headers=headers)
        print(response.text)
        response.close()
        success_count += 1
    
    except OSError as error:
        print ("Error with REST API call. " + str(error.errno) + " Error: " + str(error) )
        fail_count += 1
        
print("Update attempts. Success: " + str(success_count) + " Failed: " + str(fail_count))       
time.sleep(10)

`

The URL in the snippet is obviously not what I'm actually using but you can see from the REPL what it returns.

'Sending POST Request
{"mac_addr":"aabbccddee","temp_scale":"C","temp_low_value":"19","timestamp":"Tue, 14 Jan 2025 11:42:12 +0000"}
Update attempts. Success: 38 Failed: 0
Sending POST Request
{"mac_addr":"aabbccddee","temp_scale":"C","temp_low_value":"19","timestamp":"Tue, 14 Jan 2025 11:42:23 +0000"}
Update attempts. Success: 39 Failed: 0
Sending POST Request
{"mac_addr":"aabbccddee","temp_scale":"C","temp_low_value":"19","timestamp":"Tue, 14 Jan 2025 11:42:33 +0000"}
Update attempts. Success: 40 Failed: 0
Sending POST Request

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>408 Request Timeout</title>
</head><body>
<h1>Request Timeout</h1>
<p>Server timeout waiting for the HTTP request from the client.</p>
</body></html>

Update attempts. Success: 41 Failed: 0
Sending POST Request
Error with REST API call. 103 Error: [Errno 103] ECONNABORTED
Update attempts. Success: 41 Failed: 1
Sending POST Request
Error with REST API call. 103 Error: [Errno 103] ECONNABORTED
Update attempts. Success: 41 Failed: 2
Sending POST Request
{"mac_addr":"aabbccddee","temp_scale":"C","temp_low_value":"19","timestamp":"Tue, 14 Jan 2025 11:44:16 +0000"}
Update attempts. Success: 42 Failed: 2
Sending POST Request
Error with REST API call. 103 Error: [Errno 103] ECONNABORTED
Update attempts. Success: 42 Failed: 3
Sending POST Request
Error with REST API call. 103 Error: [Errno 103] ECONNABORTED
Update attempts. Success: 42 Failed: 4
Sending POST Request
{"mac_addr":"aabbccddee","temp_scale":"C","temp_low_value":"19","timestamp":"Tue, 14 Jan 2025 11:45:24 +0000"}
Update attempts. Success: 43 Failed: 4
'

At one point the API response timed out, which I've never seen before, so maybe that's a hint as to what's happening. But as you can see once the 103 errors start, they keep going. It's almost as if the sockets aren't getting closed and once it runs out, that's it. I'm wondering if there's something in my API response that's causing the issue. I'm going to try changing the POST to a GET and see what happens, and will also try changing the response from the API and see what I get. Two separates tests...

Just to follow up... I figured it out, for the most part. After striping down the app to the absolute bare minimum, trying GET's instead of POSTs, modifying the API responses to an absolute minimum, I continued to have the Error: [Errno 103] ECONNABORTED errors in the order of around 20% of the time. Even worse, it would occasionally get sticky and always return an Error: [Errno 103] ECONNABORTED error with the urequest.post() and urequest.get(). Not only that, but it would sometimes take 10-40 seconds to even respond with the error and would hang everything in the meantime. I would need to reboot the PICO to clear it.

I deduced down that the wifi.isconnected() would return True, but I really don't think it was actually fully / properly connected. Also, sometimes the wlan.connect(ssid, key) would take many, many tries to connect. At this point, I suspected the physical Wifi layer being the problem. I know the PICO W only supports 2.4Ghz. I have a Unifi network setup with both 2.4Ghz and 5Ghz on the same SSID. It's been a VERY solid WiFi setup. I rarely have any Wifi issues except, I know some of my other devices in my house that only use 2.4GHz don't like the dual band SSIDs. So I decided to switch the PICO to a 2.4Ghz SSID only as a test. In the process of adding this new SSID with 2.4Ghz only, it must have "restarted" the WiFi across all configured SSIDs because I lost WIfi for a moment on my laptop. After that, everything started to work!! No more multiple attempts to connect to WiFi. No more Error: [Errno 103] ECONNABORTED. The problem was just gone. I assumed it couldn't be a problem with the access points because everything else in my house using Wifi worked great.

Now I've been building this app on the PICO W on and off for weeks now. When I first started, I had no issues. Over time this issues got worse and worse, which is why I just couldn't figure out what I changed with the app to cause the issue. It wasn't the app. I suspect the constant connect/reconnect of the PICO to the access point(s) caused an issue on the access points and the restart cleared the issue. I put my original version of the app back on the PICO, with the first dual band SSID and it worked great! 1000 urequests.post() and 0 errors. What an ordeal.

However, that said, it would be really handy to get more details on networking related errors when they occur. I spent hours trying to figure out what the [Errno 103] ECONNABORTED meant, and because I can't see open sockets, or file handles or any network details on the PICO I found it super hard to diagnose. Most posts I found related to [Errno 103] ECONNABORTED where due to not issuing urequests.close() which we result in running out of available sockets, which makes sense. When/if the issue happens again I set up a constant ping to the PICO IP and see how it responds, or use wireshark to monitor the traffic.

I hope this bit of information helps anybody else in the future.