ESP8266 and Lost WIFI Connection

Please note – this blog is WELL out of date and all of my blog items and much, much more have now been moved to – many of the blog entries have been brought up to date – please visit the new site and register for much more.

Something those of you planning to use your ESP8266 units in remote installations might want to be aware of.  I’ve been working with TUAN who developed the MQTT software – now, I’m sure it has nothing to do with his code… but essentially, I’m using his latest software as the basis of a controller.

I’ve added a simple interrupt driven real time clock, refreshed by occasional MQTT message, I control output 0……GPIO0 – and I have a temperature sensor on GPIO2.

All of this works VERY nicely (some new updates from last night you might want to get from the GIT repository) – when the temperature drops below a certain level the output comes on etc, or I can manually turn the output on and off.  I can even store settings in FLASH having added a little section to the area that normally holds WIFI settings – all of this works perfectly.

BUT.. has anyone tried turning off the WIFI for a while…. and then turning it back on? Does your little board reconnect every time, reliably? Because in the real world of remote control that will happen.  I am finding that this is not always the case, that the code sits and tries to connect, maybe even seems to but ultimately fails. If the ESP SDK comes back with “STATION_CONNECT_FAIL” just what exactly should yo do about it?

Most of the time, simply disconnecting the ESP8266 board sorts the problem – if not the first time, the second time (and that in itself is a worry) – but that is no good if the board is actually controlling something – you can’t just reboot the board, you need to somehow reboot the WIFI while maintaining control over whatever it was you were doing…. or find another way to ensure that the WIFI reconnects every time.

The alternative is to use the board with an Arduino and have the Arduino reset the ESP8266 in the event of communication failure – but that’s really a bit of a cop out.

Thoughts?  (this is for C programmers, we’re not talking about LUA though I’m sure that is also worth testing).

Thanks to input here I’ve asked Tuan if it’s possible to update the code using the new 0.9.5 SDK + patch… and we’ll try again!


10 thoughts on “ESP8266 and Lost WIFI Connection

  1. That’s strange, I cannot see any esp_mqtt updates in past 24 hours. There are updates in nodemcu but I assume you are not talking Lua code here.

    • Again strange, I found it by going up from the esp_mqtt git page to Tuan’s page and then clicking on the esp_mqtt link. Low and behold an update 9 hours ago.

  2. I missed it he first time around…there IS an update a few hours old in the middle somewhere./ – See MQTT – Tuan has mis-spelled my name and it says “Scragill reported”. I’m using this code…. with some additions for timing and on-off etc. What I’m finding is that it’s perfect – spot on – until you disconnect and reconnect WIFI…. can’t test this in seconds – needs time – but it does seem to fail often on reconnects… but I would love to hear experiences of others…. it’s always possible it’s something I’ve done to my code.

  3. I am working in the ECLIPSE SDK using Tuan’s MQTT code… I am assuming we’re using the 0.9.4 SDK – I’ll ask as I’m not confident enough to know what to drop in to update the SDK. Good point worth looking at.

  4. Ok I’ve asked the question – it is always possible that the SDK is responsible for reconnect issues… I’m sure Tuan will look at this – I’ve just emailed him.

  5. ok… tried it quite a few times … leaving 5-10 minutes ….. not the latest update … just sits there looping
    no ‘AP’ found
    continuous loop…
    When the AP comes up (Broker off at same time as AP), esp finds it and re subscribes etc. No hint of an issue so far.
    I noted that stability when I updated to the second version, after your observations and suggestions.
    Just got some 12’s in and the boards with 0.1″ headers all round. Have to see what they are like.

    Also found an mqtter android app that takes variables from Tasker sliders etc.

    I know the above doesn’t alleviate your frustrations, it’s just for reference. Lets hope you can get it sorted.

  6. I’m jealous that your boards with 0.1″ headers have turned up – the others are a pain to use. Looking forward to finding out more about the IO – today I discovered that despite setting up GPIO as an output, until you actually set it to 1 or 0 it is in an intermediate state (LED very slightly on) – so now first thing in the init I setup the pin and set to 0 (or whatever).

    To help if you want to do any more reliability testing… When I power up I have maybe half a dozen subscribes to do first, and I have a timer which runs every 5 seconds on the board and sends out some information – in my case the temperature from the SD18B20 (which you’ll recall no longer has any delays)…. So using the latest MQTT software which shows how much of the queue is being used, I can see the packages going out – (0 out of X)….. no queue building up. If I then kill the WIFI the amount of the (currently 2k) queue being used starts to increase as it fills up – I usually let it get half way full and then turn the WIFI back on. Sometimes the queue empties out and all is well, but not necessarily forever, sometimes it never really recovers fully.

    I’m hoping Tuan can update the code to the latest (now not beta) SDK to see if this helps. Right now I’m at a bit of a loss as I really need this to recover automatically from any eventuality. I’m even storing output states in FLASH to ensure that in the event of loss of power, the output(s) (well I only have one on the ESP-01, more when I use the larger boards) stay in the same state on reconnect. I plan to stick this in a room with a heater and I don’t fancy a horrendous bill because the WIFI goes off and leaves things running.

  7. If you want to email me your address, I’ll post a one of headed units to you. Figure I owe you a drink.

    As to the gpio, it’s probably in an input weak pullup state before switching to an output.

    As to the queue build up, seems you need an ack that it has been received and actions taken accordingly. Could do the ack with a local esp, which could feed any other remote devices.
    If the data is not getting received, no point in it being sent, then a send of a break failure to notify that power went down?

    • Hi Dave – I really hope you get this – I just put a redirect on the entire old site – I don’t even know how you got there – the new version is

      Anyway….. thanks for the info and advice.. and here’s my address, please try to confirm you got I – I hope I have not opened up a can of worms upgrading the site…

      Willow Cottage, Wark on Tyne NE48 3LB, UK. Much appreciated.

      I have no idea where this comment is going to end up…


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s