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
Update to this - the WiFi manager get/post/put methods all initiate a connection if not connected, so when using these methods reset is enough to recycle the connection.
The problem comes when using the socket directly, for example when using the MQTT libraries or the ESP object directly. In this case connect needs to be called explicitly.
This leads to three options that I can see:
Do nothing and rely on any code that uses the WiFi manager and the socket to reconnect manually by calling reset then connect
I do not like this option, reset resets the physical hardware. A reconnect method could perform a hardware reset, check the module status, then reconnect the socket. MiniMQTT is designed to resubscribe to existing topics.
The problem comes when using the socket directly, for example when using the MQTT libraries or the ESP object directly. In this case connect needs to be called explicitly.
An example would be the Azure IoT library - this uses the socket and network interface which are passed to miniMQTT. If code uses the WiFi manager to connect, then gets a connection issue and needs to reconnect that involves resetting the WiFi manager and reconnecting.
Or am I overthinking this, and should add a connection check and auto reconnect to the IoT library when reconnecting?
I think this is the crux of the API design for CircuitPython networking libraries. I don't know what the right answer is.
It feels like the protocol level (HTTP, MQTT) will need to know what to do on reconnect in order to get back into it's current state. Python's socket doesn't have a reconnect but it does have connect. Perhaps a protocol layer should be able to call connect again and it can internally do any reset of external hardware necessary.
Perhaps a protocol layer should be able to call connect again and it can internally do any reset of external hardware necessary.
I like this. The socket which already has access to the interface, wiznet/esp, would handle network reconnection within connect. So if a recv times out, the protocol (minimqtt/requests) could call connect to reset and reconnect the connection?
Activity
jimbobbennett commentedon Jun 2, 2020
Update to this - the WiFi manager get/post/put methods all initiate a connection if not connected, so when using these methods
reset
is enough to recycle the connection.The problem comes when using the socket directly, for example when using the MQTT libraries or the ESP object directly. In this case
connect
needs to be called explicitly.This leads to three options that I can see:
reset
thenconnect
reconnect
methodreset
callconnect
Thoughts?
brentru commentedon Jun 2, 2020
I do not like this option,
reset
resets the physical hardware. Areconnect
method could perform a hardware reset, check the module status, then reconnect the socket. MiniMQTT is designed to resubscribe to existing topics.Which examples have this issue?
jimbobbennett commentedon Jun 2, 2020
An example would be the Azure IoT library - this uses the socket and network interface which are passed to miniMQTT. If code uses the WiFi manager to connect, then gets a connection issue and needs to reconnect that involves resetting the WiFi manager and reconnecting.
Or am I overthinking this, and should add a connection check and auto reconnect to the IoT library when reconnecting?
tannewt commentedon Jun 2, 2020
I think this is the crux of the API design for CircuitPython networking libraries. I don't know what the right answer is.
It feels like the protocol level (HTTP, MQTT) will need to know what to do on reconnect in order to get back into it's current state. Python's socket doesn't have a
reconnect
but it does haveconnect
. Perhaps a protocol layer should be able to call connect again and it can internally do any reset of external hardware necessary.brentru commentedon Jun 19, 2020
@tannewt
I like this. The socket which already has access to the interface,
wiznet
/esp
, would handle network reconnection withinconnect
. So if arecv
times out, the protocol (minimqtt
/requests
) could callconnect
to reset and reconnect the connection?tannewt commentedon Jun 19, 2020
Yeah, by basically getting a new socket.
Call wifi.connect() after wifi.reset()