Blowing the Home Control 2016 Code

Hackitt and BodgittThis is for the people who’ve been trying out my software (or thinking of trying it out) on the ridiculously cheap (£1.40) but very reliable, powerful and comprehensive ESP12 WIFI processor board and those who’ve gone ahead and gotten some boards we made – all referenced in earlier blogs. For the latest on how to FLASH the chips see this blog update.

Essentially the assumption here is that you have an ESP-12F-based )(or variation such as ESP-12E) board of some description and that GPIO0 is used as a programming button (held to ground to program etc) – and also as a web setup button.

Let me explain the difference between programming and setup. GPIO0 is set up permanently by Espressif as the pin to hold LOW before and during power-up to put the board into programming mode to replace the firmware (which may or may not exist on purchase… could be that AT-Command firmware, LUA or something else). Web setup is just something my software does – it’s not the only software to do so. It may use GPIO2 or GPIO0 AFTER power-up to put the unit into a mode where it acts as an access point, allowing setup for, for example SSID and password.

All other I/O pins are available for one use or another including GPIO16 – take note of other blogs describing wiring and power unless you’re using something like a node-mcu board which just plugs into USB. The software works with my Node-Red software – again described in the home control blog – what’s new here is that OTA now works and you don’t need a development environment to program up the code which  I developed with lots of help from others, using the unofficial Development Kit in Windows. The software will react to MQTT commands and also commands coming into the serial line at 115k baud (serial commands are the same as MQTT payloads - no topic required). - home controlI worked with Richard Burton to get RBOOT working on our code– it is his software which allows for OTA (remote updating) when developing, in my case, in C on the ESP8266.

With OTA working (including from an external location) I thought I might try taking the ROMS and blowing a chip from them rather than from the editing system – that way others can benefit.


Well, I went to get the NODEMCU flasher which was always good – so after a couple of blind alleys – I got to this link..

As you can see, with the flasher, the RBOOT rom loads at 0x00000 and our current code runs at 0x02000. Unlike me, make sure BOTH ROMs are ticked on the left.. as the first one is so short it shows little or no sign of activity. I found I could flash at 46800 baud, you may or may not wish to play safe at 115k baud.  You may also note there is an additional file needed above – in SDK 2.0 and above, on first installation this is needed. See THIS blog entry for up to date information.

So – you blow the software onto the ESP8266 board (here is the link to the NodeMCU – no guarantees as it isn’t mine), now what?

A reminder – what will my software do?

  • Turn outputs on and off with optional timeouts
  • Read inputs
  • Handle RGB Serial LEDs (up to 300 of them assuming you have enough 5v power)
  • Handle PWM 12v LEDs (assuming you have a 12v source and driver hardware such as Mosfets)
  • Act as a LED clock (and a nice one too) with 60 serial LEDs.
  • a TON of other things including handling DS18B20, DHT11, DHT22, talking to Nextion displays (see the Serial Nextion blog) and WAY more – all in the Home Control blog. Add to that the power of Node-Red and you have the basis for a very good and reliable complete home control system.

But first the unit needs to be setup. After programming and then resetting or power-cycling the ESP12 (suggest hooking a LED and resistor to GPIO13 and down to ground) – the light will start flashing – within a second or so – hold GPIO0 (or GPIO2 depending on defaults in the current ROMS – see power-up messages coming out of the serial at 115k baud)  to ground for say 10 seconds and let go (DON’T press for the first 100ms of turning on – JUST after turning on or resetting will do – if you come in early (and if the current pin in use is GPIO0)  it will go into programming mode – of course if you don’t program it, no harm done – just reset and try again).

NOW you can access the board with your mobile phone WIFI as “hack-Setup” and once connected use the phone browser to go to and you get that nice setup on the right above which needs at least one router SSID and password, two if you have them available (second is a backup) – the address of an MQTT broker and username and password and that’s really all that is essential to start off.

Once everything is up and running , the LED on GPIO13 should be flashing very briefly (i.e. off most of the time) – a variation you can setup by commands uses an RGB LED to give more meaningful use (yellow power up, green working, orange working on it, red dead – throw in the bin etc).

