HC 2020 and ESP-GO

Introduction (Latest update February 01, 2020)

HomeMinor update here – I’ve gone back to SDK 2.1 for now as RBOOT will just not reliably OTA on SDK 3.1 – and there is nothing wrong with SDK 2.1

Sick of reading about other people’s home control? Want to make your own? Got some electronics and software experience? You’re going to LOVE THIS! Rock-solid home control, flexible, low cost, DIY.


On October 28 2018 I added the ability to optionally make gpio12 a temperature port (DS18b20, DHT22 etc) leaving 2 and 14 as de-bounced key inputs, from version 2.7.01. Also as of March 2019, optionally gpi4 and 5 can be set as inputs and can then produce automatic debounced status data – handy for up/down buttons for thermostats etc. See input45 and input54 commands in the WORD doc in the ESP-GO BitBucket repository.  By the time you look at the diagram above it will likely be out of date as new features are added (no indication of deep-sleep capability in here for example) and OTA using Espressif SDK 2.1 now works a TREAT (RBOOT-based OTA in SDK 3.1 version works but not every time so for now I’m sticking with SDK 2.1) – thankfully there’s a WORD manual along with source code and diagrams available online and kept up to date. This is all free incidentally and without warranty. Software, diagrams, board layouts… and this blog has a range of articles on the subject. The main ESP8266 software is freely available, called ESP-GO (also ESP-GO-3 repository but note comments above about OTA – something to do with SDK 3.1 and RBOOT) and is available on this BitBucket repository

The diagram pretty much says it all – a Raspberry Pi (2, 3 or 4 – I recommend 3 or 4) or similar (Orange Pi Plus 2E works well as do some FriendlyArm boards),  talking to your PC and/or smartphone via a range of potential technologies – and using a simple yet powerful communications protocol (MQTT) over WIFI to talk to small yet incredibly powerful ESP8266 units – these can be bought very cheaply (WEMOS D1 Mini etc.) and programmed – or you can take our board designs and have some boards made in China if you really want to DIY. This is all free and open source but don’t expect support on the boards.

There are no real limits to the number of ESP-8266 boards you can have talking to the central controller – that is down, in the main, to your WIFI network which could cover one room or extend across the globe.

In my own system I have 2 properties talking to each other – one in the UK, one in Spain. No matter where I am, I have full access – great fun, great utility, low cost. Who wants to pay £30 to control a light! This is definitely aimed at the DIYer.

In the coming link there is a complete project, suitable for Windows development using the ESP8266 “Unofficial Development Environment” for the ESP8266 – but that won’t stop Linux users from bending the makefile to their will!!

Here is the master repo https://bitbucket.org/scargill/esp-go/src/master/ See the doc file which is fully up to date with all commands  which the ESP8266 software accepts – this blog entry just shows a selection. Even if you ignore or don’t understand the source and just download the ROMS available – you’ll be able to keep up to date via OTA (over the air updating) – and you’ll need that manual!

You may also need some new – and very useful skills as you’ll see the term Node-Red appear very often throughout the considerable range of blog entries in here – this is by NO means a single item – there’s a Nextion-based, prize-winning WIFI touch display blog and a range of discussions (and there are LOTS of valuable comments) throughout the blog – enjoy learning and please do feel free to share knowledge – there is SO much more we can do with this.

Update on flashing ROMS here:  https://tech.scargill.net/esp8266-home-control-update/  – Blog reader Jay has written a great blog on setting up the programming environment for Windows.

ESP8266-terminalWhat is missing from the diagram above is my first experiments with SPI. Utilising GPIO13 to 16 on the ESP8266 (this is all in ESP-GO) , I have a 320*240 display working experimentally as a fast scrolling terminal on the ESP8266. Handy for debugging the system without tying up your PC monitor. I also have working drivers for the likes of ILI9341 (not the touch part).

How useful this is depends on how many other pins you need! If need an ESP8266 with many more IO pins – for around £1.50 (AliExpress) you can use my “universal peripheral” – using a simple Arduino Nano clone talking to the ESP8266 or indeed any I2c setup.

Background: I’ve been using ESP8266 chips since they first came out – and I have the development kit for that and the ESP-32 –just waiting for some decent, seasoned software tools to emerge for the ESP-32 but right now the ESP8266 is a lot of fun and that’s part of what keeps this all going.  In the summer of 2015 I made myself so visible on the ESP8266 front that I was invited to be part of an Espressif-led delegation to MIT in Boston for the FAB11 Conference – demonstrating the ESP8266 with MQTT and Node-Red and how to build this into practical systems. Some time ago I was involved in a project in Spain for the MOD researching ESP8266 and IOT security and more.  If you wish, follow my ramblings on the subject of control using these chips in THIS blog – and also on Twitter (@scargill), Facebook (esp8266wifi and IOT pages) and LinkedIn.

Nextion DisplayRegular readers will know that  the ESP8266 boards are still unbeatable if you take price into account and don’t need Bluetooth (ESP32). I’ve long-since scrapped various other radio designs (NRF24L01 etc.), blighted by short range or lack of network ability – and have gone “hell for leather” into using these boards.

Home ControlThe original plan involved an Arduino Mega as a “master controller” and Arduino “slaves running over an NRF24L01 mesh network. Here in this link is one of my first attempts at blogging on the subject – along with pictures of the original “Appcon” system from back in the ‘90s.

The original Arduino-based system worked well worked and indeed controlled heating and lighting for a couple of years at my home, but the controller went out of the window when the Raspberry Pi 2 came out which was dirt cheap but with more than enough power to control a house or ten. Now of course we have the RPI4  and other exciting boards such as the FriendlyArm NanoPi K1+ and others.

Hardwired to Ethernet (the main controller, not the ESPs), the system allows for a comprehensive wireless home control setup  and to answer any questions about ESP8266 reliability – with the code you’ll see in here,  I can say with a lot of experience, that the ESP8266 units given reliable power, are rock solid – stunning considering the price.

ESP-12The ESP8266 boards provide a very low-cost entry solution into the world of IOT making it possible to create in the simplest sense an Internet-controlled LED for under £2 (it could just as easily be a 2KW heater of course for a little more outlay) or more likely a WIFI-controlled LED STRIP with various sensors etc.

There are a number of variations on the ESP8266 boards, the first shot at this being the old ESP-01 – a simple board with power, a couple of IO lines and serial in and out. The thing is – they all use the same chip and that particular board (the ESP-01) is very I/O and FLASH limited – and for no good reason – the ESP-12 and variants for example have access to the A/D converter, several IO lines, have more FLASH memory and cost the same amount!

The only downside to the latter is 2mm spacing pins but for VERY little you can buy adaptors to 0.1” or better yet a Wemos C1 Mini or similar– i.e. a board that will take the ESP-12 or the ESP-12E (which is the same – but with a few extra essentially useless pins) – same price. There are also a number of ESP-12-based boards today which offer 0.1” spacing. For this reason I’ve long since given up on supporting the ESP-01 with it’s limited FLASH memory though as you’ll see in another blog entry,  with a steady hand and fine soldering iron it is trivial to replace the old 1MB Flash on the ESP-01 with a cheap 4MB Flash making it more compatible with ESP-12 etc. (well, you still have hardly any pins to use).

