ESP8266 Reliability and ID

Questions for you C programming ESP8266 guys re: the ESP SDK (1.2.0) and some possibly important info on WIFI and MQTT reliability.

In the SDK:



HOST ID….  If you do an IP scan on a windows network – ESP units will coming up as IP addresses – and Manufacturer ESPRESSIF…   there is a WIFI HOSTNAME GET function in the SDK -  but not only can I NOT get it to do anything, the corresponding GET function returns something like ESP_945645  - and not what I put in and NEITHER are showing up in the Windows IP scan – so the question is… where are you supposed to use the SET function in the SDK to replace the info that comes out of the GET function – and why isn’t any of this showing up on a Windows scan.


I discovered that if our software was running happily on the ESP12, happily talking to MQTT, if I then disconnected the WIFI and router for a few secs and reconnected…… DEAD. The board would respond to serial but it had LOST the WIFI number.

No amount of waiting would fix this – I wonder how many people have NOT twigged to this – well, if not – this could be your lucky day. The reconnect policy set to 1 will ensure that within a few minutes, the IP will reconnect.. and of course you can CHECK this!!!

So the next step was to see if the IP had been reconnected and call the MQTT reconnect routine – after all, you’ve lost all your MQTT subscribes at that point.

Then it occurred to me – there might be other circumstances – the NODE-RED might have gone off for a while – could I be sure I’d still have a connection – so finally we set Node-Red off sending a “heartbeat” message to all of the units (by missing off the unit name and just having a topic of “toesp” on our boards, you send to all) every minute – and that resets a timer – so then in the above routines – if the WIFI is active and the timer has timed out – once again reconnect to MQTT.  I checked the stack and this does not suffer – so fingers crossed that will be just fine for the odd occasion that this is needed.

Hence reconnect without rebooting and all the horrible relay flicking results of that!!!  I’m quite happy – a beer, I think. The repository is updated and I have boards testing now.

If you are using MQTT and C on your ESP8266 boards, you might just want to ponder the above and if you have an answer for my query at the top, please do let me know.


9 thoughts on “ESP8266 Reliability and ID

  1. Is this related to the problem that I had - reliably setting the WiFi Access Point name in C?. I found that I first had to do a read of the WiFi settings before setting one item in the struct. Apparently, by doing a set without a read meant that I had to populate everything before I set it - the read first made sure that there were some default values in the items that I wasn't changing.

    Just a thought!

    1. I've been using the Relay Board project from harizanov. His code boots as an access point which you connect to. It scans the available access points for you to choose the main one and enter the password. Then you commit the changes and the ESP8266 is on your wifi network.

      It's a quick, easy and reliable process and it always reconnects when the router goes down.

    2. Hmm, that's a good idea.... in my case that would have let to writing rubbish - what actually happened was my set name appears to have been utterly ignored.

  2. Hello Peter,
    Currently working on esp 8266 mesh network but cant anything.Do you have any idea about mesh network and plz provide some tips or guide on that stuff.

    1. Apparently the ESP mesh was supposed to get English documentation this week but there was some last minute change. As soon as I find out more I'll report back as I'm interested in this myself but not with Chinese docs.

  3. This is related to stability, but not directly to the topic in hand!

    correct me if i'm wrong but you are / can run a lot of WS2812 LEDs using your software. I'd like to ask you a few questions.

    I've been using the Arduino IDE to design some pretty cool lights, that can run complex animations in 2D from a strip, and over the last month or two my ESP have become pretty unstable... doing a lot of this random rebooting stuff. It has been driving me nuts... but the source of ALL the instability turns out to be turning off interrupts on the WS2812, whilst running wifi. If the IDE is downgraded to use SDK1.01 then there is no instability and it is fine. This issue can be reproduced easily by just using the web server, adding a nointurrupt()s period and pinging the ESP. see

    so my question is, do you have this problem with your LEDs as you also run a lot of them? If you do not, do you update the LEDs a lot, or are they generally just one colour. i have no problems when they are just red.. but when they are updated at 30hrz then the ESP crashes eventually, as there is a lot of nointurrupts.. enabling the interrupts for wifi, solves the rebooting, but the LEDs now glitch and flash a lot!


    1. Hi there Andrew... yes, I have run more than 200 but typically I have a play toy here with 70, and a clock with 60. If you take a look at my code (well that bit isn't mine - it's a combination - but you get the idea) You'll see I'm disabling interrupts - right now I'm having no problems. Well other than the fact that you CANNOT run Espressif's new PWM at the same time - and when you set their PWM to off, it doesn't actually stop it - a point I've raised with them - so it's PWM OR RGB for me..

      Here's the extract from my code... sometimes one colour - sometimes varying (makes no difference as I'd fill up the array outside of interrupts then blast the lot out. When you say update at 30Hz .... if you are referring to updating a whole bunch of LEDs, the LOT at 30Hz - then that would not surprise me that the thing would bomb out ... erm, you could try doubling the clock rate - but then you'd have to adjust your timings accordingly...

      // ----------------------------------------------------------------------------
      // -- This WS2812 code must be compiled with -O2 to get the timing right. Read this:
      // --
      // -- The ICACHE_FLASH_ATTR is there to trick the compiler and get the very first pulse width correct.
      static void __attribute__((optimize("O2"))) send_ws_0(uint8_t gpio){
      uint8_t i;
      i = 4; while (i--) GPIO_REG_WRITE(GPIO_OUT_W1TS_ADDRESS, 1 < < gpio); i = 9; while (i--) GPIO_REG_WRITE(GPIO_OUT_W1TC_ADDRESS, 1 << gpio); } static void __attribute__((optimize("O2"))) send_ws_1(uint8_t gpio){ uint8_t i; i = 8; while (i--) GPIO_REG_WRITE(GPIO_OUT_W1TS_ADDRESS, 1 << gpio); i = 6; while (i--) GPIO_REG_WRITE(GPIO_OUT_W1TC_ADDRESS, 1 << gpio); } void ICACHE_FLASH_ATTR WS2812OutBuffer(uint8_t * buffer, uint16_t length,uint16_t repetition) { uint16_t i; if (wsBitMask>16) return;

      for (i = 0; i < 2; i++) WRITE_PERI_REG(PERIPHS_GPIO_BASEADDR + 8, 1<< wsBitMask); while (repetition--) { for (i = 0; i < length; i++) { uint8_t mask = 0x80; uint8_t byte = buffer[i]; while (mask) { (byte & mask) ? send_ws_1(wsBitMask) : send_ws_0(wsBitMask); mask >>= 1;

      1. Thanks for that... Ive seen that code before, its a little beyond me.. I've actually found a workaround that re-enables interrupts in between bits.. which seems to work most of the time. trying to improve on it. your right... i meant 30hrz.. not kilo hertz!

        The issue is really that I'm running the neopixelbus lib, and this has animations that you can set up that run with a fairly high refresh rate, leading to too much time without interrupts. my same application that takes adalight via serial and that is a lot more stable.

Comments are closed.