Page 1 of 2

NodeMCU and WiFi disconnects

Posted: Mon Mar 26, 2018 10:58 am
by crayfish
Hi There

I and a few colleagues of mine are running 1hr workshops with students (themed around IoT), based on NodeMCU, MicroPython, NeoPixels and a temperature sensor (18B20). We want to excite them about IT, show them how easy coding can be; this is supported by a bigger volunteering program of our employer. The students abolutely love it! :D

Anyway, my question is with regards to WiFi stability and MicroPython. What our final MicroPython script is doing, is basically:
1. initialise all the things, getting WiFi up, NeoPixels (ring of 24), Temp sensor, conntect to an MQTT broker
2. Run a constant animation (just a circling light), the colour can be changed by the students and on every completion of a cycle:
3. read the temperature and send it to the MQTT broker
Towards the end of that hour, the students can then pull their smartphones and check with how little effort you can implement an "IoT thing".

My observation is now, that the NodeMCU is after some time disconnecting from the WiFi. Over the serial line, I can see that it is trying to publish to the MQTT broker, but due to the lost WiFi connection cannot ("mqtt reconnect: OSError(103,)").
I have searched this forum and others up and down and seen some similar cases, but I don't believe that I have found the exact duplication of my problem.

In the end, it is not essential to the workshop, but I'd be interested to find out whether an ESP running MicroPython can be used for other projects. Given this connectivity "problem", I would currently rather go with a C implementation.

We have about 20 or so boards (sys.version 3.4.0). We have run this workshop in several venues. We have tried many different MicroPython versions, from 1.8.6. upwards to now 1.9.3. We have used several different WiFi types (from corporate access points to hotel hotspots to SmartPhone hotspots to my home network). We have used public MQTT brokers, we have setup several MQTT brokers on our own on Raspis. I also tried limited playing around with some capacitors directly at the boards. We have used powering the whole thing from a standard USB board, to a USB charger, to one of these standards breadboard power supplies.
It is always the same problem. After some time (this can be 50 cycles, 150, 400, 766, 831 or 2000 cycles), it loses the WiFi connnectivity.

I'd love to post the code here, but it seems that BBCode is off for me (perhaps because I am new posting now?). In the meantime, you can find the source code here: and the bread board setup here: - my apologies if this is not the proper way to do it.

Thank you very much for any help!

Re: NodeMCU and WiFi disconnects

Posted: Tue Mar 27, 2018 9:58 am
by kevinkk525
I can sadly confirm that. I have a bunch of NodeMCU in my appartment as SmartHome using the umqtt.simple (wrapped in uasyncio to make it reliable) to subscribe to my bell and publish sensor data.
Sometimes for 3 days they are connected perfectly but then they go offline. Sometimes only for just 1 hour and 10 minutes (weird that it is always this time) or forever.
What I have found out so far is that there is a correlation with Wifi traffic. With many smartphones connected to my router the connection got lost more often.

My solution is to use an asyncio mqtt library that also checks the wifi connection and reconnects automatically.
You can try this one (forked from peterhinch): ... ree/module
And use the minimal version for the esp8266. The module is quite big so I hope you still have enough RAM left for all your fancy programs. These have to be rewritten in asyncio though..

Re: NodeMCU and WiFi disconnects

Posted: Tue Mar 27, 2018 1:40 pm
by Roberthh
1 hour 10 minutes is about 2**32µs. So it could be a timer overflow issue. Hard to tell where.
1 hour 10 minutes is also close to 2**12 seconds and 2**22 ms.

Re: NodeMCU and WiFi disconnects

Posted: Tue Mar 27, 2018 2:19 pm
by ad525

One of my projects ( a relay for my room light ) is based on micropython. It makes requests using urequest library and based on response it turns on/off the light. The problem was, as you describe above, after a while it was losing the wifi connection. My solution was to make a function which will check the connectivy and then I call it when I receive an error.

Code: Select all

import network
import ...

sta_if = network.WLAN(network.STA_IF)
retries = 0

def connectTowifi():

if not sta_if.isconnected():
    sta_if.connect(WLAN_ESSID, WLAN_PASSWORD)
    while not sta_if.isconnected():
        retries = retries + 1
        print('.', end=' ')
        if retries == 20:
            # wenn keine WLAN Verbindung, rot blinken und Exit hier
            for i in range (0,6):


while True:
		print('Error was detected')

I hope this will help you :D

Re: NodeMCU and WiFi disconnects

Posted: Tue Mar 27, 2018 3:15 pm
by kevinkk525
Your solution only works if the microcontroller is not supposed to receive any information. But if a project only requires the microcontroller to take action and connect then that's of course a simple solution.

Re: NodeMCU and WiFi disconnects

Posted: Thu Mar 29, 2018 12:03 pm
by kevinkk525
Although I have a coroutine running that checks the WIFI state and reconnects, one of my µC went offline for 1h 10 minutes again.. I don't know what the reason for this is. It did not went offline in the logs of my WIFI-Router but to the mqtt broker. A problem with the broker can actually be ruled out as the other µC are still connected and work perfectly fine. Also the broker is connected by wire not wifi.
I guess I have to add a file logger to my µC to find out what is happening during that time.
I really hoped that the new mqtt library would solve this issue but apparently it has to be somewhere else.

Re: NodeMCU and WiFi disconnects

Posted: Fri Mar 30, 2018 4:47 am
by pythoncoder
@crayfish You might like to read the start of this doc which explains some limitations of the official MQTT client.

Re: NodeMCU and WiFi disconnects

Posted: Tue Jul 10, 2018 8:32 am
by crayfish
Hi Peter

Thanks for the link. I understand the limitations, most of them anyway. However, I do believe that the issue is not with MQTT itself, but with the WiFi implementation in Micropython, or at least in conjunction with that. The problem is, that the NodeMCU loses WiFi connectivity, i.e. you cannot reach (ping) it anymore and the NodeMCU MQTT client (hence) cannot send anything anymore.

Now, I have no knowledge over the implementation or inner workings of all this. The problem is, that with this not working, the NodeMCU (or ESP8266) cannot be used in a real implementation. I am just curious, I am surely not the first one discovering this.

I'd prefer to use Python for my stair light, because it'd be easier. I am a lousy coder, I am fighting for every line with google :lol:

Anyway, perhaps that gets solved in the future, I will check back every now and then.


Re: NodeMCU and WiFi disconnects

Posted: Tue Jul 10, 2018 3:27 pm
by kevinkk525
If you just use the module in that link about which the documentation is about, you're fine. It will reconnect your esp if it gets disconnected.

If you are that new to python and micropython you might find my framework useful, that takes care of connecting to the broker and wifi and staying connected. You'll then just have to write your script for the stair light, which should be an easier starting point.


Re: NodeMCU and WiFi disconnects

Posted: Sat Jul 14, 2018 1:07 pm
by pythoncoder
@crayfish The limitations are inherent in radio technology: WiFi connectivity suffers outages for a number of reasons. Any code using WiFi needs to make provision for this and ensure that the link is re-established after an outage. PC operating systems can do this transparently and give an illusion of near-perfect connectivity. Micro implementations need explicitly to code for handling outages which can originate from several sources. It isn't straightforward. That's what my "resilient" MQTT library aims to do: amongst other things it detects WiFi disconnect events and repeatedly attempts a reconnection.

Unfortunately the official MQTT drivers are based on the assumption of perfect connectivity (as in wired Ethernet). I think this has misled a number of people into thinking that connectivity, once established, is rock-solid. In the words of the song "It ain't necessarily so".