Oh, here’s a link to the various source files. Here are original Board files designed by Aidan Ruff (NO WE DON’T SELL BOARDS). No guarantees – not even any guarantee they won’t change or disappear if we find bugs. Since this article was started I’ve added I2c and a software serial port (optional) on GPIO4 and 5 to control Nextion serial displays directly as well as an Arduino NANO (or Pro) clone board which I’ve programmed up as a general purpose I/O expander for the ESP. Instructions here may not be fully up to date but always check the WORD document in the repository.

Also check elsewhere in the blog to see what we’ve done with the Itead Studio Sonoff boards and their plug-in-the-wall remote mains socket. All of this stuff works together as a whole or you can cherry-pick. Today I would suggest using Tasmota firmware on Sonoffs as the designer has put a lot of work into that.

I’ve added i2c to the ESP8266 software which as you’ll see in the picture at the start of this blog as made a big difference to the number of supported devices. What a roller-coaster this has been an a great way to learn all about i2c – I’ve improved the original Espressif offering a lot!  I’ve recently added version numbering to power up info and a powerful debug command and also, the power-up info indicates which GPIO is currently used for Web setup and which pin for the visual LED or RGB LED indicator.  At the time of writing the code is using  Espressif SDK version 2.0 as the later version is too-RAM-hungry for no real benefit.

tmpA4AFThe later PCB you see here was designed (by Aidan Ruff) for my award-winning (ok I had to get that in) Nextion Serial Terminal which in April 2016 grabbed second prize at the esp8266.com 1st Annual awards. The last update to this board includes the option to use an RGB LED as the status indicator – something I see as becoming the standard – once you have a selection of colours an intensities to indicate status, all of a sudden a normal LED looks boring.

Flashing ESP-GO

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 myour software does – it’s not the only software to do so. It may use GPIO2 or more likely 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.

Note: These blog entries will never all be up to date – too many of them – the WORD manual that comes with the ESP-GO source code on BitBucket is the most up to date available.

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 alongside Node-Red – 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, as you can just use the latest ROMS. 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 but no topic required).

SetupI worked with Richard Burton to get RBOOT working with ESP-GO – 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. Note the main rom is now called rom.bin not romx.bin – location is the same however at 0x2000.


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 ESP-GO main 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 468kbaud, 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.

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 ESP-GO 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), talk to various I2c devices and displays, talk to some SPI displays and WAY more .. 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 roms.scargill.net:




(for Espressif SDK 3.1 there’s a slight variation of that last file name)

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 – for example it is now standard to use GPIO0 as an input only with GPIO16 being used as an output. 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. Here is the project itself. https://bitbucket.org/scargill/esp-go/src/master/

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 GPIO0 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.

Update 11/07/2017: Code updated to version 2.1.0 to work with the new release of the Espressif SDK version 2.1.0 – this is no longer compatible with the ESP-01 or other boards with less than 4MB of FLASH.

Update 01/10/2017:  Fixed some SSD1306 sillies – added great new commands, updated manual.  Also, some new WEMOS boards seem to need a slightly different programming method. If boards persistently refuse to operate – even after programming – check out the mode- there is a QIO mode – and a DIO mode. The default is QIO – however some WEMOS boards need DIO – check out this entry.

Update November 2018: Version now supports more inputs – see manual… making better use of GPIO0

The Boards

For the reasons stated I’ll discuss here the ESP-12 (and variations, ESP-12F having a marginally better antenna) as that is my favourite sub-module – but the same code applies to other variations where pins allow. We have working software – and circuit boards to go with it. For reasons best known to my pal Aidan we called this original the Hackitt & Bodgitt board. We have a variation with an RGB LED as the status indicator on GPIO13.

If you are in any way unhappy using 240v AC mains power, you may want to give this a miss or fit one of those 12v to 5v down-converters so cheap and popular on EBay – I do this to power ESPs from a solar-charged deep-discharge battery in some cases. This version does NOT tie GPIO16 to reset (the saving in power on this board wasn’t really worth the bother – and note that GPIO16 is usable as an output). On new boards and in general we’re using GPIO16 as the default relay output – freeing up GPIO0 to be an input only (programming – and web-setup).

Front view

Here is the rear view. Note the MOSFETS on the back (this is looking straight through hence letter reversal)


Note that a nice feature of this board is that it can be programmed from a standard, cheap 5v FTDI.

So in terms of “Features”, the diagram at the start of this blog entry says a lot – but for clarity:

  • Mains-powered WIFI controller board (or use standard boards)
  • FTDI-compatibility
  • Accommodation for solid state or mechanical relay output
  • Temperature sensing using DS18B20
  • Temperature and pressure sensing using the BMP280
  • Temperature, pressure and humidity sensing via the BME280
  • Temperature and humidity using the DHT-22 or DHT-11
  • Our own board has signals brought out to edge connectors
  • De-bounced input with automatic de-bounce and messaging
  • Analog in for checking battery state etc., will handle up to 20v
  • Several Outputs expandable via I2c
  • RGB WS2812b output on most pins able to handle 300 or more serial LED STRIP
  • 3 outputs for high definition PWM – with MOSFETS to control LED STRIP
  • Talks WIFI and MQTT – ideal for being controlled by a Raspberry Pi or similar using, say, Node-Red
  • Flashing status (software supports both simple LED and serial RGB LED)  indication that the unit is functioning and has the correct time which it maintains internally in between updates*
  • Second (software) serial output to support Nextion displays (see the Nextion WIFI Touch Display project)
  • Software mono-stable out for use as a watchdog
  • Outputs can be timers for watering systems for example
  • OTA updating from internal or external website
  • I2C support for an ever-increasing range of devices
  • Hitachi LCD and Seeed OLED support
  • 16-channel 12-bit PWM support via I2c
  • 4-channel 16-bit ADC support via I2c
  • A new NANO-based peripheral via I2c with GPIO/PWM (inc fade), ANALOG in and SERIAL OUT
  • Support for various displays, SSD1306, SSD1351 and others
  • INA219 voltage/current sensor support
  • Deep sleep support < 7 hours at a time
  • GY30 luminance sensor board support
  • Simple GPIO10 support for some DIO-programmed boards
  • A new SPI-based scrolling terminal (which fits on the ESP8266)
  • and more to come…

* (The time comes from an MQTT broker, for example using a Raspberry Pi or similar running Node-Red – see below)

** I now use Node-Red on the Pi to do thermostatic control. Consider the thermostat code to be legacy.

And another board: we’ve also put together a board for the Nextion displays – but WELL suited as a general purpose board and it is detailed on the WIFI Nextion blog entry but I’ve included a picture here for reference. I can see a variation on this one being my main board eventually – just needs an add-on with a couple of relays and 3 MOSFETs to make it a perfect development board.  There is a cap on the reset line so that typically an FTDI is able to reset it automatically. Note: The current revision of the board has extra grounds and  4 way sensor connector (DS18B20, DHT22 etc.). Note that an even later version optionally uses an RGB LED for a status indicator – WAY better idea.

Nextion control board

The Controller

ESP-12We have chosen to commit to a communications protocol called MQTT as reliable code for this is freely available, MQTT “brokers” are also freely available and once you spend a little time on the subject it is both easy and the obvious way to control stuff in a network. Lookup “tuanpm mqtt” on Google.

