Galactic unicorn: MBEDTLS_ERR_SSL_CONN_EOF from urlopen at "random"

Support
1

I’m building a dashboard for my unicorn. It cycles between some screens, and periodically refreshes its info from two rest calls.

I was using urequests initially, but was getting out of memory errors relatively quickly. I switched to urllib.urequest, which got rid of the memory errors, but now it runs for about an hour before freezing.

I was able to capture a freeze while connected to Thonny, and it says:

Traceback (most recent call last):
  File "<stdin>", line 402, in <module>
  File "trains_azure.py", line 37, in get_timetables
  File "trains_azure.py", line 21, in query
  File "/lib/urllib/urequest.py", line 30, in urlopen
OSError: (-29312, 'MBEDTLS_ERR_SSL_CONN_EOF')

Googling isn’t telling me much about this error. What could it be? This request goes through ok multiple times before failing. (There’s a 9min cooldown on refreshing the network data)

Memory seems pretty stable. I’m gc.collect()ing between each network call, and before the final call it’s reporting around 55k bytes free.

Alternatively, how can I make micropython detect and recover from an OSError? I’m ok with just hard-resetting the device at that point, if it’s once an hour or more.

The source is here if it helps GitHub - tenpn/unicorn – the crash I intercepted was on the urlopen in trains_azure.py.

2

Curious, have you found a solution? – Based on the error, it seems to be a TCP socket closure.

Are you able to logs from the data point?
(might give you a reason why your connection drop and Unicorn froze)

3

I’m not sure I found a solution, but I found a workaround. I was making two big json requests but discarding a lot of that info, so instead I wrote an azure function that made the requests on the pico’s behalf and paired everything down to a minimal flat json blob. since then I’ve had it running for many many hours non-stop.

there’s still some issue that causes it to stop, but I haven’t been able to capture that while attached to a PC for an entire workday. my current theory is that it’s the power supply I’m using, so I’m going to try swapping that and seeing how long the pico runs.

4

Glad to hear you find a workaround (possible solution). Sounds based on your testing, that a large file has a greater chance of failing to receive, oppose to something small and quick.

Good luck on the power supply swap!!