Replies: 6 comments 5 replies
-
How did you reconnect the device after the failure? Microdot does not handle the networking, it assumes that this is managed by the application. My guess is that the server just errored when the network disappeared, so you could catch the exception, and when you can, reconnect and start the server again. |
Beta Was this translation helpful? Give feedback.
-
Use case is, I'm intentionally disconnecting and reconnecting WiFi (to be precide, switching WiFi networks, but staying in the same IP space).. |
Beta Was this translation helpful? Give feedback.
-
If the device has no network there is no way to tell it to reconnect, so while this sounds great in practice, it is not possible. The device can attempt to reconnect on its own in a retry loop, I guess, but I want this project to be independent of the underlying networking so I don't see it likely that something like this will be added.
This is not really in scope for this project. What you want is a network stack that is able to handle disconnections and reconnections internally, without affecting the applications that use it. |
Beta Was this translation helpful? Give feedback.
-
I have this problem as well when wifi disconnects but when I try to catch the exception say around ws.receive I get other exceptions which did not occur before. Now when the browser is refreshed or the client disconnects there are additional exceptions such as ENOTCONN, ECONNRESET, and 32 which micropython does not label for the esp32, but is EPIPE. Also [Errno 113] is EHOSTUNREACH not ECONNABORTED. |
Beta Was this translation helpful? Give feedback.
-
A method for getting around the ECONNABORTED OSError is to monitor the network.status() for STAT_BEACON_TIMEOUT condition. This can be used to hard reset the device so that it is back in a known configuration. Since the ECONNABORTED OSError only occurs when a client is connected and the wifi router goes down it is hoped that this is reasonably rare event. Here is example code. import machine
import network
import uasyncio
async def connector():
sta = network.WLAN(network.STA_IF)
while True:
if sta.status() == network.STAT_BEACON_TIMEOUT:
machine.reset()
.... rest of code to connect to network
await uasyncio.sleep(1) |
Beta Was this translation helpful? Give feedback.
-
Not sure if it helps in this case, but what I noticed is there's a list of network errors in microdot defined to be ignored ("muted"). I simply did so without modifying microdot by:
|
Beta Was this translation helpful? Give feedback.
-
This is happening on ESP32 with micropython - so "network" and "wifi" are used interchangeable.
When I'm disconnecting from WiFi within a microdot-handler, microdot fails live below and does not recover from this (as in: does not serve requests anymore after reconnect):
When shortly afterwards reconnecting back to WiFi and the device being reachable again, microdot's state doesn't allow to accept further connections anymore.
While I see one shouldn't purposely drop the layer-2 connection within the handler, I do believe this might happen in the wild and microdot should recover and - once l2-connection is re-established - continue serving data.
If that's intended behaviour and one is supposed to restart microdot oneself after l2-reconnects, maybe a note within the docs would help and/or an example on how to best deal with such a situation.
Beta Was this translation helpful? Give feedback.
All reactions