As MQTT is so central to this, I’ll go into this in a little depth.  There are many ways you could have units talking to each other – a mesh network, a radio network, polling etc…over time I have come to see MQTT as the ideal tool for home control because it is simple, the tools are free and it WORKS.

Essentially an MQTT broker is a piece of software – a server if you like,  available online or (my preference) on the likes of a Raspberry Pi inside your network) which monitors incoming messages and sends messages out according to who they are for. Addresses are simply text. Messages are simply text. MQTT clients (software that receives MQTT messages for one unit and sends messages out to an MQTT broker) are available freely for the likes of Arduino, ESP8266 and in Node-Red. It really is all very simple once you get playing. So MQTT is an incredibly simple yet powerful format comprising a message “topic” and a message “payload” both in the form of simple text. Units can “subscribe” or listen for specific topics. A great way to play with this is to use an online free MQTT broker – and something like MQTT-SPY which is a free “client” which runs for example on a PC.

The ESP-12-based controller has a number of inputs and outputs which can be controlled equally well by MQTT commands or serial data – by the current software.

To talk to the unit wirelessly (WIFI) via the popular MQTT message protocol, a message can be sent to the topic “toesp” to send to all units in the network or to a specific unit by prefixing the topic with the unit ID, or example “kitchen_light/toesp”. The only difference between these two topics is that the former will go to all units yet never elicit a response from any unit, the latter will go to unit “kitchen_light” only and MAY, depending on the context, elicit a response from unit “kitchen_light” – unit ID is simple, programmable text.

My Node-Red ESPLOGON mode will respond to incoming MQTT topic “logon” from any ESP8266 sending it’s data in the payload (see esp-go software, the boards do this on powerup) ) and the node will send back time and date to that specific board. The node will also send, every 12 hours, such time/date/dusk/dawn info to ALL boards by sending the generic toesp topic and time/date/dusk/dawn info.

Finally hte node can be made to send:

topic: toesp

