Handle temporary loss of WiFi



  • Hi,
    I am using LoPy4 as a HTTP server to send data over LoRa. The setup is as follows:

    • LoPy is connected to a WiFi
    • a device that wishes to send data over LoRa will send a request to the server using a pre configured static IP.

    is there a good way for handling the loss of wifi and how does LoPy react to that?
    I tried to lookup the docs and found nothing there mentioning this.

    Thanks!


  • Pybytes Beta

    @Assem-Hasna said in Handle temporary loss of WiFi:

    a device that wishes to send data over LoRa will send a request to the server using a pre configured static IP.

    It seems you have found your answer. But if connection robustness is what you need, the pre-configured static IP concerns me. If you convert it to a floating IP or DNS name with a low TTL, you will better handle a failure in that server. Alternately, configure multiple IPs in your device for multiple servers, and have it try each one until success. Only one of them needs to be alive at any one time.



  • @Gijs said in Handle temporary loss of WiFi:
    I just (still) need to convince someone here to merge my fix :)

    Ah, the GateKeepers Gijs, what would we do without them!



  • @Gijs said in Handle temporary loss of WiFi:

    Though, as @kjm noted in a different forum thread, the timeout is not recognized explicitely as an error in a try-except block. I just (still) need to convince someone here to merge my fix :)

    But it should not generate an error.
    If you looking for some "fix" then you must add new parameter to connect to run it sync/async.
    If sync then throw an error if assync (as it is now) do not throw an error.
    Becaouse i do now e.g. run connect with some timeout and do different things in the middle and then check state of connection.
    If i need to wait for connection and be sure it is on i do it in the loop (and the loop with the timeout too ;-) ).

    while not wlan.isconnected():
        machine.idle() # save power while waiting
        if chrono.read()>30: #30 sedcond timeout
           break
    

  • Global Moderator

    @livius The timeout indeed works. Though, as @kjm noted in a different forum thread, the timeout is not recognized explicitely as an error in a try-except block. I just (still) need to convince someone here to merge my fix :)



  • @kjm
    there is a timeout parameter in the conncet
    e.g.

    wlan.connect(ssid='ssid', auth=(WLAN.WPA2, 'password', timeout=5000)
    


  • The problem with the standard wifi connect example

    wlan.connect(ssid='ssid', auth=(WLAN.WPA2, 'password'))
    while not wlan.isconnected():
        machine.idle()
    print("WiFi connected succesfully")
    

    is that it is too polite, asks once for a connection then waits. Such code can hang, stuck in a wait loop that never exits. If I loose a wifi connection & need to reconnect I hammer it a bit harder

    for i in range(10):                                                                                                                                  
        if wlan.isconnected(): print("WiFi connected succesfully"); break
        wlan.connect(ssid='ssid', auth=(WLAN.WPA2, 'password')); print(i, end='  '); time.sleep(3)
    


  • @Gijs I believe @Assem-Hasna has an interesting case where it's the LoPy which is acting as a server and receiving the data (before forwarding it over LoRa), so that probably changes a bit the logic involved.

    Though of course something needs to happen on the device which sends to the LoPy, I suppose the main question here is whether the LoPy will automatically reconnect to the WiFi network.


  • Global Moderator

    You should be able to use wlan.isconnected() to find out if the WiFi connection is still alive before using the socket. Another solution could be to use a try-except block around the section where you send data. There can be many exceptions associated with sockets, depending on the state of the connection and server, which might give you more information about what is going on in the event of a connection loss


Log in to reply
 

Pycom on Twitter