You can now talk to the board via MQTT… or the serial port at 11500 baud (you could use my serial terminal.

If using the serial, fire {debug} at it – if using MQTT – then assuming you’ve given it the name “fred” then the same command would be – topic:  fred/toesp and the payload would be {out4;1} or {out4:0} to flick GPIO4 on or off (or if your board is mis-labelled as some are – GPIO5).   The Home Control blog entry goes into the rest of this in detail.

Note that if you DON’T set up an MQTT broker, the unit will try to connect to MQTT and eventually reset and start again. This is deliberate. You MUST setup an SSID, an MQTT broker and once running you should use the ESPLOGIN mode or similar to send the time to the unit shortly after power up then every 12 hours or so. Again this is detailed in the home control blog… it’s quite simple.

The rest is up to you.  I use this with my Node-Red software and I have a node for setting up the time and date on the boards…  it is called node-red-contrib-esplogin

Node-Red controls - Peter Scargill

That log-in node incidentally is available here.

That’s it for now… I’m quite chuffed the OTA now works. This of course is directly relevant to the Nextion WIFI Display project.

You can get the three BIN files from:

IMPORTANT NOTE: If you choose to use ROMS rather than compiling code, you will need to keep up with the BITBUCKET repository changes as these ROMS will be updated when I make changes – which I’ve just done having realised I need to support some older boards we made with a relay on GPIO0 whereas I’m now considering GPIO0 should be an input. There is also a DOC file in the Home Control blog and that is the ONLY up to date guide to the ever increasing instruction set.

Update 14/05/2016:  No longer showing passwords in the web setup page so you must put those in every time you use the setup page – otherwise you end up with blank passwords – which you might want. Added several new commands like cpu_clock so you can double the clock speed  - documented… ROM updated. DEFAULT pin for web updating is generally GPIO2 but on power up you’ll see serial messages which TELL you which pin to use. You can change this to GPIO14.

Update 24/07/2016:  See the changes in blog above, rendering some of the comments below obsolete.


267 thoughts on “Blowing the Home Control 2016 Code

  1. Excellent work Pete, looks good.

    I had been playing around with ESPEasy, but like you I like Node-Red and I think this will be a better bet for that.

    I'm looking forward to having a play when I get home, and plugging all the purchases from AliExpress and Bangood together.

    Keep up the great work mate.

    Brynn (down sarf in Teesside)

  2. Hi! Tnx for your great work on this! son testing feedback:
    - when connecting to ESP i am not getting contact on but on works!

    is there any other web page for other config ? more then MYIP/wifi/wifi.tpl ?
    kind regs

    1. One page is enough surely? That is it...the meat of the software is in the commands as documented in the original blog. LOTS of them. No idea why you shoudl be getting 8.1 instead of 4.1 - it is hardcoded in the software.. Still - if it works....

      1. it didnt work with so i did a ip-scan and found it on and it works fine there 😉
        i just wondered if i missed something on any other page, like what I/O is used for what and things like that.. i guess you do that by commands..
        Just for a couple of days ago i tested this
        and there it is lots of configurations on diffrent pages, so i just expexted some more here to.. 😉
        Thnx for a great blog and nice work!
        kind regs Anders

  3. Hi more Q´s 😉
    I see the flexibility with few topics and "commands" in the case you describe... but in a setup with other "hosts" that expect a uniqe topic per "device" it needs som parsing on the way. Have you concidered to add a topic per I/O pin or DS1820?
    regs Anders

  4. I was having fun programming my ESP-12s...then I found your blog...there's nothing that I wanted to do for my home automation system that your firmware doesn't already do. And now I don't even get the 'fun' of setting up a build environment and compiling myself. Brilliant!

    1. Sorry about that Jerry.. I was in the same position so I made my own software... but - now you get to build lots of stuff and maintain it and upgrade it and.. 🙂 . that'll keep you busy. And trust me - the other end with Node-Red control can take up lots of time too depending how ambitious you want to be.

  5. Hi

    Now have this running but when I connect via serial I keep seeing resets:-

    E:M 2056
    E:M 768

    ets Jan 8 2013,rst cause:2, boot mode:(3,6)

    load 0x40100000, len 1344, room 16
    tail 0
    chksum 0x9c
    load 0x3ffe8000, len 660, room 8
    tail 12
    chksum 0xb8
    csum 0xb8

    Any idea what cause:2 means?
    This is typical of my experience of the ESP. I am using a Wemos D1


    1. No experience of a WEMOS D1 at all I'm afraid - this needs an ESP12 or unit incorporating an ESP-12 - having said that I just had it working on an ESP-01 (the OTA would of course fail).

      Are you getting as far as setting up (grab latest version) with hack-Setup at ?? If you're not getting that far, then it is your physical setup - either the boards or what you are using to blow them. If this is your "typical" experience then I suggest that is the problem as ESP8266 boards are generally very reliable. Have you tried another board.

  6. Hi Peter
    Thanks for sharing your findings on a wide range of IOT projects, especially the esp8266.

    I have your code working on an ESP 12-E and all working fine with node-red.
    However if I browse to my 'network ip/wifi/wifi.tpl' it exposes the setup webpage with all security settings visible, is there a way around hiding this?



    1. Peter,
      I have disabled web page control and the info is now hidden.
      I did toggle that before, but seemed to work after reboot.
      Is there a restore command using the serial port?


    2. I'd suggest editing the wifi.tpl page, so it doesn't insert the wifi password into the form sent back to the browser. A trivial change, which I had to do my local copy when playing with this for Pete.

      1. I assume Richard that you mean the underlying C code so that you send the password from the web page to update - but not then show the password in the refreshed web page? That what you meant? If so sounds reasonable?

        1. No, in the tpl file. The fields have values like %sta_pwd% which are replaced with the real values when sent to the user, just remove these variables from the tpl. Of course you may need to edit the form receiving code to handle blank values being sent back, but I never needed to change settings here, I just didn't want anyone in my area to connect to it and see my house wifi password.

          1. Oh I see - well yes, can do that but also... you can turn the web interface off - so that it only appears when you press GPIO0 and do the business - once done there will then be nothing for them to look at - you can also if you MUST leave that on - put a password on it. But yes, makes sense. All done in source and roms. I've also removed MQTT pass - so that both SSID passwords and MQTT pass must be entered.

  7. Hi Pete,

    Yes I get as far as setup and beyond. I can connect and send debug from serial. Mqqt is working. The only issues is a peridic reset of the esp which I see in the terminal of your serial software. I will try a different esp and see what happens.


    1. Ian,
      Have to set up the following from Peter's notes:
      "Whatever controls these boards must now send topic toesp command {heartbeat} every minute. All the boards will see this - and all will pre-set a counter in themselves - which if allowed to drop to zero will re-initialise the MQTT code."

        1. Excellent Ian - don't forget to check the bitbucket repository for changes and fixes etc... I've just fixed a command in the documentation which was wrong... check out those commands - this software can do a lot more than just turn lights on and off.

          1. Hi Pete

            I have now added the esplogin node. I think there may be an issue with the date.

            From the serial window following a {reset]

            ESP Starting...
            STATION mode
            Web page control disabled
            Waiting for Access Point Studio224G
            Connected as 192:168:1:15
            MQTT connecting
            MQTT Broker connected
            Device ID is BPA3
            Item published
            Time is 08:55:01 10/04/2016

            The time is U.T.C, what do you have to do to get BST?

            Also I log the toesp from esplogin. The log entry does not match the serial output from the esp, it is a day out.
            last entry "Logging in device BPA3 at 08:55:50 11-04-2016"


        2. Hi Ian,

          What did you put into nodered for this heatbeat. I have the esplogin node which is talking to mqtt. but i dont see how i get it to post the heartbeat message.



          1. Flow herewith:-

            [{"id":"ba386057.845d3","type":"mqtt-broker","broker":"localhost","port":"1883"},{"id":"21216e.fe8d7e92","type":"mqtt out","z":"141ba2d1.ebe45d","name":"","topic":"","qos":"","retain":"","broker":"ba386057.845d3","x":790,"y":840,"wires":[]},{"id":"94bcefe9.2341d","type":"inject","z":"141ba2d1.ebe45d","name":"","topic":"toesp","payload":"{heartbeat}","payloadType":"str","repeat":"10","crontab":"","once":true,"x":157.93698120117188,"y":864.6649780273438,"wires":[["21216e.fe8d7e92"]]}]

            If you cannot copy and paste that it is an Inject into an mqtt output.

            Topic is toesp

            Payload {heartbeat}



  8. I am getting the following on my serial monitor. I am not seeing a new wifi location to connect to.
    What should the wifi address be?

    ESP Starting...
    STATION mode
    Web page control enabled
    Waiting for Access Point beyond
    Waiting for Access Point beyond

      1. Correct - The kit only contains the "decoupling capacitors" which act to smooth the power supply voltage.
        The other cap that you are referring to is called a "transient load decoupling capacitor" (usually 100nF) and this is for another purpose really - to reduce voltage drops caused by internal circuit problems
        e.g. Inductance introduced by relatively long power wires and the use of large Caps for smoothing (which have internal inductance caused by the manufacture of the rolled foils inside the cap).
        There can also be internal "logic switching" noise on the power lines introduced by other ICs in the circuit downstream from the power supply (e.g. radar module?) - so it makes sense to put these 100nF caps very near to each IC in the circuit so that they are "internally decoupled"

        N.B. If you look at the circuit diagrams, the ESP8266 already has a "transient load decoupling capacitor", so in theory, it should be OK to NOT add another "transient load decoupling capacitor".

        However, adding an extra one directly by the board should do no harm really .

        Most of the power problems I've experienced for an ESP8266 are cause by voltage drops from poor power supplies which just can't handle the peak current fullstop! (e.g. from cheap USB FDTI)

        Sorry for the long off topic post - just hope its useful

        1. I tend to call the little ones decouplers and the electrolytic smoothing caps - works for me.... if I were to give a recommendation I would say the 0.1u caps close to the regulator are a must. Better safe than sorry.

          1. Pete, you're missing the point a bit - the "decouplers" are meant to be placed nearest the device. however I guess you can have the "decoupler " near both the device and the regulator at the same time 😉

  9. Peter, thanks for modifying the web interface so quickly, that looks more secure now.

    I have been trying to use the {otaupdate} command via serial and its returns a 'Not supported' message.
    The OTA ip is pointing to my RPi server where I have installed the bin files, am I missing something?


    1. {otaupdate} working ok now Peter. It was an ESP12 with 4MB Flash, but I had not set mem size in NODEMCU flasher to same . Initially hung after wdt reset, then remembered GPIO16 to RST link !
      I'm impressed how resilient it is with recovering from power,mqtt and wifi losses.

      Thanks again


  10. Pete.. Re: Caps - there should be a 0.1u cap near the ESP AND near the regulator - assumption would be that the ESP has one already and that COULD be avoided, personally I choose to have both - been building stuff for around 45 years - I don't think that practice has changed much.

    1. "there should be a 0.1u cap near the ESP AND near the regulator"
      Whatever makes you happy Pete, but it isn't needed.
      The 69p kit as provided by Maplin/Adafruit is fine for an ESP8266.
      If it was a problem as you are saying (it isn't), Adafruit would supply it as part of the kit, and they don't 😉

  11. Ian

    Here's the code that pokes into the database

    else {
    newMsg.topic = "insert into device_list(device_name, device_description, device_attribute,logins,last_update,creation_date) values('" + +"','" + fred.desc + "','" + fred.attribute + "',1,NOW(),NOW()) on duplicate key update logins = logins+1, device_description='" + fred.desc + "', device_attribute='" + fred.attribute + "', last_update=NOW()";

    newMsg2.payload="Logging in device " + + " at " +("0" + now.getHours()).slice(-2) + ':' +("0" + now.getMinutes()).slice(-2) + ':' + ("0" + now.getSeconds()).slice(-2) + ' ' + ("0" + (now.getDate() + 1)).slice(-2) + '-' + ("0" + (now.getMonth() + 1)).slice(-2) + '-' + now.getFullYear();

    // in the case of mysql - send out the one message... for SQLite - different syntax so send it out in 2 halves... the conditional insert then the increment
    newMsg3.topic = "insert or ignore into device_list(device_name, device_description, device_attribute,logins,last_update,creation_date) values('" + +"','" + fred.desc + "','" + fred.attribute + "',1,(datetime('now','localtime')),(datetime('now','localtime')))";
    newMsg4.topic = "update device_list set logins = logins+1, last_update=(datetime('now','localtime')) where device_name='" + +"'";

    So as you can see when INSERTING I'm using the time on the database machine- on updating for whatever reason I'm using the time on the machine running the NODE. In my case one and the same - and I checked - my logs are the same as my login info..... hence I can only suggest you check the time and dates on your respective machines.

    1. Pete

      That's odd. I am running Node Red and Mosquitto on the same PI which has the correct date and time:-

      pi@node-red ~ $ date
      Sun Apr 10 15:38:01 UTC 2016
      pi@node-red ~ $

      Any thoughts on BST or do we have to work with UTC?


      1. Hi Pete

        Puzzled as to why I am logging the wrong day I had a look at esplogin.js and saw this:-

        (now.getDate() + 1)).slice(-2) + '-' + ("0" + (now.getMonth() + 1)).slice(-2) + '-' + now.getFullYear();

        I don't know json but I took out the +1 after now.getDate() and i am now logging the correct date in the log file.


        1. Well I have to say... your amendment LOOKS right - and yet - I checked that my local code was the same (its a while since I wrote this) - and sure enough it is the same as the one I published.

          I took a board, gave it a new name, plugged it in and sure enough in the logs

          blue2 empty 2 2016-04-12 17:47:39 2016-04-12 17:47:39

          The correct date with MY code.. at this moment I have no idea WHY. I'll have put that +1 in there for a reason.

          1. Pete

            My log format is different to yours, I have:-

            Logging in device BPA4 at 08:56:10 13-04-2016

            I guess there has to be something different in our NodeRed software. I am away for a few days, I will update esplogon Node when I get back.


  12. Evening all - well I am so glad Ian pointed out a date issue - he was looking at the log file - I was looking at the database - hence the reason I didn't have the foggiest what his problem is - there WAS a bug in the software which put the DAY one day ahead in the LOG file - that has now been fixed. The node red repository is taking it's time but you should be looking at version 1.0.5 now with that bug eliminated - and I'd also realised that my bitbucket repository was behind the times - both now bang up to date.

    By the time you read this - the version SHOULD be 1.05

    and here is the bitbucket store for this.

  13. Hi Pete,

    Love your work. I'd like to try your software on my two v12 boards and 3 x Sonoffs but I'm a bit of a NOOB. I have managed to compile test builds for ESPEasy using their Github repository but I'm not quite sure what to do with Bitbucket to compile your latest build. Could you advise if you have a QSG for this process?

    P.S Do you intend selling your Nextion boards as I'd like to try building some of those too?

    1. Hi there Pete. Well, first of all IO'v eno idea what a QSG is, I've never used ESPEasy (and reading this I think I'll give it a miss "ESP Easy also offers limited "low level" actuator functions but due to system instability, this could be less useful in real life applications."

      I use the Unofficial Development environment for Windows. As you'll have seen in a previous blog I made ROMS available so you don't have to use any environment to flash the chips - you just need some means to flash the two files at 0 and 0x2000

      You do need to fire a command regularly at the code to give it time and date info - for example the ESPLOGIN node in Node-Red - most of my current work is oriented toward using the ESPs in an environment centrally controlled by Node-Red as, over time I've come to realise this is an excellent way forward. board, no plans to sell populated boards as most of the people I talk to would rather do their own thing - and in any case with people expecting Chinese prices there's no way it is worthwhile doing, going into small scale production. As for boards themselves, sending off the pcb info to someone like dirty PCBs in China you can get 10 boards for little over a tenner as some guys have already done. You have to have some soldering skill however as we've used surface mount parts.. but not the very smallest ones - only ones that you can feasibly solder by hand.

  14. I have been following the progress of this home automation project for quite some time, and I finally got around to trying to compile the code you have posted. I have tried everything I can think of so far, but I keep getting an error during the linking stage.

    Do you have any idea what is going wrong? Since you obviously have the code compiled and working on your devices, I can only assume there is some shortfall in my environment settings, but I have not been able to track it down. I'd appreciate any pointers!

    This is where the compile process keeps going wrong for me:

    LD build/app.out
    build/app_app.a(petes_code.o): In function `wifi_station_scan_done':
    d:\Desktop\scargill-esp-mqtt-dev-8cb0930b7e40/user/petes_code.c:713: undefined reference to `rboot_set_current_rom'
    d:\Desktop\scargill-esp-mqtt-dev-8cb0930b7e40/user/petes_code.c:718: undefined reference to `rboot_set_current_rom'
    build/app_app.a(petes_code.o): In function `HSV2RGB':
    d:\Desktop\scargill-esp-mqtt-dev-8cb0930b7e40/user/petes_code.c:631: undefined reference to `rboot_get_current_rom'
    build/app_app.a(petes_code.o): In function `mqttDataCb':
    d:\Desktop\scargill-esp-mqtt-dev-8cb0930b7e40/user/petes_code.c:1397: undefined reference to `rboot_get_current_rom'
    d:\Desktop\scargill-esp-mqtt-dev-8cb0930b7e40/user/petes_code.c:1399: undefined reference to `rboot_set_current_rom'
    build/app_app.a(rboot-ota.o): In function `upgrade_connect_cb':
    d:\Desktop\scargill-esp-mqtt-dev-8cb0930b7e40/user/rboot-ota.c:183: undefined reference to `rboot_write_flash'
    d:\Desktop\scargill-esp-mqtt-dev-8cb0930b7e40/user/rboot-ota.c:198: undefined reference to `rboot_write_flash'
    build/app_app.a(rboot-ota.o): In function `upgrade_recvcb':
    d:\Desktop\scargill-esp-mqtt-dev-8cb0930b7e40/user/rboot-ota.c:83: undefined reference to `rboot_write_flash'
    build/app_app.a(rboot-ota.o): In function `upgrade_resolved':
    d:\Desktop\scargill-esp-mqtt-dev-8cb0930b7e40/user/rboot-ota.c:269: undefined reference to `rboot_get_config'
    d:\Desktop\scargill-esp-mqtt-dev-8cb0930b7e40/user/rboot-ota.c:269: undefined reference to `rboot_write_init'
    build/app_app.a(rboot-ota.o): In function `connect_timeout_cb':
    d:\Desktop\scargill-esp-mqtt-dev-8cb0930b7e40/user/rboot-ota.c:206: undefined reference to `rboot_get_config'
    d:\Desktop\scargill-esp-mqtt-dev-8cb0930b7e40/user/rboot-ota.c:206: undefined reference to `rboot_write_init'
    c:/Espressif/ESP8266_SDK/lib\libcrypto.a(aes-internal.o):(.irom0.text+0x0): undefined reference to `rcons'
    collect2.exe: error: ld returned 1 exit status
    Makefile:131: recipe for target 'build/app.out' failed
    mingw32-make: *** [build/app.out] Error 1

      1. Yes, I'm using that repository along with the Windows unofficial development environment from within Eclipse. From a fresh copy of the project off of bitbucket, I run the windows makefile, and I get compiler errors claiming GCC can't find files which are obviously right there in directories within the main folder. If I explicitly add the names of those directories (and all their subdirectories) to the MODULES line, then it will compile, but it dies when it starts in on the LD section.

        I have redownloaded the SDK and the unofficial dev kit, but it's still doing the same thing. I must have something else on the system mucked up. Maybe the MinGW setup is bad? Hmm. I'll keep poking at it. Could you post a copy of your PATH variable that you use in Eclipse, just so I can make sure I am including all the necessary resources?

        1. Hah! Nevermind. I rebuilt my MinGW installation from scratch, and now I'm getting a clean compile of the app.bin from your code. Something must have been missing or corrupt in my initial environment installation. Thank you for your attention while I muddled through this! Maybe my experience will help someone else track down why their builds are acting weird. Now I can get back to the fun part - working on devices instead of debugging tools. 🙂

          1. Excellent - well just to confirm, I've just arrived in Spain and of course had to completely update my setup as I've not been here for months - and put the latest Espressif on there, pulled down the repository from bitbucket and it has all compiled cleanly - so all is indeed well. Of interest we're working on a revised board and plan, as long as there are no isssues with PWM and serial LED, to use GPIO16 which is the most limited of the pins, as a multi-colour status indicator in place of GPIO13. I have to do some tests this weekend to ensure that'll work ok then we'll have an updated PCB layout (similar otherwise) possibly around the end of the month.

      1. Answering my own question here. Managed to upload it with the below command.

        ./ --port /dev/tty.usbserial- --baud 74880 write_flash 0x0000 rboot.bin 0x2000 romx.bin

        Looks like it's working. Get Serial out and can do a {debug} but I can't see a WiFi SSID. Will keep plugging away.

  15. Hi

    I am having trouble in getting back into set up mode to enable web page control on a couple of my ESP12 devices. Has the timing changed? Looking at serial it seems as if there is hardly any delay between esp starting and going into station mode. I assume that you need to ground GPIO0 before station mode.



        1. NodeMCU should work - nothing special about our boards. Make sure please that you have the doc update from earlier this evening - there were a couple of mistakes - not unexpected considering the major revamp I just did... if you spot any errors do let me know.

          1. I'm wondering if all works but you can't get WIFI setup to work if the default settings are wrong.... There's a checksum that kicks in when you use the board for the first time... and right now, the programming button may be set to GPIO2. So a second after power up, hold GPIO2 to ground for say 3 seconds..... to make that GPIO0 for WIFI setup, you may have to serially (only once) issue the command {wifi_button:0} - after doing that, reset the board - note that then, references to out0 will actually refer to GPIO16.. for example {out0:1} and {out0:1} will will affect GPIO16 - as GPIO0 is now an input.... hope that helps. Alternatively with {wifi_button:2}, GPIO16 is not enabled, GPIO2 is the reset button (this is all for legacy) and {out0:X} instructions will operate on GPIO0. If using the former {wifi_button:0} remember not to press GPIO0 low until AFTER poweup or you'll just go into setup.

  16. Hi Pete
    In another post I think you said that these 2 binaries are current. I have tried several times to upload to my Nextion daughter board but on each occasion it refuses to store values to eeprom. Any advice?

    1. You have me a little lost here John - the binaries I made available are not for blowing into the Nextion board, they are for blowing into an ESP12 - which then connects to the serial on the Nextion board. The Nextion itself is used as normal - but with the baud rate adjusted as per the Nextion documentation, to 56k as I could not get reliability out of a software UART at a higher speed than that.

      It is up to you then to define what you want to do with the Nextion, put up pages expecting input and responding accordingly - and then you can use the ESP via WIFI to send commands to it and receive info from it. So as you see my files have nothing to do with EEPROM in the Nextion.

  17. I said daughter board meaning the board housing the ESP12 attached to the Nextion display.
    It accepts all the usual commands eg {ssid:”kitchen_wifi”}
    but on reboot .... nothing... not getting stored to eeprom.
    Am I going wrong in the upload process. I've tried 2 methods.

    1. Hi John

      Meanwhile - I realised when trying to change the description of a board that I had a mistake so I took this opportunity to test. I checked the version - 1.3.3 and changed the ID to "greenish" after updating the code with an FTDI... all went well. I then updated the version number and over-wrote the original binaries. After ensuring {ota_host:""} I called {otaupdate} and sure enough the board updated to version 1.3.4 and rebooted again retaining the ID... so all is in fact well and if you repeat what I've just done you'll get version 1.3.4 of the ROM. All of my units are now up to a version that can handle the OTA - it SO beats yanking them out of cabinets to update them.

      Have fun - the Nextion part depending on how you think may be trivial or not so. I hope my blog entry helps.

  18. That should work. Have a look at {debug} and make sure the ota_host is "" - exactly that - not some variation with http or anything. It should work just fine.

    1. GPIO2 is NEVER the reset button - none of the GPIOs is.. The reset is completely separate.

      Reset - is reset no matter who's software.
      GPIO0 - is hardwired as the programming input - ie if you hold that down as you power up, the board will go into standard ESP8266 programming mode (serial, not web). In some software it is also used AFTER powerup to go into web set up mode - this is entirely dependent on the user software. In mine it is not the default but can be set that way with a command.

      GPIO2 - is often used for web (OTA) programming and that is the default state with my software but you can program it with a command to use GPIO0 or GPIO2.

      So there is web programming - that is merely the ESP8266 running a simple web page to let you set up parameters (which you can also do serially with my software) - OTA is something different - that is when the ESP8266 goes off to a website, grabs a binary file and replaces it's own code with it. That's not strictly true - what actually happens is the ESP8266 loads the file into an otherwise unused part of memory then sets a flag so the next time it boots up, the start address is set to the NEW address (leaving the old area usable for another OTA). This of course relies on you never using more than half of the available FLASH on the ESP - not that difficult on the ESP12 as it has loads of FLASH (it is RAM it could do with a little more of).

      1. question was badly written.....but you answered anyway. In your original blog post you talk about grounding GPIO0 after switching on to get into setup (your setup I am hoping) then some comments mention the new version uses GPIO2.......I was just asking if the serial message I am seeing 'Web Programming Pin:2' means I have the new version......Your answer seems to be 'yes'!!!

        Unfortunately for me) I don't have buttons on my GPIO0 and GPIO2 so I am frantically moving jump wires........I just went to Maplins and bought a SPDT switch for the inflated price of GBP2.49!!!! Thanks for the help!

        1. GPIO BEFORE power on is the same for all units - flashing the chip.. GPIO0 AFTER power on depends on the setup - my default here is to use GPIO2 - but I will be changing to GPIO0 because it matters not which one you use - and GPIO0 is brought out to a button on the SONOFFS so I thought we may as well use that... but by default if you're flashing from my ROMS for the first time it will be GPIO2 - because the original green boards we did had a button on GPIO2.

          Hope that is clearer and understand it can all be confusing for some... especially having the same input doing different jobs at different times. And of course for clarity, you should really use say a pullup of 1k or 4k7 on GPIO0 and 2 - and then when I say PRESSED I mean shorting to ground. Another good reason to use GPIO0 as it has to be held high anyway and so why not make it an input permanently (the original rush to use it for an output was on the ESP-01 which only had a couple of useful pins - but hopefully most of us are beyond using those now.

  19. For reference - when my software "logs in" to tell the Raspberry Pi it is here (this is all handled by node-red-contrib/esplogin) - it sends code starting at line 359 here

    Starting at "void IFA mqttConnectedCb(uint32_t *args)"

    (that line number won't be valid in the future as I update the software often).

    To keep the unit happy, whatever you are using if it is not a Pi or similar and my node, you must send the unit the TIME (doesn't have to be valid) once every 12 hours...

    See line 1003 - again that won't be valid in the future - it starts "else if (os_strcmp(token, "time") == 0) {"

  20. Hi Pete,

    Excellent Work. I've just blown this on the sonoff and it works. One question though. When you send a MQTT meassge to the remote device to say switch out put 12 on is there a way for the remote end to send back a MQTT message to say that it has switched the output on.



    1. Not directly Paul as I pretty much trust MQTT... however.... as I found out today, I was sending an {out0:1} message to turn heating on and the damned board had died and wasnt' doing anything - I though it was impossible for the boards not to restart after losing WIFI but it seems there is a one in a million way they can fail... I had the board rebooted and all is fine (just as well as the board is in England and I'm in Spain). So yes there is an argument for getting something back in MQTT. I'm racking my brains to see if there's a reason I should NOT add this in.....

      If you want you can check another way. Adter you send, say {out12:1} - you could always follow that with {out12?}

      So - and this is a real test I'm doing now for you.... "sidewall"

      Subscribe to sidewall/fromesp/out12/#

      send to sidewall/toesp the message {out12?}

      and what comes back is... ON

      obviously if you'd sent {out12:0} the equivalent response would be OFF

      1. Yes indeed - BUT.... when you send {heartbeat} to one of the boards, it responds in serial with "tick" - that may look fine but that does NOT stop the unit from logging on over and over - when you send the time as I mentioned above (even if the time value is rubbish - just a long number) it actually resets a downcounter.

        So the ESP will try to login - and as long as you send the time less than 24 hours, the unit will be happy. I could of course turn all of this off optionally if there is a demand.

        So here is the routine - note that this is ALSO responsible for the change of flashing rate in the ESP from fast to a very brief flash - that means all is well, it has the time etc.

        else if (os_strcmp(token, "time") == 0) {
        if ((!isQuery) && (intValue != 0))
        tm.Valid = 86400;
        myRtc = intValue;
        if (sysCfg.rgb_ind) set_ind(INDIC_GOT_TIME);
        os_timer_arm(&flashTimer, 200, 1);
        iprintf(RESPONSE, "Time is %02d:%02d:%02d %02d/%02d/%02d\r\n", tm.Hour, tm.Minute, tm.Second, tm.Day, tm.Month, tm.Year);

        Notice the TMVALID flag... on powerup and every couple of minutes the ESP module will try to log on and will keep doing it until it gets the time. After that it won't try again for another 24 hours. The reason for doing this was to ensure that even if the ESP timekeeping wasn't perfect, every day, it would get it corrected. And also I log the event in a database.

        The node-red-contrib-esplogin node was put together for just this purpose - sends the time to everyone every 12 hours - and also to a specific unit logging directly.

      2. Hi Pete,

        Ok I'll try that. With regard to "sidewall" i assume this is a new feature you are working and it's not in the rom's on your site yet.

        In the Mqtt Spy I've been subscribing to # to see all the messages. But dont see any coming from "fromesp"

        That is just what i want. My code, which wan't reliable enough did just that with Status and Command. So you sent On to /espxx/command/op1 and it sent back /espxxx/status/op1 when it had switched on the output.

        Hope the weather there is good, it's very hot and sunny back here in the UK today.



        1. Hi Paul... maybe I didn't explain it well.

          If you have a board, lets say it's id is FRED...

          Topic: fred/toesp
          Payload: {out12?}

          That board will return (assuming the output is on

          Topic: fred/fromesp/out12
          Payload: ON

          So if you keep an eye out in MQTT-SPY for fred/fromesp/#

          You should most DEFINITELY see that response - it has been there from the start.

      3. Hi Pete,

        That works so i now see on and off in the fromesp topic.

        Is it possible to join the two requests together.

        {out12:1},{out12?} or {"out12":"1","out12?"}

        I've tried various formats and it doesn't respond.



        1. Hi Paul

          When you mentioned that, something in my mind told me I'd incorporated that into the line parser but it was such a long time ago.

          Anyway, I remember now...


          use the semicolon as a delimiter. I have NO idea how well that will work.. and bear in mind that thanks to limitations of space - that payload can't be more than I think 80 characters so don't get too carried away - but that is a good solution to the issue of getting feedback.

          1. Thanks Pete,

            That works for me. I'll now update my nodered stuff to get that output into the Blynk led.



  21. Just in case it helps anybody else....the SSID appears to be case sensitive....maybe it always is and I have never noticed, but took me quite some time. Also {scan}, which helped me diagnose, works when provided by serial even when not connected, I don't think it is the word document documentation. Finally, and I still have to confirm this, I am trying (so far unsuccessfully) to get nextion working, set_serial:3 does not appear to be included in the switch statement around line 2662........not sure if this 'matters'.

    1. In the last code release, a couple of days ago - the switch is complete.. case 3 sets the serial at 38k4. This is matched in the documentation. SSID is case sensitive.

      case 2 :
      case 3 :
      case 4 :
      case 5 :
      Softuart_SetPinRx(&softuart2, 5);
      Softuart_SetPinTx(&softuart2, 4);
      iprintf(INFO, "Initialised software serial to ");
      switch (sysCfg.serial2)
      case 2: Softuart_Init(&softuart2,57600); iprintf(INFO, "57600"); break;
      case 3: Softuart_Init(&softuart2,38400); iprintf(INFO, "38400"); break;
      case 4: Softuart_Init(&softuart2,19200); iprintf(INFO, "19200"); break;
      case 5: Softuart_Init(&softuart2, 9600); iprintf(INFO, "9600"); break;

  22. hi
    this is exactly what i have been looking for. i have loaded it on to two esp12s one a esp12-E dev kit and the other a WeMos D1 and have the same problem on both. I cant get them to go into setup. on power up The LED on GPIO 13 flashes slowley 6 times then starts flashing faster continually. taking GPIO 0 to ground for 10 secs after power on / reset seems to have no effect. serial output :

    ESP Starting...
    GPIO4 and 5 are outputs.
    Current web programming pin: 2
    GPIO13 is an indicator.
    Software version 1.3.8

    Use the {debug} command for more information.
    STATION mode
    Web page control enabled
    Waiting for Access Point beyond
    Waiting for Access Point beyond
    Waiting for Access Point beyond
    Waiting for Access Point beyond.....18 times then
    Switching to AP: beyond

    ets Jan 8 2013,rst cause:2, boot mode:(3,6)

    load 0x40100000, len 1344, room 16
    tail 0
    chksum 0x9c
    load 0x3ffe8000, len 660, room 8
    tail 12
    chksum 0xb8
    csum 0xb8

    rBoot v1.3.0 -
    Flash Size: 32 Mbit
    Flash Mode: DIO
    Flash Speed: 40 MHz
    rBoot Option: Big flash

    Booting rom 0.
    don't use rtc mem data

    Could this be the particular boards i'm using, or am i doing something wrong?
    many thanks

  23. Peter, Just wondering have you flashed this to the Sonoff devices ? Did you have any dramas or all straightforward (as per the blog instructions further up ?)


    1. Hi Craig,

      Yes it does work, I have flashed it to 14 Sonoff's however, dont try the OTA update as that doesn't work. I dont think there is enough memory for it.

      If you run the OTA it crashes and you need to re flash it.



  24. Hello Peter,

    I am trying to compile the source under Eclipse on Windows 10 and get the following:

    C:\Espressif\examples\ESP8266\nextion>make flash
    FS firmware/webpages.espfs
    cd html; find | ../mkespfsimage/mkespfsimage.exe > ../firmware/webpages.espfs; cd ..
    0 [main] sh 23392 sync_with_child: child 3968(0x178) died before initialization with status code 0xC0000135
    1959 [main] sh 23392 sync_with_child: *** child state waiting for longjmp
    /usr/bin/sh: fork: Resource temporarily unavailable
    make: *** [firmware/webpages.espfs] Error 128

    Any ideas please?


    1. I have absolutely no idea - as I've never seen that before - but expecting lots of people looking into the blog today because of my latest ESP update blog - so you never know, someone might've come across this before. Any ideas, ladies and gents?

      1. OK, sorted. I have WinAVR, which has make etc. and it was in the environment variable and interfering with esp8266.

        Meantime, I have a different question, Peter, what is LK1 for on your diagram please?

  25. Hello,

    I'm using NodeMCU dev 1.0 board. After loading the firmware to it, it keeps reseting and after some time, it even shuts down my PC with error WDT_Handling.

    ets Jan 8 2013,rst cause:2, boot mode:(3,6)

    load 0x40100000, len 1344, room 16
    tail 0
    chksum 0x9c
    load 0x3ffe8000, len 660, room 8
    tail 12
    chksum 0xb8
    csum 0xb8

    rBoot v1.3.0 -
    Flash Size: 32 Mbit
    Flash Mode: QIO
    Flash Speed: 80 MHz
    rBoot Option: Big flash

    Booting rom 0.
    rf_cal[0] !=0x05,is 0xFF

    Can someone help me, how to properly get the code on the esp?


  26. Hello. I am new to the ESP8266 world and am using NodeMcu-12e. I need some help, if you will. I flashed the chip using the two bin files on your website taking care to check off both and put them at the correct addresses. After completion, which seemed to go normally, I unplugged and plugged the chip to its power source and the led on the chip started flashing rapidly. I then tried to find it at without any success. Another person on this site said that he found it at so I scanned all the addresses in between and could not find it. Can you suggest where I might have gone off track and how to complete the installation successfully? I am really excited about the potential this chip has for some projects I have in mind. I thank you in advance for any help you might be able to provide.

    Bill, Sun City Center FL USA

    1. Hi there

      Well to put it into web programming mode, JUST after power up (not before) you have to hold GPIO2 to ground for several seconds (this can be reset to GPIO0 later on in software). The board should then appear as

      Of course there's another way to do it - serial monitor if you have the kit... 115k you can both view the powerup and send commands...

  27. Hi Pete
    I am having problems with the most recent Roms. Serial is showing a very fast stream of rubbish characters and I can't get programming mode on either GPIO 0 or 2.

  28. Hello Peter

    First, thanks very much for your quick response to my question of yesterday. I was able to get the chip going but unfortunately cannot connect to it at the suggested IP address. I did a scan of all ip addresses and it does not seem to be pulling an IP address. Can you suggest a next step?

    Below is a partial dump of the serial monitor screen. I am not sure what "waiting for access point beyond" means but that is the most common message. Again, I would be grateful for any help you are able to give.

    Bill Miller

    Boot v1.3.0 -
    Flash Size: 32 Mbit
    Flash Mode: DIO
    Flash Speed: 40 MHz
    rBoot Option: Big flash

    Booting rom 0.

    ESP Starting...
    GPIO4 and 5 are outputs.
    Current web programming pin: 2
    GPIO13 is an indicator.
    Software version 1.4.8

    Use the {debug} command for more information.
    STATION mode
    Web page control enabled
    Waiting for Access Point beyond
    Waiting for Access Point beyond
    Waiting for Access Point beyond
    Waiting for Access Point beyond
    Waiting for Access Point beyond

    1. The unit is waiting for access point beyond because you've not put the unit into web programming mode - there are two - ssid and ssid2 and their associated passwords - pass.

      I'm testing this here and I can't seem to get it to go into web programming mode. I'll check this.

      Meanwhile you can set all parameters via the serial port.

  29. No I just checked - all is working well. I've just added a little + sign into the setup so that when the relevant programming pin is held low (in your case GPIO2, a "+" sign will appear every 200ms on the serial line.

    So immediately after power up - hold in your case GPIO2 to ground for 5 seconds minimum - more if you like. If you then release take a look on your mobile - you'll see a new access point appear called hack-Setup - log into that - no password needed and NOW you'll find your control pages. Put into the phone browser and you'll be taken to

  30. I managed to capture some of the gobblygook serial data
    rBoot v1.3.0 -
    Flash Size: 32 Mbit
    Flash Mode: DIO
    Flash Speed: 40 MHz
    rBoot Option: Big flash

    Rom 0 is bad.
    Rom 1 is bad.
    No good rom available.
    user code done

    Is this something to do with your new larger flash?

    1. I can only imagine John that either you are flashing the second item to the wrong address (should be 0x2000) or that you are using a board with insufficient FLASH. You need 4Mbytes of Flash as in the ESP12 etc.

      Having said that, not too long ago I flashed ESP-01s - clearly OTA isn't going to work but I certainly did not get any errors in normal use. Today while using up my older ESP-01s I just replace the flash with the 32Mbit parts.

      There is nothing new about larger flash - ESP12 has had that for a long time - for several months the code has been oriented to devices with 4Mbits - the Espressif lbrary has grown and my code is now well over 0.5Mbytes.

  31. The strange thing is that I have successfully blown earlier version roms many times on several of my esp-12s with no problems. This has just arisen in the last 2 days with recently downloaded roms. I am using the exact same process. Unfortunately I have wiped my older versions of them.

  32. Please could some kind person help me out here! I cannot get a working ESP with the current Roms and now I have "killed" a working ESP after doing an OTA update.
    Could someone please try blowing the roms for me and prove me an idiot or otherwise.

    1. Hi John,

      Your not an idiot unless i am too.

      I have downloaded the espflasher and using the two files from Pete's site. Have flashed them to the esp and only get the rboot info. (running at 76800 baud).



      1. Ok, guys - you have me there... I have just taken a brand-spanking board - and used espflasher to blow the board and... nothing. Exactly as you describe.

        So normally I would produce a working board from the source code OR I would use those ROMS to do an OTA update. I must admit then at first glance - and these two reports are the first I've heard of utter failure like this - that I have no idea why this is happening. Clearly the ROMS work or they would not be doing OTA updates.

        So - given the board that has just FAILED I used the same hardware to do a normal install.

        Here is the relevant part of the MAKEFILE

        $(ESPTOOL) -p $(ESPPORT) -b $(ESPBAUD) write_flash $(FLASH_OPTS) 0x00000 $(RBOOT_BIN) 0x02000 $(RBOOT_ROM_0)

        As you can see - we have the addresses correct.

        RBOOT_ROM_0 is defined as romx.bin and RBOOT_BIN is defined as rboot.bin

        So the next step I repeated the operation with roms just created on the compiler locally. Same result. Nothing but the initial 78k stuff.

        So I flashed in the normal way.... ensuring that I was not doing any kind of rebuild.

        $(ESPTOOL) -p $(ESPPORT) -b $(ESPBAUD) write_flash $(FLASH_OPTS) 0x00000 $(RBOOT_BIN) 0x02000 $(RBOOT_ROM_0)

        Here are the flash options...

        FLASH_OPTS ?= -fs 32m -ff 80m -fm qio

        But here's the thing.

        After all that, with conclusive proof that I could not flash a board, I flashed in exactly the same way, an EXISTING board and.... it worked perfectly.

        I ran the OTA command on those exact roms up on the website - worked perfectly.

        At this instance I'm at a slight loss as to why this is happening. Keep looking in and meanwhile if anyone has any thoughts do let me know.

        1. Hi Pete,

          Spotted the problem. In the text above you have this
          "As you can see, with the flasher, the RBOOT rom loads at 0x0000 and our current code runs at 0x2000. Unlike me, make sure BOTH ROMs are ticked on the left"

          And the image shows that too.

          However if put in 0x02000 for the romx it flashes and works on the SonOff.



          1. However if i do that for the LoLin v3 board it crashes with :-

            Booting rom 0.
            rf_cal[0] !=0x05,is 0xFF

            ets Jan 8 2013,rst cause:2, boot mode:(3,6)

            I never managed to install all the software so that i could compile Pete's code. Think it's time to have another go at this. I have wiped my win10 setup so will see if i can setup things from scratch.


  33. Thank you Paul for your time.
    I made the assumption that because there are hundreds of people (if not thousands) following Pete's wonderful blog that there would have been a tsunami of comments from his disciples about this. Therefore I assumed it was just me.

  34. Ok I will fix that - but... there is no difference between 0x02000 and 0x2000 - am I missing something here.... thank YOU... but... have you been able to recover boards that you already tried - mine won't recover... and that surely is just not possible.....

    1. Hi Pete,

      I realise there is no difference, but I started off putting 0x20000 as i just changed the first number not spotting you only had 4 zeros.

      Anyway. I have a LoLin V3 running version 1.3.4 and it works. I have now flashed that to 1.4.8 and it and it works.

      However a brand new board wont work, it flashes but reboots continuously.

      load 0x40100000, len 1344, room 16
      tail 0
      chksum 0x9c
      load 0x3ffe8000, len 660, room 8
      tail 12
      chksum 0xb8
      csum 0xb8

      rBoot v1.3.0 -
      Flash Size: 32 Mbit
      Flash Mode: DIO
      Flash Speed: 40 MHz
      rBoot Option: Big flash

      Booting rom 0.
      rf_cal[0] !=0x05,is 0xFF

      ets Jan 8 2013,rst cause:2, boot mode:(3,6)

      I have even erased_flash and it still gives the same problem.

      So something odd going on.

      I'll keep trying things and let you know how i get on.



      1. I just ran that flash 1 meg clear on all 4 meg and it makes no difference. Now, I know that it cannot be because there is some secret data in the FLASH - because I've replace flash chips on ESP-01 with new 4Mbyte flash chips. So erasing the Flash chip should surely return it to absolute new condition.

        I DID note that the default flashing setup on that program is SPI mode DIO - whereas I use QIO in my setup on Eclipse. Sadly that is where my expertise stops as I have no idea what the difference is and how if at all it might affect things.

    1. Thanks Paul. I'd test that and leave it at that... but I don't like not knowing what's going on so firstly I'm wiping all 4 1 meg pages using QIO mode. If that fails (it takes a while) next stage will be to do what you did. Need also to understand why 0x02000 should be any different to 0x2000 (I fixed the blog regardless).

    2. And just for a complete test.

      Brand new Device - Flash Pete's code - Reboot Loop.
      Then Flash NodeMCU - Works
      The Flash Pete's code - Works.

      I've now done this on 3 devices.


      1. Thanks Paul - I think you've hit on a fluke but I'm glad it is working for you. I've tried that integer file of yours on the two dead boards - and they remain dead. Just the power up 78k stuff then they are dead.

        Still experimenting.

        1. Just so you know Pete.

          These boards have not be tweaked. I have ordered some of the memory upgrade chips but they haven't arrived yet and will only be upgrading the SonOff's



  35. No good for me either. FWIW I have been merrily blowing earlier version ROMS from different PCs, using different programmers, to various ESP-12s with no problems. It's just the recent iteration that is problematic.

    1. The only thing new about the most recent version is that it has a couple of fixed commands and one new one. But I can both blow that on top of an existing working board - AND OTA it. This is really not making sense - any more than the fact that the programmer will NOT let me program a 1 meg blanking file at 0x300000... but it will let me do it at 0x2f0000

      1. Aside from the fact that I can't wipe the full 1 meg at the end with an address of 0x300000 - I wiped up to a base of 0x2fff000 - and that STILL did not sort out the issue - so unless there is something nasty hiding in that top 4K - I've no idea what has happened to the boards - I have three of them. Even if there was something seriously wrong with that flasher that it can indeed tell the difference between 0x2000 and 0x02000 - I cannot imagine what it can have done at "0x2000" to stop these boards working that cannot be fixed by erasing them - nothing I try will make them work again.... clearly we're missing something here.

  36. Hi guys - I want to assure you that this has NOTHING to do with the ROMs.... see the updated blog - near the bottom - this morning having taken out 3 boards, I continued to play with this issue that I cannot seem to FLASH a full 1MB at the top of the 4 MB. I took a perfectly working board and tried... the flashing got just a little way through and stopped.... so this was something that was going to fail on any board - need to get to the bottom of it.

    Anyway, I had that NODEMCU software sitting at the bottom of the programmer so I swapped the ticks over and programmed the NodeMcu software. BLOW ME it worked - so I blew our software from scratch and all was well.

    I'd given up on the other 3 boards yesterday but I thought "to hell" and tried blowing the NodeMCU software onto them - in all THREE cases the NodeMcu software came up - I then reprogrammed the boards using my normal Eclipse software - and lo and behold they are all perfect.

    But the mystery deepens: I got hold of Aidan this morning and he build 2 brand new boards up using virgin ESP-12s straight out of the packet. I got him to download the NodeMcu programmer - and he blew one with that second ROM at 0x2000 - and the second with the second ROM at 0x02000 - exactly as I would have expected before yesterday, both boards worked PERFECTLY.

    So there is a mystery going on here, call it cosmic rays, call it power issues??? I've had 2 power cuts since yesterday which means my PC has reset (the uninterruptable is only good for an hour and we had a long one last night) - that is ALL that has changed.

    All I can say is I now have NO failed boards. John - I have no idea why - but humour me - shut the lot off - load up - blow that NodeMCU software and let us know what happens.

    Need to get to the bottom of this - and when you look around the web for this issue - time and time again - the word POWER is used.

    1. Hi Guys,

      Since I also had this issue, which I found I could get around by blowing the nodemcu software first.

      I took the time to wipe my development machine (windows 10 reset) and start from scratch.

      I followed the development environment setup from here -

      The using git in eclipse got the latest copy of Pete's code from here

      tired to compile but it failed.

      The installed Python 2.7 from here -

      tired to compile but it failed.

      then found missing esptool2.exe from Richard Burtons (rboot) from here

      Put this into c:\esptools (It's in the makefile so you could of course change the location.

      Ya, Pete's code now compiles. And will successfully blow code to any device i have given it.

      I wonder if there is a bug in the ESP8266Flasher.exe

      So today I have flashed 1.4.8 to 10, esp-01's and 6 esp -12's which will OTA but there's no change in the code so i can only assume it works. And 14 SonOffs.

      So as i see it I dont think there is going to be an easy to find out what caused the problem.



      1. Thanks Paul

        I (and presumably others) thank you for taking the time to document this and indeed to clarify that my success here was not a one -off. I think the solution here until we know better is to avoid using that ESP8266Flasher as I could not even begin to guess how many chips I've blown with other tools - other than to guess it is many, many hundreds - and I've never had this issue before.


          1. Hi Pete,

            I dont know, but i'm now running :-

            Eclipse IDE for C/C++ Developers

            Version: Mars Release (4.5.0)
            Build id: 20150621-1200

            When I pointed it at my previous workspace(dropbox) it said it would update things, and may no longer work in older versions.



  37. Pete
    I'm a bit unclear on how to proceed. I have repeatedly tried to upload the roms using NodeMcu programmer and on each occasion I get the flashing led and the 74K serial stream. Are you saying that the remedy is to firstly try to upload to 0x03000

    1. No - I tried to run a 1 meg blank file on one of the boards and that failed - but on the other two ALL I did other than a reboot - was to install the nodemcu software at 0x0000 and they came back up. In total I got 4 boards (all of the ones I'd messed up) back up and running.

      You say "roms". Try to install the nodemcu rom at zero - that should work and say that something is missing - then you can load my roms normally.

  38. Forgive me for being stupid but..
    What is "nodemcu software"
    I have nodemcu programmer but am not familiar with this.
    Also for information, my "dead" ESPs will also not respond to another programmer I have "flash_download_tool_v1.2_150512" but strangely are quite happy being programmed in the Arduino IDE environment.

  39. Hi Peter,

    I'm still having problems getting the board runing with the roms. Could you create exactl tutorial how to get them working with the flash fix process?

    Thanks for the hard work!


      1. William - and others - I can't do a tutorial on programming chips - as you can see I was as easily caught out as others.

        Rather than comment further in here - I will update the blog with what I think we've learned.

        I and others have gotten back now to where we were in the beginning - there is nothing wrong with the ROMS - we can program boards, we apparently can resurrect dead boards though it is not clear why they went wrong in the first place. Look out for a blog update.

  40. Ondrej
    I've just restored mine to full health. I deleted my mcu programmer and downloaded the most recent version. Then downloaded the node mcu software (see Pete's link above)
    and upload it at address 0x00000.
    Mine failed the first time and had to do it again.
    After that upload romx and rboot at addresses 0x00000 and 0x02000 respectively.
    good luck

    1. Hi John: I would hate to think all that hard work on our behalf was down to a duff programmer. Though I thought I had the latest version. Oh, well. I'll put something together to use the programmer I normally use - it's not as pretty but it doesn't cause issues. Glad you're sorted.

      Ondrej: I don't know enough about those NodeMCU boards to help. I had one some time ago and for reasons I could not fathom out I could not program it at all. I think you'll see in the various comments in this blog everything that is needed to program the ROMs. If you have a list of specific questions - fire away.

      1. Peter

        In some of his most recent videos Peter Oakes makes reference to a command set that can be used in the serial terminal. You also make a reference to that . I have tried and failed at every step to make this work and I am wondering if having access to this command set might move the ball a little further. Can you please provide a link to it? I know you are besieged with requests and Ihope that you can help. I really want this towork but sofar tono avail.


        1. Bill - all the commands can be sent either by MQTT or by the serial terminal. Commands need wrapping in {} and examples are shown in the manual that comes with the source code. It is a WORD document. If you are not using the Eclipse serial terminal you need to ensure you send a CRLF at the end of the lines.

  41. I normally do not use that NodeMCU software. For those who have not looked at the source code, an extract from the flashing part.

    $(ESPTOOL) -p $(ESPPORT) -b $(ESPBAUD) write_flash $(FLASH_OPTS) 0x00000 $(RBOOT_BIN) 0x02000 $(RBOOT_ROM_0)

    If you were to convert that into a specific example it would be in my case....

    c:/espressif/utils/esptool.exe -p COM3 -b 115200 write_flash -fs 32m -ff 80m -fm qio 0x00000 rboot.bin 0x02000 romx.bin

    As I have recently discovered - from around SDK 1.54 onwards - the very first time a chip is blow, at least one more file is needed..esp_init_data_default.bin

    $(ESPTOOL) -p $(ESPPORT) -b $(ESPBAUD) write_flash $(FLASH_OPTS) 0x00000 $(RBOOT_BIN) 0x02000 $(RBOOT_ROM_0) 0x3FE000 $(NEWSTUFF)/blank.bin 0x3FC000 $(NEWSTUFF)/esp_init_data_default.bin

    Also - for me in trying to narrrow down the issue here - I found this far more useful than a bunch of large erase files..

    c:/espressif/utils/esptool.exe -p COM3 -b 115200 erase_flash

  42. Gentlemen - would you please try the current ROM files at - I have spent most of the day on this, slowly disappearing down a hole - until out of desperation at seeing only partial startup messages appear, I went BACK one to SDK 1.5.3

    At which point... I hate to say this - all the problems went away!!! But please also note I've been making changes to allow the use of GPIO2 as an output etc so you need the DOC file from the web.

    Two of us have now verified there is an interaction between SDK 1.5.4 and RBOOT -code reverted to 1.5.3 and ROMS updated. All working well.

  43. Peter!!!!

    Success!!!!! Thanks so much for your hard work and persistence with helping newbies like me get this going. Now, on to implement some control, monitoring, and features in my home environment.

    Thanks again!!

    Bill Miller

  44. I hate to rekindle the issue of the roms, but.... are the roms that are linked on this page up to date or have they been modified recently. I now have a non functional esp12 (attached to Nextion board). Although upload process is successful, it will not boot and seems to get stuck in the 78k mode.

  45. No joy. When I run the line
    c:/espressif/utils/esptool.exe -p COM3 -b 115200 erase_flash
    I get
    head: 0 ;total: 0
    erase size : 0

    That doesn't seem right for a start.
    And the updated roms behave the same for me.

    1. If I recall correctly - Espressif changed that top sector to use some kind of new RF-calibration around 1.5.3 - I've just recompiled the ROMs using 1.52 - and uploaded the ROMS.

      On the subject of the erase-flash - I can't seem to get answers out of anyone on this one - it works for me - says job done.. but I've no idea if it is erasing the full 4Mbytes including the system sector way up at the top of the 4th meg. When I tried to use a 1 meg empty file at 0x30000, it would not let me but if I tried a base 16k lower, it did - indicating that the system info is being write-protected. I've no idea if esptool.exe overwrites this - kind of an utter lack of information on this subject really.

  46. Those roms didn't work either.
    It looks like (for me anyway) the ESP12 is compromised. Now my problem is how to to extract it from the Nextion board and replace it.

    1. It would really help if we could get some info out of Espressif as to how this might happen. As far as I'm aware, starting with a fresh clean flash things should always work - and using the ESPTOOL to wipe the flash should present us with effectively a new unit. But in the absence of solid info I'm not convinced this is the case.

      I wrote off to them today... in their forum in the hope someone can clarify.

  47. I've tried every method of erasing the flash, including in the linus environment. Then when I blow the roms....
    I repeatedly get this. Does it mean anything to anyone?
    Fatal exception 0(IllegalInstructionCause):
    epc1=0x4020237e, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000054, depc=0x00000000

    ets Jan 8 2013,rst cause:2, boot mode:(3,6)

    load 0x40100000, len 1344, room 16
    tail 0
    chksum 0xef
    load 0x00000000, len 0, room 8
    tail 0
    chksum 0xef
    csum 0xef
    csum err

  48. I can't comment on the Linux environment as I use Windows. Those instructions (as usual) mean very little to me. I just wish Espressif had put a little more effort and code into this and actually given us a useful error message at a standard baud rate.

    Meanwhile locally I've update RBOOT to the latest version - made no difference at all for me. 1.52 works fine - 1.5.4 and 2.0 actually miss out the first function call in my code! Or rather any output from it....

    Hmm, I'll check that next.

  49. Peter

    In the node-red diagram on this page there is a node that is titled login from boards. I can't seem to find this. Is it a node that was not installed with "the works" or is it another node that should be used and customized? If so, what is the name of that node? As always, thank you.

  50. I flashed your firmware to a NodeMCU dev board and successfully connected it to my mosquitto/node-red installation, using your great guide, but now I'm struggling with wiring DS18B20 to it. I connected data wire to GPIO2, grounded both vcc and gnd wires (parasite mode) but alas, {in2?} and {temperature?} returns only this results:

    Tried to wire gnd to gnd and vcc to 3v3, but result was the same.

    Could you help me to find mistake in wiring, or where to find a proper documentation how to do it? I read almost all of your blog posts and comments, but couldn't find a working recipe 🙂
    Thank you.

    1. Not sure where you got parasitic mode but I make no attempt to support that. Connect the +v of the DS to 3v3. You have to select the mode for the temperature sensor and define which pin to use. This is in the manual which you should read. set temp_type to 0 and temperature_port to 2

      From that point you should be able to poll for temperature and an automatic mqtt message will also be sent out at regular intervals.

      1. Yes, I did this type of connection too. Connected +V to 3v3. Sent through serial console {temp_type:0}, then {temperature_port:2}.
        After that I send in serial console command {temperature?} but it always returns 0 ( nodemcu01/fromesp/temperature=0 )

        Is it a bad wiring, or I should check something else?
        Thank you.

  51. I had the same Problem as described in the above post.
    I'm testing with one Sonoff and two ESP-12 using DHT22 and DS18b20 sensors.
    I connected them to gpio2 and gpio14 and always get "fromesp/temperature=0"
    What I'm doing wrong, any idea?

    1. Make sure the two settings as described in the manual are set correctly - and make sure you have a WIFI and MQTT connection - and wait a couple of minutes max after the connection is made. I've improved the debug today with more info.

  52. This is a fantastic blog and your work is very much appreciated. I have been looking at souliss and mysensors etc for the last year or so , without a great deal of success. I now have two ESP12-e's running as sensing nodes, though node-red which im going to hook up via openhab2.

    One function which would be really great would be an interrupt driven i/o pin for a pir. This may exist already apologies if it does. It would need to operate on the basis that when the pir output goes high, the interrupt is triggered and issues an mqtt message. This would save constantly polling the device pin to read the output and save a bit of power as my nodes will eventually be battery powered.

    Keep up the great work, ive ordered a couple of i2c display's, that's the next bit of my project.


      1. Hi Peter,

        Many thanks, that looks like it should do the trick.

        My sensor needs 3 inputs (DHT22, PIR, Photodiode (light level measurement), i can only see two available, How can i get a third?

        Would it be possible to make the I/O's user configurable; there is the port2out command which changes I/O 2, can this be implemented for all I/O lines, i.e. a portXIn and portXout?

        Kind regards,


        1. There are two inputs - one can handle one of 3 different types of temperature sensors (or none) and the other is a debounced input. I've no plans to change this - with the source of course you can do anything you like.

  53. hey Pete, Having trouble with a Sonoff, what is the Flash size in these? cause im reading 1MB but i can only get it to Flash the rom at 256Mb! ?? puzzled... any help would be really appreciated..

  54. Would anyone know why my ESP8266 programmed with Pete's script continually sends a '+'?

    I'm sure it's something I've done but I'm not sure what. The board is a LoLin NodeMCU board from Ebay.

    Here's what I mean.....

    ESP Starting...
    GPIO4 and 5 are outputs.
    Current web programming pin: 0
    GPIO13 is a LED indicator.
    Software version 1.5.67
    SDK Version: 2.0.0(656edbf)
    Use the {debug} command for more information.
    STATION mode
    Web page control enabled
    Connected as 192:168:1:117
    MQTT connecting
    MQTT Broker connected
    Device ID is emma
    and so on - ad infinitum.


  55. "That is definitely due to the software seeing the WEB PROGRAMMING BUTTON being held low."

    Many thanks Pete. I made a schoolboy error but I couldn't fathom what caused it.
    {out0:1} fixed it.

  56. Hi Peter,

    sorry for bothering you again, but I can't get reading of the input 14 change to work.
    I looked at the manual, the part about debouncing, where is stated, that change on the input will result in sending the state over mqtt.

    I get nothing. Do I need to set something or?....Thanks for the help.

    Great work Peter!

    1. Hi there

      Ok, I've just tested a board I happen to have on, doing work on the PWM I2C chips -I have MQTT-SPY (there's a new release incidentally) looking for freddy/fromesp/# as the board is called freddy.

      After a minute of sitting there I saw the auto-temperature reply come back.... and then when I shorted GPIO14 to ground and released it, I noted the messages coming in from freddy/fromesp/trigger14

      So it is working no problem.

      For reference I am using version 1.5.68 of my software on that board.

      1. Oh, I had old versions of ROM and RAM. I'm using sonoff relay boards. I have followed instuction by Peter Oakes, but he doesn't use the third file, that you are uploading on the boards.

        Should I use the third file with the sonoff boards too? I think they only have just 1MB of memory.

        Thanks for the help.


        1. The third file is for new installations only - it has Espressif setup info. There are different flashing locations for the smaller chips because of the differing sizes. I seriously recommend only using boards with 4MB of FLASH - soon the project will grow beyond the ability of an ESP-01 board. The Sonoffs will work fine but again I am replacing the FLASH on mine with the 4MB part - which, as I will never use more than 1MB (plus same again for the OTA alternative) will leave a MEG for logging just as soon as I get that up and running - not a priority right now however.

  57. Hello again Peter.

    Is it possible to modify the code, or change the configuration to use the button (GPIO0) to control the relay directly?
    I just bought the WIFI smart plug and used your code, it works great, but this feature would be very handy.

    Thanks for the help.


    1. As it is Sunday and I was sitting here anyway.... I've implemented this - you need the WIFI button set to 0 - and the sonoff mode set to 1 - and you'll find that the GPIO button will toggle GPIO12 on and off with debouncing. The status of the output is not stored in FLASH so whatever REMOTE status you'd set will resume after powerout...

      Enjoy. Source is up - ROMS will be updated today.

      1. Hello Pete.

        You sir, are amazing!
        Thanks for a such quick response :). Tested your code few secs ago and it works great.


  58. Pete, I have a question but I really want to thank you for being such a great source for information and research. I have adopted the Home Control Code and am building everything around it here in Tennessee USA.

    My question is about the out command. I am attempting to use it to have a single relay close a set of contacts for around a second. If I am reading things correctly this would need to be formatted:

    It does work but only down to three seconds. formatted {out:0,6,10003}.
    If I use the one second timer value it turns on but not back off.
    Hardware I am using an ESP01 with GPIO0 (non inverted). I was just wondering if I am fighting the ESP01 or something in the code itself. I will be trying and ESP12 when I get home tonight but I figured I might as well ask.

    1. You are correct about the timing - because you could be sending the command at any arbitrary time but the timer is using the real time clock, there would not be a lot of point in letting you set the timer for 1 or 2 seconds - 1 second could be as low as zero, 2 seconds could be as low as 1 second worse case - so arbitrarily I set this to 3 seconds minimum.

  59. Hy,
    I installed all the staff needed to make a build and got quite far, but get stuck on this when trying to build your latest HomeControl2016 file. Any idea what is wrong?
    user/petes_code.c: In function 'readDHT':
    user/petes_code.c:1058:5: internal compiler error: Segmentation fault
    temp_p /= 10.0;
    libbacktrace could not find executable to open
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See for instructions.
    D:/Leo/Eclipse/HomeControl2016/Makefile:300: recipe for target 'build/user/petes_code.o' failed
    mingw32-make.exe: *** [build/user/petes_code.o] Error 1

    I am missing something in this function

    I am using Windows 10 x64,so using the windows makefile

    1. Good to know there is some problem in petes_code.c:1058. I made a wild guess when I read the fault message and changed temp_p /= 10.0; --> temp_p /= 10; and voila no faults anymore. Don't ask me why, I am practically a C illiterate!

      1. Hi Leo - not sure it's a good thing if there are faults - but it's a good thing you noticed. The high temperature stuff is integer - and I'd been dealing with floats. Suitably amended.... thank you.

  60. Hi
    Can someone point me in the direction of what i need to compile I just seem to keep going round in circles.
    I am using windows 7 64bit with sonoff(1mb) or ESP12F(4mb).

    1. You need to go get the unofficial Dev Kit for Windows which includes Eclipse (I believe I mentioned this on the blog). Once you are happy it is all installed - grab the latest SDK and replace what is in there unless it is already 2.0 - and then import the project - stuff it in a directory and import.

  61. Hello Pete.

    I finally downloaded your code to my esp boards and got them to work! YES!
    I was just wondering, if it's possible to read from multiple DS18B20 with your sw, or it would be easier to find code for arduino and use it to send data to my nodered server.

    Thanks for the info! Ondra

    1. I only attempt to read on - the general assumption being that in a typical location you might need to control something, maybe read temperature, humidity, pressure, light level.... so all of that can be done with one board (with add ons) - I could not see the point of multiple temperature sensing in one board. Might be better to find something designed for the purpose for that.

      1. in my case, a rack server, i needed 2 probes, 1 in the front, where the air conditioner blows, and 1 on the back, where the hot air exits from the servers... but i have a commercial product, which has umidity, flood, smoke and other sensors, too, and a gsm modem to send alerts in case of missing connectivity...

        i'd like to test the new BME680, which adds a gas sensor to the ones already present in the BME280, but cannot find it anywhere...

  62. I am stuck after blowing the ROM!
    I flashed the 2 files to the Sparkfun Thdev. with NodeMCU and that seems to be OK. I was watching Peter Oakes's video and he connected a terminal to the ESP board and voila there is the seekign Wifi msg. I connected my Arduino IDE serial Monitor to the Spf board and put it to 115230.
    I did run a number of programs from the Ard. IDE before and no problems with the serial Mon. However with your code flashed I only get gibberish in my Serial Mon. I also do not see a flashing LED at GPIO13.
    Can I use the Arduino Ser.Mon or shall I use another terminal program? I tried Coolterm_0 and get some error when trying to connect "Framing error 104" and no comm. with Ard.Mon. I see the serial LED on the board flashing and that is what the Ard Ser. Monitor shows.
    I really need to pass this hurdle otherwise nothing goes anymore. Any suggestions where to look for guidance?

  63. Update trying to connect to ESP on Sparkfun.
    Downloaded CooltermWin. found out that there is communication at 74880, which was one of the options in the Serial Monitor of Arduino IDE. Put the non standard baudrate into a file in the same directory as CooltermWin. Reflashed the ROM with a much slower tx speed 115200. Same result as with 921600 what I use for all my Arduino sketches.
    It seems the ROM is not booting and keeps transmitting the following:
    rBoot v1.4.1 -
    Flash Size: 4 Mbit
    Flash Mode: QIO
    Flash Speed: 80 MHz
    rBoot Option: Big flash

    Booting rom 0.
    rf_cal[0] !=0x05,is 0x00

    ets Jan 8 2013,rst cause:2, boot mode:(3,7)

    load 0x40100000, len 1344, room 16
    tail 0
    chksum 0x9c
    load 0x3ffe8000, len 660, room 8
    tail 12
    chksum 0xbe
    csum 0xbe


    This text comes out of ESP Sparkfun Thing Dev. This only has a 512 kB ROM so no OTA, but that is for a later stage.

    When I put the speed on 115200 than I only get:
    rf_cal[0] !=0x05,is 0x00 and then a framing error 104.
    No flashing LED on GPIO13 too.
    Can you make sense of this to explain things going on?
    Do I probably need to load another rBoot version. I could enter the entry point of your ROM with hex editor?

    1. Flash size 4Mbit?? My code won't run in a board with only 512KB. Consider an ESP-12 or similar with 4MB (32Mb) of Flash. It will run with 1MB (8Mb) - but you can't OTA. I thought devices with that little FLASH were just about defunct now (ESP-01 etc).

  64. The 78K information is debug info that comes out of the ESP on power up - that cannot under any circumstances be changed. Normally after that you would set up in the user code what speed to use - I set up 115k.

  65. OK thanks to let me know, I did not estimate that size. I have an ESP-12F and am now setting up wiring on a breadboard with a 340G flasher.
    I had this small mem setup with 115k and it showed the first moments before it died because of too small mem. NodeMCU does not know it is writing in the air and still gives a green sign.
    In another thread I asked for your Flow. Can you send this to me privately in aPM. I know I will learn a lot from it. So please do me a favor I won't ask anything about it.

    1. Hi there

      I think I mentioned elsewhere that I have no intention of releasing my set of flows - they are way too complicated and specialised to perform specific tasks in my home - they would not be much of a learning tool for you and I would be faced with more questions than I could handle. Do you have any specific tasks you wish to perform? I would say the easiest and most interesting part of setting up a home control system in the way I have - is Node-Red as you can build things up in stages. MQTT is the central communication method - you simply pull in messages or use timers to create conditions - and send out MQTT messages to control boards or to request information.

      The first thing to do is set up the simplest of nodes. One for example to wait for incoming auto temperature readings from an ESP - when that message comes in - send the output to the debug node so you can see for yourself what is happening. Also you can use an inject node to send a message out via MQTT to say, a relay driven by an ESP8266. Once you see these working - everything else will slowly fall into place.

  66. Hey Peter. Firstly, thanks for releasing this code and the comprehensive instructions. My Sonoffs are working perfectly with Home Assistant thanks to all your good work. One question though. I have a Wemos D1 miniand a 1 Button shield. I've flashed the Wemos with your firmware, and wondered whether I could configure it to operate as a simple one button MQTT thingy...essentially, I just want to be able to push the button and it publishes to a topic. The shield I have is not well marked, but looking at others I *think* it uses D3 on the Wemos, so that's what? GPIO0? I'm wondered whether I can easily use configure your firmware to detect button presses and publish to my MQTT server. Thoughts? Cheers!

    1. See my other reply. Compared to the Amazon button which takes a second, I found waking up an ESP, sending an MQTT message (and getting a reply which is almost instant) and shutting down (to be woken by a reset) takes too long, over 2 seconds. IT works just fine - but I think I like the shorter timespan. See my latest blog incidentally - there's not just my code for the Sonoffs.

  67. Hi Peter, thank you for all the effort you are putting in this project. I tried several firmware and I have to say that this is the most resilient I could found.
    I would like to suggest to add in the esplogin (and of course inside the firmware) the altitude of the site, in order to compensate the pressure read from the sensor.
    Maybe it is possible calculate automatically from some googlemap (or similar) API using the coordinates, but I suppose it is much more easy just to insert as a parameter.

        1. Not entirely sure I see the point in this - if Google can get that value, then for any given installation - it's fixed - just enter it in! Also it needs longitude and latitude in floats - my parser does longs and strings only... so that doesnt' help... thanks for the info though.

          1. Hi Pete, thank you for the reply. I also used the easy way and I compensate directly into the node I use to decode and assemble the data.

  68. Hi Pete, it's again me
    I'm using since couple of month you firmware to drive the relay for the thermostat.
    Everything worked well since I changed one of the two access point at home.
    In reality the previous one has a stable connection and the ESP never needed to swap on the second wifi. By the way now happens and I noticed something that could be a bug.
    When the esp swap 1) the uptime reset to 0 maybe it is normal but 2) even if the out16? query returns an ON (or OFF and still has the state having before the wifi swap) the relais receives an OFF signal. Is it 1 and 2 a normal behaviour ? My issue is that I monitor the gpio state exactly to avoid any problem but in this case the state seems returning an incorrect data.

  69. Hi Peter, awesome work mate, enjoying following this and other blog topics on your site. I have loaded your code on to an esp8266-01 model and connected a relay to gpio2 (used "port2out" command) as an output. I have the relay working using Node-Red flows on a Raspberry Pi 3 working fine although my relay board requires a low (gpio2=0) to activate the relay, opposite to what would normally be expected but there you go. I can use the "invert or "invertset" commands to invert the output of gpio2 and that works as expected, all good so far. I thought i would try the "mist" command as that looked very useful for a watering system but what I'm finding in my case, at the end of the cycle of on/off repeats, eg. {mist:2,5,5,10}, the relay stays on even though i have set the inverse command for the gpio2 pin. i have tested using the mist command via mqtt and via the serial interface with the same result. seems the mist command ignores the invert setting. I rearranged the gpio and tested on gpio0 with exactly the same results. Would be interested in knowing if this is the expected behavior or am i doing something wrong. I will eventually move to the esp-12 or something similar depending on the requirement but for now i only have the 01 model to play with. I have also tried combinations of moving the wifi button between gpio 0 and 2, power resetting after making changes and verifying the settings after each change, without success.

    Anyway keep up the awesome work and look forward to seeing further enhancements etc.



    1. Right - fixed - indeed I'd forgotten all about the inversion on the mister which I just developed for my own misting system - never occurred to me someone else would use it -= fixed for all ports.. give it a go and let me know.

      WARNING - thanks to the inability of my service provider to fix a longstanding upload bug I can't upload the OTA fix right now - probably by lunchtime - but the source is updated...


  70. excellent, a bit late here in NZ to try now so will download the updated files tomorrow and let you know how i get on with the "mist" and "invert" command combo.

  71. Hi Peter, I downloaded the entire repository and extracted the bin files from the firmware directory assuming this would be synchronized to the latest updates? flashed both bin files using the nodemcu flashing tool under windows.

    after testing the mist command again it still didn't work, output of debug? is showing firmware version 1.7.7.

    to ensure i had the correct bin file i downloaded the latest commit e6e71b7 of file romx.bin and re flashed the esp8266-01. firmware version is still 1.7.7 and the invert command is still being ignored when using the mist command. one difference from my original tests before upgrading, I now have to issue an {out0:1} followed by {out0:0} before the relay is switched off (the invert works for the specific gpio commands. Previously I only needed to issue (out0:0} to switch the relay off (remembering i have invert set for both gpio0 and 2). I have tried the same on gpio2 with the same result. So unless I'm doing something wrong it seems the mist command is still not honoring the invert settings, my relay stays on after the end of the mist cycle.

    1. Absolutely right - I'd done it entirely the wrong way - in fact that never worked properly - just updated and tested a lamp here. How such a simple thing can take so much work.... all updated now including binary


  72. Hi Pete, thanks for looking into this, downloaded the latest version 1.7.8 and tested fine with invert now being honored with the mist command. All working as expected.

  73. I still have problems with otaupdate. Depending on the weather(I cannot find any other pattern) the otaupdate command just gives me E:M4392 and E:M 5856 and failed to update. When looking into this at Richard's site this error seems to happening when defining the wrong address range. This link says something about how to handle this situation, but that is beyond my knowledge what you did in your FW. Earlier on I signalled this situation too and it results in messages of Bad ROM1. When you completely wipe the ESP8266 and reload FW then sometimes it does not give this problem till the weather gets wrong again.
    Any thoughts about this. Supply voltage filtering???

    1. After further investigation I only have 1 ESP8266 which I cannot otaupdate at all. I ran them all through the flasher and the other ones had a succesfull otaupdate. I can only see difference in antenne pattern on the failed one. I happened to have another of the same type as the failed one. I was wondering if there was really 4MB in it and with " -p PORT -b 115200 flash_id" I found out it indeed has 4MB. The new pc has the same problem with OTA! So I conclude I cannot use these and are probably fake ones? I am very unlucky with my orders to China, the 2nd attempt ordering them will fail to be delivered the day after tomorrow. But how to guarantee I get the right ones?See the picture of the OTA failing ones

      1. I can only say that this has never happened to me. Certainly not with ESPs - though clearly some of the rock-bottom priced stuff from China can be less than ideal - and they tend to overclaim capacity on batteries by some way but I've never had a bad ESP.

        1. Still I am deeply concerned about your OTA procedure. On other pcs it fails regularly with error messages or it does not boot after success leaving the ROM in an unusable state(program not started because no blinking LED on 13). See this:
          The normal operations all are working well only this bootup problems after otaupdate makes me driving away from HC2016, sorry to say. I am at square 1 for the main control system.

          1. Well, if you chose to abandon the project then of course, that is absolutely fine - but you are as far as I'm aware the only person complaining about the OTA procedure which suggests, given the feedback I get, that no-one else is having issues - of course - that can be misleading).

            So let me assure you and others by experiment, that the OTA procedure was put together with the fellow who developed it and has worked very reliably.

            Just in case anything had changed recently, I have just taken a standard board lying on my bench and checked, via MQTT, the version number which returned 1.7.1

            I then ran the OTA code {otaupdate} - the board responded with "Attempting OTA".

            I waited for 30 seconds and ran the {ver?} command again - and the board responded as version 1.7.8

            This operates perfectly. If it does not work then I suggest the issue lies either with power supplies or with boards NOT using the 4MB Flash Or with invalid information for the ota_host. Note that a 512KB unit may be described as 4Mb - i.e. 4 mega-bits.... the ESP12s in every case I've come across - come complete with 4 mega bytes of Flash - i.e. the first 2 MB are used for the two swap images each of which can be just short of 1MB.

            For the sake of completeness, I then took another unit which was gathering dust in a corner and checked that, it was very early at version 1.2.5

            I ran the command {otaupdate} and this unit too replied "Attempting OTA". I waited several seconds for the unit to update and reboot.

            Sure enough - it returned version 1.7.8 on request which means that not only had it rebooted - but had rebooted with the correct update in place.

            There is nothing wrong with the OTA procedure. You might want to check that the {ota_host} request returns "" (without the quotes) and that the {ota_port} request returns 80

            when I say "" I mean that, not http: or anything else, just ""

            The two boards on test were based on ESP12 modules.

            1. Incidentally I have yet to see a FLASH that cannot be brought back to life. If for any reason a board which was otherwise working perfectly seems to fail, if FLASHING it in the normal way does not work - note the comment about adding the Espressif information into the flashing procedure. If this has been altered then that would stop boards working - re-flashing restores them. I believe that is covered in this blog entry.

  74. Please note all that as of today (15/01/2017) there is an update to the ESPLOGIN node - it is not AT ALL critical - just a bug that was returning an incorrect error message. You can just install over the original - no changes that affect operation.

  75. I was away for the day but am glad you take my problems seriously. I have a question: can try to otaupdate when there is no change in firmware 1.7.8. Still no problems with you then I will dig deeper with complete different supply. I use those 5/3.3v combination which you see delivered on a lot of breadboards fitting over the edge of the BB. I also wil start producing a soldered programming board. What I see on my breadboards is very regular interruptions of signals(my test leds blink shortly) not always critical, but during programming this might be fatal. There is also the verify command in the that I will investigate. I really hate to leave the project, a lot of knowledge down the drain. So I will pursuit things a bit more now I know I am the unlucky person.

    1. A note - and this is just my view - I would never use a switched supply directly to an ESP8266. I tend to use boards with 3v3 analog regulators on them and feed those from a switched mode power supply. Some of the supplies coming out of China have very poor regulation and don't forget that although the average consumption of an ESP is not high, they have a tendency to need more current on startup and when sending info... so make sure you have a good margin. Comments in here over time suggest that for those people who do have issues, power tends to be the major culprit. There should be no interruptions to signals. If you are getting that, then you need to resolve the cause before considering problems with software etc.

      The ESP code I developed with help from others has been tested over time and works - rock-solidly, come access point failure, power failure and more. One of my installations is in Spain where I did most of my testing - up a mountain with atrocious electricity reliability and stability. If the ESPs and software can stand up to that (the Raspberry Pi running all of this is on battery backup) in my absence for months at a time, I think it is fair to say that the problems most likely are elsewhere.

  76. I've built a new programming device with most soldered wires. Still get the same problem when doing otaupdates. That could be power or internet connection. 3.3V has been supported by 2 times 470uF and very short wires, the an. reg. is AMS1117 and voltage is very near to 3.3. I have no scope so I cannot check for noise which drops the 3.3V. But the only trouble is with OTA. Your clock is no problem(separate 5V!) with all the high frequency switching. PWM working perfectly. According to datasheet max. current during writing is ~170 mA, the regulator is nicely WARM(<50degr or so). What is wrong with AMS1117? Do I need to use heavier stuff? Do you use high freq. filtering with low resistance/ind. capacitors? I doubt it is the problem and also not your software. But I really have doubts about the OTA/bootloader procedure. It works a few times without problem and then I get a suite of failed ota, I reloaded the rboot.bin and data_default file from your site to be sure using the latest. I find one complaint on Richard Burton's site ( ) about the same problem, but that is not really ended into a conclusion what went wrong in there. The remark of piersfinlayson about limiting some mem alloc did helped for him, appparantly knowing the problem, but that goes over my head and I don't know where they are talking about. You might recognize what it means! When I Google for E:M 5856 I find this happened to someone else, but no conclusion in your HC2016 blog about that.
    Interesting to say I never had issues with erase_flash and NodeMCU flasher after that, so serial is very much OK(nothing to do with ota, but still writing to flash as is done with ota). The only other problem is internet connection and data integrity during the downloading although very very unlikely. I download files for years and years and NEVER had ONE file which was corrupted because of data transmission interruptions.
    I can be patient, but these problems are nerve wrecking.

  77. hi Pete, I have another question around the mist command; im playing with Node-Red to monitor the status of the gpio pin using an inject node with a payload of {out0?} (repeat interval every second) and debug the return message from the esp, that all works fine. When I send a mist command to the esp (either using mqtt or serially) the gpio state is always off regardless of of actual state i.e. relay is activated and deactivated or pulsed (remember I'm using the invert on the grio pins 0 and 2 as my relays are active low) according to the mist command {mist:0,5,10,10} but checking the status of the gpio pin for both relay on and relay off, still reports the gpio0 as off! is the correct, does the mist command somehow bypass normal query commands? Im not a programmer so can't make use of functions within Node-Red (at the moment but hopefully over time I will teach myself how to do this) so im using Boolean logic within flows to take action based of the result of the relay status (gpio pin status); Im getting false readings because of the issue mention above. Does your code tell the esp to publish the state of gpio pins (gpio is output) when it receives a command to change state? this would simplify my flow and not have to poll for the gpio state change but simply monitor an mqtt message from the esp. correct me if I am wrong, the esp reports on a regular interval the state of sensor information, temp/humidity etc. can this be selectively extended to gpio pins on a port by port bases i.e through an additional command to add a programmable reporting interval for selected gpio state.
    I guess i could feed the output back into another gpio pin set as input, will this trigger a mqtt publish message from the esp because of the gpio pin state change? on the esp-01 this method would be very limiting and would only allow a single relay to be controlled...

    by the way, reasoning for checking gpio pin state is to ensure as much as possible that the water is off at the end of the mist cycle and not stuck on... "trust but verify". Im also issuing the {out0:0} command as the "off" message within BigTimer although this doesn't work if using a manual override into BigTimer, the mist command keeps running to its conclusion, only way I have found to cancel the mist command is to issue a reset command as the "off" message instead.

    1. By the look of it - what you are doing is way overkill. Even if you were to monitor the state of the pins - if there was a fault you could not know whether the reported state was true or not. When you set a pin high (which might be 1 or 0 depending on the state of the invert system) you will get a response of ON.

      So - {out0:6,1} sets the output for one minute - the STATE of that output depends on the invert status... but the RESPONSE to {out0?} will be ON if you are within that minute - regardless of the INVERT status.

      In terms of confidence, I have a watering system which runs all year, part of which we are absent - thousands of miles away. The only time it has failed was when idiot pulled the water pipe out - you can never account for that.

      As for the mister, because it turns on and off, it never occurred to me to ensure that the checks actually reflected the state of the output, similarly in the event of a reboot, the output will not maintain it's MIST state but will be OFF (sensibly).

      So - if you would care to update - I have altered all of the outputs - which when in MIST mode now show ON or GAP accordingly - and OFF when done.

      I trust that meets with your approval.

  78. Hi Pete, thanks for the reply, you may be right in saying its an overkill, im still learning and experimenting as i go. I'll do the update and continue playing.
    Thanks again.

Leave a Reply

Your email address will not be published. Required fields are marked *