payload: {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. In the event that boards lose the WIFI for some time, they may reset their WIFI  – then reset the MQTT code. Reset is used only as a last resort and the software can handle up to two SSIDs in case you happen to have two access points. If one fails it will try the other.

Hence in theory they should be bullet-proof. In practice they are bullet-proof unless of course the power goes off. In the summer of 2016 in Spain I endured horrendous WIFI and power issues and the current code stood up to this and has done ever since – learned the hard way. That experience is also why I worked hard to ensure the OTA works so I can update the units remotely.

Each COMMAND or payload starts with an open brace and ends with a closing brace (my choice, kind of like JSON). In the case of MQTT, this information is stored in the message “payload”. For serial, there is no “topic” – just the message (payload) which you can fire into the serial port at 115k baud.

An example of a simple command might be to turn output 4 ON (out12 goes to pin GPIO12).


It is possible to send multiple commands at once by separating them with semicolons. i.e.


So to use serial – this is all that is required (newline delimiter) – for MQTT – the topic should be as referred to earlier and the payload should be in the format shown just above.

clip_image002[4]For more on MQTT go here. http://mqtt.org/

I chose to use a Raspberry Pi 3 (you could use 2 but 2 is ok) as my controller – and chose to use Node-Red as the controlling software when this was a project unknown to most  – turns out I picked a winner as Node-Red is now embedded in “Raspbian” on the Pi and is hence guaranteed a well-deserved and bright IOT future though I always do my own install using “the script”. It is also wonderful and really NOT hard to use. Want to play with Node-Red without even doing an install? https://fred.sensetecnic.com/ – enjoy.

The following document details the commands the ESP units will respond to – the actions which will occur along with any return serial message or MQTT message created as a result of the incoming command. But please – read the manual.

The Pins

Here we see a drawing of an ESP-12 board, please note there is a question mark over the positioning of GPIO-4 and GPIO-5 – on many units, these are reversed.

You are looking at the FRONT of the unit with the metal cover visible.


Note: Contrary to the diagram, in prototyping I’m using a 1k to pull GPIO15 down as it’s still a grey area (some say the board won’t program unless GPIO15 is held down) – it does NOT have to be fully grounded and as you’ll see in fact I added PWM output on it (March 26, 2015).


The ESP-12 units operate on 3v3 – NOT 5v. Extensive experience suggests a good 3v3 linear regulator fed from, say a 5v supply provides more reliable results than a 3v3 switched-mode supply – but that will vary with suppliers. I’ve recently been part of a project where we used WELL over 100 ESP-01 units all attached to one 20 amp switched mode power supply – they worked well… but I personally prefer per-unit linear regulation.

We done just that in all our own boards, using a cheap switched-mode mains to 5v supply (or DC/DC convertor for 12v use) with a 3v3 linear regulator. I suspect most queries about ESP reliability boil down to power supplies. I can honestly say – that having used countless ESP boards since they came out – I’ve not once come across a bad board!!

To talk to these units from any 5v system through serial, you should ensure that inputs to the ESP-12 never exceed 3v3 (resistive divider). Typically the serial output will work just fine fed into, say the serial input of a 5v Arduino – I have NEVER had any trouble with this at 115k baud. Simple resistive level conversion can easily be implemented so that a 5v FTDI will talk to the serial without issue. In practice I’ve yet to see a 5v FTDI destroy an ESP8266 but if you go without the divider, be it on your head.

NOTE: If you want to experiment with Deep sleep – you need a board without regulator or USB convertor – the latter in particular can consume up to 10ma !!! There is a command in ESP-go which disables GPIO16 so that you can attach it to RESET for deep-sleep support – during which the processor turns off – and only a simple real-time-clock survives, sufficient to use GPIO16 to force a reset and bring the board back to life.

Certain pins are special and in particular, grounding GPIO-0 on power-up is used to trigger “flash” programming of the chips and also used to put the units into access point mode for setup – so you should be aware of this. When designing outputs I base all of mine on Vcc. So for example when driving a LED…


Why do I do that? Well, when the unit powers up – GPIOs are all input – and if you preset them to “1” on power up you’ll not get any flashing lights as the units boot up.

Below describes SOME of the commands currently implemented.  We have both WEB-based and SERIAL setup, full MQTT integration and the development focuses on using NODE-RED – specifically but not exclusively on Raspberry Pi (I’ve installed Node-Red on many SBCs and consider it as standard as adding Apache and PHP.  We’re using the free and excellent Mosquito for the MQTT “broker” on the Pi (i.e all units connect to this “broker” by address and password” and the broker stores and releases on request stored messages – hence any unit can talk to any other unit as well as making requests of the Pi).

The WORD manual that comes on BitBucket with the code is way more comprehensive than this blog in terms of commands.

Command set

The commands below merely represent a subset – the WORD MANUAL is your up to date source of information.

Controlling and monitoring outputs

The potential outputs are GPIO0 (that’s the one on the board with the relay – future boards of ours will not use GPIO0), GPIO4, GPIO5, GPIO12[1]  GPIO13[2] and GPIO16. These are referred to as OUT0[3], OUT4, OUT5, OUT12 OUT13 and OUT16. You can also use GPIO2 as an output via a command – normally the latter is used with the likes of temperature sensors.

Typical outputs respond to the commands {outX:1} , {outX:0} etc where X is the GPIO number. If requesting the status of an output this form is used {outX?} where X may be 12 for example

There are 3 variations on this:

{out13} (GPIO13) by default should not be used as its main purpose is that of a LED “status” indicator (though you can override that) (see the relevant command).

{out12:Y} responds to the following for Y:

0 – off (if command “invert=1” then the state of that output is inverted (for positive-based relays) – see the invert command…

1 – on (see above)

2 – on from dusk till midnight (see above)

3 – on from dusk till dawn (see above)

4 – on from dawn till dusk (see above)

5 – under local thermostatic control – see relevant command (see above)

6 – timer for output. Another parameter determines ON time in minutes – i.e. {out0,6,100} sets the output on for 100 minutes.

There are a set of related commands for reading the state of outputs – these are {out12?} etc. Should unit “kitchen_light”  be asked for the state of out12 – the MQTT message sent back will be in the form

topic: kitchen_light/fromesp/out12

and the payload will contain the appropriate value.

Outputs can be inverted by the invert command by setting bits 0,1 and 2  etc., in the invert command. See the manual.


You can use a command to send PWM onto 4,5 and GPIO15 using the Espressif library which allows for up to around 95% duty cycle at very high resolution (14 bits) for the cheap 12v serial RGB LED STRIP though we have brought that down to 100 smoothly transitioning levels – but decent levels (i.e. non-linear – with more emphasis at the bottom end for smooth transition). Attached to a logic-level control MOSFET you can drive a 12v LED strip with this – initially off, use the command {pwm:X,Y,Z,I} where X,Y,Z are 0-99 for duty cycle and I is false if you want instant transition, or any value if you want a smooth transition.

For example if I =50 (50ms) then 0-99 would take 5 seconds. A lookup table is used to get a reasonably smooth fade.  Due to the Espressif library, you can get up to around 90% or so duty cycle at value 99 – but you really would not notice the extra on a light. Note also that the PWM even when off is still technically running – so if you run PWM with a board, don’t expect reliable SERIAL RGB LED operation as the PWM has a minor effect on really critical timing as needed for serial RGB LEDs.

Heating controls

In controlling heating, the unit will generally use the internally connectable (on GPIO2) temperature sensor DHT22 (which also handles humidity) or the Dallas DS18b20 or DS18b20p. These heating commands are deprecated as it is a lot easier to do heating controls in Node-Red.

It is possible right now to set the maximum temperature, the fall-back temperature, frost temperature and 2 on-off times per day locally. Of course using an external MQTT control the possibilities are endless.

Relevant commands are (X is general a value, degrees C or minute after midnight):








Time settings

The ESP units are able to keep time but clearly do not have a source of time – this can be provided to each unit separately or more sensibly to all units at once by Node-Red.

{time:X} standard Unix time value the number of seconds since January 1970

{dawn:X } number of minutes past midnight considered “dawn” or street lights off time

{dusk:X} number of minutes past midnight considered “dusk” or light up time

{When they power up, units attempt to log on. This is an ideal time to send them the time.


The internal analog to digital convertor in the ESP reads from 0 to 1.024 volts and outputs a signal accordingly. This can be read by the {adc?} command.


From the serial console, we can view various settings by using the command {debug}.

Temperature and Humidity

The relevant commands here are {temperature?} and {humidity?} They will send out, by return, for example in the case of unit 999 :

Topic: 999/fromesp/temperature

Data: X where X is in degrees C

Humidity follows the same format but is a percentage.


If we want the unit not to respond to a command but to pass everything on to the serial line to control, say an Arduino, use the EXT command followed by a string  – this can be used part way through a multi-line command if required.


The two outputs will be switched and the command {out0:1} will be send out of the serial port.

Of course, one COULD send these commands off to an Arduino – OR you could send them off to another ESP-12 with it’s WIFI disabled… the logic of that? It’s cheaper than an Arduino and faster!!

The above is left in for compatibility but now, the sensible way to expand the ESP is by using the new NANO peripheral, a cheap £1.50 Arduino Nano clone (there is an even cheaper PRO variation with no USB connection) for which I’ve published software.

You can develop in the C language for the ESP boards using the unofficial Eclipse development environment.


and you can learn more about my own work at https://tech.scargill.net


Setting up for WIFI

There are commands to set the unit ID (defaults to “999” note this is a string not a number), ssid, ssid2, pass, pass2, mqtt_host, mqtt_port, mqtt_user and mqtt_pass. In each case surround the argument with double-quotes.



You can also optionally set “desc” for a short description and “attribute” for any short message like “Dallas” to indicate what facilities the board has.

The above can also be set by WIFI.  Turn the device on and immediately short GPIO0 to ground AFTER power up for several seconds. This will put the unit in to web setup mode. Have your laptop, tablet or phone browser log into Hack-setup and go to to set everything up.

There are two SSID and passwords – the idea being that if the unit fails to get through to an access point it will try the second one, if that fails it will go back to trying the first one etc.


If for any reason we want to reset the device, the {reset} command will do that.


GPIO14 is an input. We can read the state with the {in14?} command.

It is also de-bounced and you can read (and simultaneously reset) the count using the in14_count? command. The inbounce:X command will let you set the bounce value in milliseconds.

When the state of the input changes (de-bounced) an MQTT message will be send out in the form of TOPIC: XXX/fromesp/in14 where XXX is the unit ID and  MESSAGE: 1 or 0

There is also a bounce value for in2 – i.e. {in2_count?}


One of the more useful features of the board is to be able to directly control an array of WS2812B LEDs. Right now, overall control is implemented including programmable fade-in and fade-out and a “rainbow” effect. However, buffer space is available to implement full individual control of up to 900 LEDs (warning use separate 5v supply for these – current can be up to 5amps for such a run). Note you cannot reliably run PWM and RGB LEDS at the same time. Initiating PWM starts a timer that disrupts RGB timing and a reboot is needed between these. That is one reason I developed the Nano peripheral which will talk to 6 PWM outputs (2 RGB PWM sets).

The RGB command takes the form of:

{rgb: port,red,green,blue,number,duration}

So if we want to go to bright red over 10 seconds and you’ve attached an array of 20 serial LEDs to the output GPI12, the command is:


And that will happen and we can do other things while it is fading in. The duration is a 32 bit number.

For amusement purposes we can also try {rainbow: port,number_of_leds,duration[,timer speed in ms]}

A neat toy: requires 60 RGB LEDs and can run on a port pin… a clock… {clock: port} if is 255, the clock is not running else runs on the relevant port.

If you want to just light up SOME LEDs in a strip – the command {rgbset: start_led, number, r, g, b} will let you set up various LEDS to various colours and the command {rgbgo: port,number_of_leds} will start the ball rolling. That number should not exceed 300 (not for any reason – I could have made it larger).

If you want to play with animation… {rgbstart: port,number_of_leds} will clear a command buffer so you can interactively add sequences {rgbadd: start_led,number_of_leds,r,g,b,milliseconds} and when you want it all to end, {rgbstop}. These commands can be sent via serial of MQTT.


When an ESP board powers up it sends a message “esplogin” and in the payload the ID with a slash after it.. so “999/”. This can be read to send the board, say, the time. See the next section.

I’ve implemented {sleep:x} where x=microseconds (32 bit number) hence 10000000 is 10 seconds. You need GPIO16 attached to reset and that just isn’t worth the saving on this particular board but it’s in there for completeness. This is deprecated.


BlynkOriginally we’d planned on using something like OpenHab for home control and of course anyone armed with the software can do just that. But for our purposes we like Node-Red as it is extremely flexible and becoming more powerful by the day. If you have a Raspberry Pi2 or better – you can run Node-Red on that but it also runs on Linux, PCs etc.

Node-Red allows one to “program” using visual boxes via a web interface– so an MQTT input box can respond to a particular topic, you can then do something with that and send a message back – or elsewhere – or maybe send a TWEET, or store some info in a database or send an email – honestly it is VERY simple to use and very powerful once you get to grips with it.

If you look at my earlier blogs I’ve written about graphing locally, using data pulled in by Node-Red and stored in a SQLITE database with ease )I avoid MySQL on the Pi to keep writes down somewhat). There are alternatives – I’ve written a “node” for Node-Red to let you simply send data to Grovestreams.com and others have written nodes for the likes of EmonCMS which has some very pretty dials.

Here’s an old screenshot of my Emoncms data and yes, the battery is really flat – due to this being solar charged out in Spain – and it is 6am in the morning – clearly the day wasn’t that sunny. Today I use Grafana locally for all graphing.

EmonCMS used at Bedrock in Spain

Node-Red has a timing module… when lets you trigger things at certain times. It also has available a suncalc which sets a flag when it is sunset. I’ve improved this significantly in a very popular node called BIGTIMER (see http://flows.nodered.org/ –  check out my bigtimer, esplogin and grove nodes– my contributions – for example – “npm install node-red-contrib-esplogin”) –  to produce an output directly suitable for the current design – to log the boards in and to tell them about the time, sunset and sunrise.

The esplogin node can send time updates when Node-Red powers up and on a regular basis (every 12 hours)to all boards – but also send to a specific board on request, and all boards will happily send that request when they power up – so typically a few seconds after power-up the boards know what time it is and what dusk and dawn times are.

Here’s what it looks like in action.. MQTT coming in from boards in the form of a json payload (purple), esplogin node in yellow doing the time/dusk/dawn updating and outputting the relevant MQTT back to the board (or in the case of time top-ups – all boards). The outputs from esplogin are, in order..

1. MQTT output

2. Output for a MYSQL database (legacy)

3. Output to a straight text logging file

4. Output to a SQLITE database


The login node now has an additional (5th) output which is the same as the first but in valid JSON format. The ONLY output you need is the first one,

All boards subscribe to “toesp” – and to a version of that with their name (ID) prefixed – so for example fred/toesp. That way I can talk to any board – or all of them.

When the board first powers up – it sends…  in the case of board “fred” which has description “my board”

Topic: esplogin

Payload: {“id”:”fred”,”desc”:”my board”,”attribute”:””}

Desc and attribute at not  important but can be shoved away in a database if you like.  So that sets off the esplogin node  putting info to its outputs – I only use the SQLITE output and that ends up in a database – that’s up to you but my setup is in the Raspberry Pi script referred to elsewhere.

So assuming the node gets that login – it will send a bunch of time info back to the ESP board in question at login – and will also do that every 12 hours to all boards. This stops the boards from watchdog resetting and ensures they always have the correct time without needing a real time clock etc.

See the time, dusk and dawn commands – the time in the ESPs can be used reliably though right now this isn’t necessary as the home control software on the Raspberry Pi is doing all the work.

How to get all the software the easy way

In order to use these boards effectively – you’ll need a Linux setup (a Raspberry Pi 2 or 3 for example) with MQTT, NODE-RED and preferably other stuff like PHP, SQLITE etc. Personally I’m not a Linux lover!!! And so I like things to be easy – so we made THE SCRIPT. You can grab a Raspberry Pi2 or 3 (B+?) and put everything on there. The script works with JESSIE or later version of Raspbian. Read more about the script here...

I use the Pi3 – after testing many boards this seemed a while ago to be the best for the job IMHO because of the very easy SD backup – and for reliability use a good SD such as Samsung EVO and to make life really easy. If you have a Pi3 all the better.

For controlling and monitoring – I am currently using the Nextion (serial) touch display boards for the wall and vary between using Blynk Android/IOS app for remote control, the node-red-dashboard and ImperiHome.  All work well depending on your requirements.

You’ll read about all of this stuff elsewhere in the blog – use the search facility – there is a LOT of info.


[1] GPIO5 (out5) can be manually over-ridden by the input and the “override” command.

[2] GPIO13 (out13) is generally used as an indicator to show that all is well. It activates on receipt of the correct time either serially or via MQTT and will flash briefly once every couple of seconds from there on. This activity can be disabled by a command. Increasingly we’re using a serial RGB LED on this pin to provide more comprehensive status info.

[3] We have generally scrapped using GPIO0 as an output and merely use it for programming and setup. GPIO16 makes a good relay output as it is not much use for other types of output.

Haptic feedback – when the board is being used in “Nextion” mode – we use GPIO12 as a beeper – simply fasten one of those cheap round haptic feedback devices to it and glue that to the back of the board. Also note that with limits (the line buffer is only 80 characters in length) you can concatenate commands so that for example if you want to turn GPIO12 on and get feedback as to the state at the same time {out12:1;out12?}  – note the two payloads are joined together by the semicolon. I also use this catenation with the Nano peripheral and RGB PWM.

The REAL source of info on commands is in the WORD manual with the project – that is where you go to keep fully up to date.



448 thoughts on “HC 2020 and ESP-GO

  1. Hi all
    Has anybody else had issues with a new Nextion 5″ basic display failing.

    I was using a 4.3″ display and decided to go for a 5″. I ordered one from ITead direct and it arrived just before Christmas.
    I ported over my project to the 5″ and all was well.
    I decided to move a few items about on the display to tidy it up a little but when I tried to upload the modified project to my display it failed!
    I was using the same SD card as before and i have tried many others, I’ve also tried a usb adapter and that failed too, no matter what baud rate I used. (Nearly 6 hours to upload it on the slowest setting).
    All my SD cards work with my original 4.3″ display as does my usb adapter.
    After some testing I have discovered that the display will now only accept a TFT file of less than 2400KB.
    As you can imagine I’m not a happy bunny as the display is only a couple of months old.

    I opened a support ticket on the Nextion support page and basically they are saying it’s down to my SD card or my usb adapter and closed the ticket.

      1. Hi Dave
        Thanks for the reply.
        I have tried everything power supply is good 3.31 volts at the card slot I assume that is correct.
        I have now tried 20 sd cards of various brands and capacity at the last count.
        I’ve used the supplied adapter for the power, and I still get the same result, if the tft file is less than 2400KB it will work anything bigger fails.

        Also note that ITead say they will fix the display if I pay for the return shipping and the cost of the repair. I guess they don’t honour any kind of warranty as its only two months old.
        I won’t be buying any more of their products that’s for certain!
        I’ll be sticking with 4D Systems displays from now on more expensive but like the saying goes you get what you pay for.

  2. Hi Pete.
    First of all a BIG thank you for all the hard work you everyone else involved have put in to make an amazing project.

    I am all up and running to a point but I’m now stuck

    I am using a Nexton display and I can send out MQTT messages from node red to set text using this message:- {to_nextion:”t0.txt=\\”Saturday\\””}.
    I can change pictures using this message:- {to_nextion:”pIcon.pic=33″},
    but for the life of me I cannot create a message to change the text on the fly using data from another message i.e DarkSky weather temperatures.

    Keep up the excellent work

    1. Happy to say I’m no longer stuck.
      I was going completely wrong(too much Arduino and
      Not enough JavaScript).

      Thanks again Pete for all your hard work.

  3. I like to get rid of the auto_temperature MQTT message. ( 4/30/2019, 4:47:08 PMnode: 36df16d0.f0001a
    ESP8266-01/fromesp/auto_temperature : msg.payload : string[1]
    Is there a command to stop all messages from this when there is no sensor connected?

  4. I just had some trouble with latest update of ESP-GO. After the update I had to cycle the power(easiest way to do) to get a connection from Node-RED. I have one node that is still on 1.9.33 and that one was OK because that node cannot be updated via OTA and it is in an awkward place to do it by serial. Please have a look at this phenomena yourself as this might heart you too.

    1. I can’t check OTA (which was working fine a week ago – I did lots of OTA) as I have a subnet issue in here, most of my boards have disappeared into 192.168.10.x (I use 192.168.14.x) – they work just fine via MQTT but can’t seem to get to the outside world. I also changed ROM location back to http://roms.scargill.net as I had reliability issues with the free storage they were on. Not sure which of these is my issue but I’m sure it’s just local. I’ll have Aidan test when he gets back from hols.

      1. Just did an otaupdate with new location,>…4. No problems after this. messsage for success and new version reported.
        Possibly an incidental mishap with the free server.

        1. LEO – after making sure you have a backup could you please try an OTA in which case you should have version compiled under SDK 3.1

          Let me know.

          1. My Experience with an update from to is not completely OK. It is spawning . This is just a fresh Mini D1 hanging on a microUSB cable. Cannot do otaupdate too. DNS problems.
            This is a log:

            (21:54:16.709) (COM10) {debug}
            (21:54:16.787) (COM10) Time and date: 21:54:16 25/03/2019
            (21:54:16.787) (COM10) Dusk: 19:01 Dawn: 06:33
            (21:54:16.787) (COM10) Up Time: 0:08:29
            (21:54:16.787) (COM10) IP: 192:168:0:48
            (21:54:16.787) (COM10) ID: ESP8266-WMP (ARPS_0053CABE)
            (21:54:16.787) (COM10) Desc: ESP8266-12F
            (21:54:16.787) (COM10) Flags:
            (21:54:16.787) (COM10) Comment: omment
            (21:54:16.787) (COM10) SSID: hoekbrwr Pass: ???
            (21:54:16.787) (COM10) SSID2: hoekbrwr_z24 (Active) Pass2: ???
            (21:54:16.787) (COM10) MQTT Host: Port: 1883 User: hoekbrwr
            (21:54:16.787) (COM10) OTA Host: roms.scargill.net Port: 1966080
            (21:54:16.787) (COM10) Code Version: Previous Version: 05
            (21:54:16.787) (COM10) SDK Version: 3.1.0-dev(8a853d3)
            (21:54:16.787) (COM10) RSSI: -71
            (21:54:16.787) (COM10) Out4: 0 (0 with invert)
            (21:54:16.787) (COM10) Out5: 0 (0 with invert)
            (21:54:16.787) (COM10) Out12: 1 (1 with invert)
            (21:54:16.787) (COM10) Out15: 0 (0 with invert)
            (21:54:16.787) (COM10) Out16: 1 (1 with invert)
            (21:54:16.787) (COM10) Sensor Type: Dallas 18B20(P)
            (21:54:16.787) (COM10) GPIO0 is an input
            (21:54:16.787) (COM10) Temperature Port: None
            (21:54:16.787) (COM10) GPIO13 available for general use: No
            (21:54:16.850) (COM10) GPIO2 is an input
            (21:54:16.850) (COM10) GPIO4 and 5 are outputs
            (21:54:16.850) (COM10) GPIO12 is output
            (21:54:16.850) (COM10) GPIO15 is output
            (21:54:16.850) (COM10) Sonoff setting: 0
            (21:54:16.850) (COM10) WiFi button: 0
            (21:54:16.850) (COM10) Invert settings: HEX( 0)
            (21:54:16.850) (COM10) Serial2 settings: 0
            (21:54:16.850) (COM10) RGB Indicator: 0
            (21:54:16.850) (COM10) Electrodragon: 0
            (21:54:16.850) (COM10) LED Clock on port: 109
            (21:54:16.850) (COM10) CPU frequency: 160Mhz
            (21:54:16.850) (COM10) Free Heap: 7688 bytes
            (21:54:16.850) (COM10) Used user area: 3340 bytes
            (21:54:16.850) (COM10) +
            (21:54:17.006) (COM10) +
            (21:54:17.209) (COM10) +
            (21:54:17.412) (COM10) +
            (21:54:17.600) (COM10) +
            (21:54:17.803) (COM10) +
            (21:54:18.006) (COM10) +
            (21:54:18.209) (COM10) +
            (21:54:18.412) (COM10) +
            (21:54:18.490) (COM10) {otaupdate}
            (21:54:18.600) (COM10) Attempting OTA update
            (21:54:18.600) (COM10) ESP8266-WMP/fromesp/otaupdate=Attempting OTA
            (21:54:18.600) (COM10) +
            (21:54:18.803) (COM10) +
            (21:54:19.006) (COM10) +
            (21:54:19.209) (COM10) +
            (21:54:19.412) (COM10) +
            (21:54:24.209) (COM10) +
            (21:54:24.412) (COM10) +
            (21:54:24.600) (COM10) +
            (21:54:24.803) (COM10) +
            (21:54:25.006) (COM10) Connection error: Not connected.
            (21:54:25.006) (COM10) OTA Update failed
            (21:54:25.006) (COM10) +
            (21:54:25.209) (COM10) +

            This is it for today!

  5. I would fully endorse Antonio’s comments regarding Home Assistant, it really is very good and extremely flexible. I have also recently added ESPHome to my mix of node-RED, Grafana, Tasmoadmin, etc. I also have a secure link via 1 forwarded port to my mobile devices.
    The things I particularly like are the ease of doing backups via ‘snapshots’ locally, these can easily be copied or backed up to an external device. Updating things like node_RED is a breeze as the addons change colour when an update is available, so simple.
    moving from one system to another is equally easy. I moved my HA set up from a dual boot PC running Ubuntu 18.04 to an Intel NUC running Ubuntu 18.04.1 with ease and I am far from a Linux expert and I have had more than a little help from Antonio along the way!
    There is no reason why you couldn’t run Peter’s excellent system too and have them communicate via MQTT. I don’t mean to imply both systems would be on the same PC or Raspi but more likely on two devices. Awesome potential!

    1. backups: you can even have them automatically generated AND uploaded on dropbox or gdrive, there are addons for that 🙂

      tasmoadmin: it stresses tasmota devices too much and they tend to restart or have problems… don’t leave it there opened all time, or try the alternative, TDM, Tasmota Device Manager: https://github.com/jziolkowski/tdm

      install hassio: just install an ubuntu 18.04 on whatever device, even each SBC that has Armbian support, then run this script by Frenck, one of the major HA addon developers, and you’re good to go: https://gist.github.com/frenck/32b4f74919ca6b95b30c66f85976ec58

      the point is: it’s not an alternative to nodered, no religion wars here… they can coexist beautifully, there’s excellent support via nodered nodes to recall home assistant services, so you can do all or part of your logic on nodered as always, or now with esphome (or tasmota rules) inside small devices themselves, so if main controllers are down you’re not blocked completely 🙂

  6. Hi Pete!

    Probably a dumb question but I am adding a couple of ILI 9340 displays to esp-go boards I have built to play with and learn how I might use them for temperature displays.

    I have got the boards working in a basic form but now I am turning my attention to sending data to them in a more sophisticated form via Node-Red (still learning) to get similar good looking displays to those you have achived.

    You give an example flow on page 32 of the manual, Pergola ILI Display which I have tried unsuccesfuly to emulate with mixed results. Do you have that flow written up somwhere on the blog that I could learn from. Tried searching but can’t find anything.

  7. Hi Pete!
    I managed to get it working in SDK version 2.0.0 but not in SDK version 2.1.0…
    Any ideas why?
    The error message:
    … xtensa-lx106-elf/bin/ld.exe: build/app_0.out section `.text’ will not fit in region `iram1_0_seg’

  8. Hi Pete from a sunny Morpeth. I’m a beginner at most of this stuff but working on it as a winter project. I’ve been through the Script and ESP Go articles and waded through the comments a couple of times and managed to get a nodemcu and wemos mini up and running and starting to look at Node Red. I’m wanting to publish a couple of temps and humidity to Thingspeak, and there’s a NR node for that which works on a W10 node red installation but I can’t get it working on the Pi 2 as the node red Manage Palette fails to install the node. Any advice? Thanks.

    1. Hi Pete,
      I red your older blog from 2015 about Domoticz. Have you used it since?
      I became a homeowner recently and in the process of remodeling the house, will be automating everything I can think of. Out of the box “smart” switches are pretty expensive and no guarantee they will be supported/updated 3-5 years from now. I decided to go for complete diy. As of right now, I replaced old mechanical timer with nodemcu esp-12e and 6channel relay, created a flow in Node-RED with Big-Timers controlling various relays at different times. Works great.
      But as I’m thinking forward, I would like to have better dashboard, integrate security cameras (trigger something on motion), irrigation controller, mobile presence, geo location, etc. I came to the conclusion that Node-RED is not the right tool for the job. I can build a house but I can’t write a single line of code.
      If you don’t know what you’re doing loading sketches on esp is not an easy task and time consuming, that’s why I tried espeasy and was surprised how easy it is to get going, while digging through esp settings I was introduced to controllers. Started with OpenHAB, wasted 6 hours, didn’t get anywhere. Next was Domoticz. So far so good.
      Managed to add API for my existing Honeywell thermostats (not ready to diy mission critical devices). Moved my relays to Domoticz, but can’t find anything similar to Big-Timer, except Blockly. I might as well keep Node-RED flow to control relays and update Domoticz over MQTT. Even got a Telegram bot setup for push notifications to smart phone.
      Could you advise on how to move forward?
      Is there other controllers? or maybe completely different approaches?
      Any Dos and Don’ts?
      If some articles come to mind that will answer my questions or some of them. Please share

      1. Not used Domoticz recently – happy with Node-Red Dashboard for my thermostat – Blynk for just about everything else – all based on Node-Red. Also the Amazon node for Node-Red lets me talk to everything.

      2. Suggest trying Home Assistant… Support for tons of hardware, you can integrate with native devices or with hacked ones via MQTT (ESP-GO, Tasmota, Espurna, Espeasy), you can write automations in YAML (not a real programming language…) or use the excellent nodes for nodered and use HA as frontend and NR for automation, or mix both, as you like… Very popular these days is the EspHome firmware, which allows to write gpio manipulations in YAML itself, and uses HA api instead (or in addition to) mqtt, for easier integration in HA…

        I use HASS.IO as HA setup, and use nodered via its addons store, everything interconnected out of the box, easy to manage backup system via snapshots

        1. Thank you for responding guys
          I have no choice but to try Home Assistant as i just discovered a major flaw in domoticz, by default it expects values from sensors and APIs in Celsius and if i change settings to Fahrenheit it doesnt let values through but converts it with (value*9/5+32).
          Not intended for US market at all.

          However, since i already have domoticz setup and working for notifications to Telegram and i have no clue how to do it in Node-RED or else where. I’ll get one more RPi, install HA, start adding new devices or cominicate with existing thru mqtt until i get more comfortable.
          If i understood correctly, i can have multiple “controllers” subscribed to any amount of sensors/devices and let them do what they do best.

  9. Pete,
    I’ve had a Sonoff socket (with esp-go) running a heater outside controlled by node red and a temperature monitor for a while now and I noticed it had stopped working a couple of days ago, completely dead! I opened it up and checked all the voltages and all was OK so I re-flashed it wit the latest ROMS of your site is reported from a {ver?}.

    I noticed that the button on the socket no longer controls the relay although I do get a “trigger” MQTT message, has it fallen off the table on the latest update?

      1. Ok, I’ve put in the garage so can’t test it immediately and I don’t really need it as the control is via MQTT but I’ll have another check when I can.

  10. Hello
    first time posting,
    ESP-GO, well this has been a journey, learnt so much but am still nowhere,
    attempting to serial flash an ESP, tried from raspberry pi as no FTDI, got so far then failing, tried from windows with recently acquired FTDI, again got so far then looping on boot, all power related problems, lessons learnt.
    Next had a wemos D1 clone, flashed it, just couldn’t get it into AP mode to set the config, what am I doing wrong, Ali had just sent me some naked ESP’s, was looking them over, face palm moment, surely not, doh the pin out on the clone was incorrectly marked.

    Thanks for the experience and knowledge, I’m sure I’ll be back with questions, mqtt and node-red challenges next….

  11. I imagine that it may be more down to the quality of the power supply used – although a PCB design with very thin power tracks would be more vulnerable.

    I do tend to make power tracks a lot thicker than signal tracks, plus I go very heavy on the grounding

    1. I guess you use another supply regulator than AMS1117 because these are very bad regulators! Of course, it is a combination of a number of factors! Did you really check the supply voltage at the ESP8266? In the video of Andreas it has been shown that there are substantial voltage drops that can brownout the ESP.

  12. Having real problems with ESP-Go, managed after a few tries (ie blanking and re-flashing my ESP) got it to connect to MQTT without constant errors but not it will not stay connected to my WiFi (the ap is less than 30cms away) Message i get is No heartbeat – switching to AP: {my secondary SSID} then that times out and restarts. I don’t seem to be able to find any documentation on what should be happening so really struggling at the moment.

    1. On all of my recent PCB designs, I’ve upped the value of the decoupling capacitor right next to the ESP8266 module. I’ve found that 47uF works really well. Otherwise, you can get some odd crashes once the wifi starts up as it takes quite a bit of current – I’ve measured pulses of up to 300mA

    2. Chris, do you have the node -red setup with at the very least Pete’s login to be able to communicate with the boards? The ESPs need to get a reply back from the MQTT server* or won’t stay alive for long.

      Have a mqtt listener node subscribe to “esplogon” and connect it to the login node, and that in turn to a mqtt publisher sending to “toesp”.

      *also needs to be setup, both server and the ESPs, which need to point to the server correctly, auth and all.

  13. Tasmota had to split the software into modules.
    I simply dont support OTA on the Sonoffs as they only have 1 meg of flash snd I’m using more than half of it.
    ESP-GO is oriented to general ESP-12 boards and hence has many features that Tasmota and others do not… a reminder..

    OTA on 4MB boards
    RGB with optional fading – for up to 300 RGB LEDS
    RGB serial including 60-LED clock software and with optional fading
    White control in Kelvin
    pushbutton debounced inputs
    Support for various OLED displays
    Support for various LCD displays
    VT100 Terminal mode
    Deep sleep mode
    Support for various temperature/humidity/pressure/light devices
    Frequency doubling to 160Mhz
    Support for Sonoff inc button
    Support for Electrodragon
    Support for IA219
    Static or dynamic addressing
    Support for “Nano peripheral”
    Support for parallel and serial 7-segment displays (Hitachi)
    RGB sequencing
    Nextion support

  14. Hi
    I’ve just upgraded my sonoffs to 2.7.01 and cannot get the pushbutton (GPIO0) to toggle the relay. I’ve tried all sorts of variations. Am I missing something? If this functionality is gone where can I find the older ROMS.

    1. I’m not convinced that I ever did implement that on the sonoffs. You don’t say what you have upgraded from?


      1. Correct that, I did implement it and the new version has indeed screwed it up by not checking for sonoff before using gpio0. Fixing that now. will have the fix

  15. If anyone has too much spare time and wants to help… I just upgraded ESP-GO again to 2.7.0 – new GPIO15 abilities. I have almost all routines in FLASH, but keep running near the limit for .text space (not variables, functions….) – on SDK 2.1 – 2.2 and now 3.0 say not enough room, apparently I should be able to upgrade and get the room back but I’m rubbish at makefiles and linkers.. using the unofficial Cherts setup on Windows and would really appreciate if someone could step in here…

    From the Espressif forum:

    Did you read and implemented all of the required changes in your code to be using V3 at all? That would be the starting point.
    Only after that, try to find out what functions end in IRAM and try to cut down on them. If you run the linker with a loadmap, you can spot which ones end up in IRAM and which ones in IROM.
    V3 needs specific changes in the loader script, otherwise many functions that are not marked as “IRAM” end up there.
    I did this. Also you need to use “-ffunction-sections -fdata-sections” as compiler options. And don’t try to use -O2 or -O3, it will generate larger code but it’s not faster. Use -Os and only that. Contrary to what the manual says, you can’t use -O2 or -O3 together with -Os, the last used option will always win. So only use -Os.
    diff –git a/loadscript-template b/loadscript-template
    index 74f8a59..c91dbd0 100644
    — a/loadscript-template
    +++ b/loadscript-template
    @@ -151,6 +151,28 @@ SECTIONS
    } >dram0_0_seg :dram0_0_bss_phdr
    /* __stack = 0x3ffc8000; */

    + .irom0.text : ALIGN(4)
    + {
    + _irom0_text_start = ABSOLUTE(.);
    + *libmbedtls.a:(.literal.* .text.*)
    + *libat.a:(.literal.* .text.*)
    + *libcrypto.a:(.literal.* .text.*)
    + *libespnow.a:(.literal.* .text.*)
    + *libjson.a:(.literal.* .text.*)
    + *liblwip.a:(.literal.* .text.*)
    + *libmesh.a:(.literal.* .text.*)
    + *libnet80211.a:(.literal.* .text.*)
    + *libsmartconfig.a:(.literal.* .text.*)
    + *libssl.a:(.literal.* .text.*)
    + *libupgrade.a:(.literal.* .text.*)
    + *libwpa.a:(.literal.* .text.*)
    + *libwpa2.a:(.literal.* .text.*)
    + *libwps.a:(.literal.* .text.*)
    + *libm.a:(.literal .text .literal.* .text.*)
    + *(.irom0.literal .irom.literal .irom.text.literal .irom0.text .irom.text .flash.rodata)
    + _irom0_text_end = ABSOLUTE(.);
    + } >irom0_0_seg :irom0_0_phdr
    .text : ALIGN(4)
    _stext = .;
    @@ -198,14 +220,6 @@ SECTIONS
    _lit4_end = ABSOLUTE(.);
    } >iram1_0_seg :iram1_0_phdr

    – .irom0.text : ALIGN(4)
    – {
    – _irom0_text_start = ABSOLUTE(.);
    – *libmbedtls.a:(.literal .text .literal.* .text.*)
    – *(.irom0.literal .irom.literal .irom.text.literal .irom0.text .irom.text .flash.rodata)
    – _irom0_text_end = ABSOLUTE(.);
    – } >irom0_0_seg :irom0_0_phdr

    /* get ROM code address */

    And for the linker do not forget -Wl,-gc-sections

    Yes of course, I totally forget to mention, that’s actually the one I meant, “-ffunction-sections -fdata-sections” is only slightly relevant. Thanks for mentioning.

    BTW Espressif made this change to actually get more free IRAM space, but if you don’t follow the required steps, you’ll end up with a lot less 😉

    @ts did you already implement a partition table and callback?

    Then I guess you’ll have to rely on the one that maintains your environment to make it suitable for SDK V3.

    I’m sure all of the above makes sense to Linux seasoned techies but was as clear as mud to me. I use R Burton’s rboot – at 0000 and everything else (all pure C code, no Arduino, plus SDK nonos, starts at 0x2000h). Currently I use maybe 700k and using RBOOT can OTA into the second meg… don’t use 3rd or 4th MB of ESP12. I can keep expanding this massive effort but eventually the .text limit (only goes to 0x8000) will likely hit me.

    I understand my code really well but that’s where it ends… R Burton helped set up OTA, user data near top of 1st (and I guess 2nd) meg, just below the ESPRESSIF data.

  16. Just like the editor really. I use it for JavaScript, php etc, and it even handles node-red. The Platformio ide handles Arduino and related ESP projects. I also like the way it integrates with git.
    It can all be done with eclipse, so this is not an issue as such – more of an interest. I shall plug away at it, but thought someone might be able to help shortcut it. If I am successful – I’ll probably write it up.

  17. Hi Pete,
    Glad you’re back in full swing – good to have you back.
    I am using previous versions of the ESP-GO software built on Eclipse following the excellent instructions of Makerjay.
    I recently tried VSCode (which is used to build the Sonoff/Tasmota software) and have tried to port your software to it.
    Basically I have had no success so far, so was wondering if one of your readers has had success. Fundamentally my tired old brain had trouble enough with Makefiles, let alone setting up anything else — so question is:

    Has anyone built the ESP-GO code in the VSCode environment?? If so can they pass on some tips.

    Thanks for a great blog Pete!


  18. I’ve just setup my Sonoff 433 RF bridge with Tasmota and playing with node red to monitor the side gate and shed door using a couple of these 433MHz door contact transmitters https://www.banggood.com/Digoo-DG-HOSA-433MHz-Window-Door-Sensor-PIR-Detector-Wireless-Remote-Controller-External-Siren-p-1163239.html?rmmds=myorder&cur_warehouse=CN
    and realised that they make great little controllers because of their small size and the little button on the front which I assume is the setup button when used with the security system, anyway thought it was worth a share.

Comments are closed.