Category Archives: ESP8266

ESP8266 Meets Arduino via I2C

If you’ve been reading the blog regularly you’ll know I added I2c to the ESP8266 code some time ago – that is, the ability to send an I2c message either to read or write – originally intended and still working with cheap I/O expanders – so you lose 2 wires (GPIO4 and 5) and gain another 6 or 14 for one or two I/O expander boards.

Well, I’ve updated it as of tonight.

Of course, ESP12 talking to Arduino is nothing new but given what we’ve built up here with the ESP boards and Node-Red I thought it might be useful to have the option to expand further.

What a few hours ago seems like something in the distance – well, it is done – and it works – and it has LOTS of potential. Read on.

ESP8266 and Arduino and I2c

What you see above (the FTDI is just stuck into the ESP8266 board for power) is a 1284 Aiduino boards flashing lights  - controlled by MQTT – that is, the ESP12 board on the RIGHT is taking in the MQTT and sending commands via I2c to the 1284-based board and to the little red expander in the middle (on the same 2 pins).

Hence, I’ve spent the day working on the I2c code adding the ability to send multiple byte parameters and to receive a byte (I could have made it receive multiple bytes but for simple control a byte will do).

ATMEGA1284The next step was to set up an Arduino – or in my case specifically an ATMEGA1284 chip to talk to the ESP – hence giving us the ability to control Arduino ports via Node-Red.  Now as yet another blog entry here will testify, you can of course connect (now that the node is fixed) an Arduino directly to the Raspberry Pi in charge – but puts too many physical constraints up.  I had no intention of developing Firmata on the ESP – and so a simple i2c protocol was develop and SO much more can be done.

Right now I have an ESP8266  on the bench with a 2-wire I2c connection to an I/O expander – and an Arduino-type board using the 1284. I can talk to both from the ESP (and hence from my Arduino wirelessly via MQTT) and can control the following:

  • Any pin as an output (and PWM outputs where appropriate
  • Any pin as an input (and analog inputs where appropriate)

So first things first – I used  the Atmega1284 simply as I have loads of them – both DIP40 and surface mount in our little AIDUINO boards. The 1284 has twice the RAM of a 2560 and is easy to use. However this would work equally well in a normal Arduino or in the massive 2560 boards.. the only difference being which two pins are used for i2c. The red chart above, shamelessly stolen from ManicBug’s website shows the pins (in parentheses the numbering system I use).

So in the ESP8266 (grab the latest ROMS or SOURCE) I have a simple method of communication which can be used by MQTT or serial. The format is similar to that used elsewhere in the home control system.

i2c:  device, return, param1, param2, param3, param4, param5.

Not all parameters are needed.

So – to talk to an i2c expander sitting as device 39, connected to pins 4 and 5 of the ESP board…


device 39, no return value, send out 3 (which lights up the bottom 2 LEDS.


This returns the value in the port expander.  this is covered in two previous blogs.

So what has changed is that the code can now send out multiple parameters – and optionally receive information back.


The above sends out to device 8, expecting nothing back, type 1 means set a port bit, bit 20 in this case (see red table above) – to 1.


Above – device 8, 1 means return a byte, type 4 means read analog value and port number is 30 – the instruction will return the value of the analog input.

1 is digital out, 2 is digital in, 3 is PWM out, 4 is analog in – you must use appropriate ports – not all are able to handle analog in or PWM out… and you don’t have to worry about port direction setting – this is checked before any operation and set.

There is SO much more potential here but only so many hours.  I will likely make the settings for outputs non-volatile at some point – and add in all manner of device monitoring and probably also make use of the multiple serial ports on these devices.

For now that’s not bad for a Sunday session.  If you’re seriously interested I’ll make the Arduino code available but right now it is highly volatile – but it works!!


Sunday Morning Experimenting

I figured after a couple of horrendous days figuring out what was wrong with my ROMS, it was time for a morning’s relaxing.  Some time ago I added I2c to the Home Control software but never actually got around to doing anything with it.  The i2c parallel expansion modules I got from Ebay have their own pull-up resistors on them… could I get away with hooking 2 boards up without having to dismantle surface-mount pull-ups on on?

test ledsSo first things first I wired up some test LEDs comprising a some AQUA LEDs I had lying around and 120r resistors. I looked all over for pre-made leads with female 0.1” connectors on them but as usual ended up making up my own. If anyone knows of a good cheap source of these – do let us know in here.

Next stop I needed a test board and the obvious one to use was one of the samples I got from Bob Elmour.

A few extra ground, 3v3 and 5v lines (0.1” connector strip) along with GPIO4 and GPIO5 brought out and I was in business. Ok, not the prettiest layout but good enough for testing.

And… yes, I’m not sure I’d want to go beyond two without removing resistors – but they work. With one DIP switch set to ON-ON-ON and the other to ON-ON-OFF I found I could easily use i2c to turn on and off LEDS on both boards at addresses 39 and 38 respectively.

ESP8266 board

It is worth noting that the output DRIVE capability of the little red boards is not that good (as the outputs are also used as inputs with pull-ups) and so to get a decent output I fastened the LED + leads to +3v3 and used the expander boards to SINK current (which means the output logic is inverted).

Using the come control software, lighting up those 4 LEDS is simple.



(The zero is a recent addition and simply says there is nothing being returned. See future blogs for more extensive use involving multiple parameters and an optional return value).

So for the loss of 2 wires, you get 16 outputs using I2c and at a cost for boards of around a fiver. Not entirely sure how well that compares to sticking an ATMEGA24560 onto the ESP and doing some custom software to let you control the outputs (I have thought about this)… but it is certainly one easy way to get more inputs and outputs.


A good day

Today has been a good day. After a great Saturday down at Castril (waterfalls etc – fantastic weather) Aidan and I sat down with some wine to test his new movement sensor/smoke detector board. As is often the case the first iteration has some issues but I’m sure it won’t be long before I do a write-up  in here. We have a 3d printed box and it is now sitting on my wall. In the process we found some bugs in the home control 2016 code – to do with reading the state of inputs and sending relevant MQTT messages – all sorted now so that I have Node-Red waiting for input from the movement sensor and turning lights on, on timers. All the code and the OTA (which works wonderfully) is now updated. See the relevant blog items.

In the process I’ve realised (and you’ll note I’ve recently been upgrading even ESP-01s to 4Mbytes of FLASH) that OTA is a FAR better way than flashing boards – as you don’t even have to dismantle installations – or worry about turning off the serial terminal before programming boards  - just issue an OTA command and you’re off.  We’ve been making ourselves a little Python code to copy the OTA files across to the web server so that as soon as the code is updated in ECLIPSE – a single button-press makes the ROMS available to others.  Lots of updates tonight and the manual is being kept updated also.

CHIP[1]Meanwhile in the process of doing this I had a need to send information from one page to another in Node-Red and the new LINK modes work just superbly for that (you need to update Node-Red if it is more than a few weeks old). I’ve now updated several Node-Red installations without a hitch.

Meanwhile as Aidan was coming over from the UK he’s brought me some supplies here in Spain – a super new keyboard – a “Tecknet” which glows blue, red or purple as needed and which has sprung keys and laser engraving. It’s like a breath of fresh air.

I’m expecting BananaPi M2 as well as FriendlyArm new boards in the near future… right now I still have a problem with the FriendlyArm NanoPC T3 – it’s a wonderful board but for the life of me I can’t get the Android installation to work other than in the 8GB image – which leaves almost nothing to work with. I plan to put a 32GB USB drive in there and want a full 32GB installation.

ChipAidan has also brought me a CHIP board (seen above) – and I’ll be looking at that in a future article – it is really neat, quite small and the setup is ridiculously simple. Ok it isn’t the fastest processor in the world but  we’ve had Mosquitto running on it and in the process I even learned how to use the venerable VI editor! Like many boards it claims to show itself up by name on the network – and like most of them this just does NOT happen on Windows 10 at least – but again like most, the line I added to the install script:

sudo apt-get install samba samba-common samba-common-bin winbind

works every time and now I can just access it in VNC as chip:1

Chip has some smile-producing features one of which is a battery connector – so to test – just plug in a cheap battery using a standard connector. Now imagine you are communicating with it via VNC – and the power to the unit fails – makes no difference at all, just keeps on ticking with its wireless connection. Of course you can do this with loads of board but most of them need a complete battery backup system which we’ve discussed successfully in this blog recently – in the case of the Chip – nothing more than a battery is required.

No issues with the updated ESP8266s with the new ROMS discussed a couple of days ago – they work perfectly as you might hope. I’ve run out of the FLASH chips now now and sent off for some more to China (2-3 weeks). I’ve been thinking about how to use the extra 2MB RAM – I looked a SPIFFS but it is WAY too complicated and at least the original code would fail for me as I’m running short of IRAM so I’m thinking how I may create a simple system.  You have to write in 4K blocks as I understand – which could prove an issue as I’m not sure I have 4K of RAM left to form a write-buffer. More on that next week as I start experimenting.


Home Control Updates

For those following the home control project including the ROMS for ESP8266, I’ve made several changes in the last few days including a new uptime command {uptime?} returning a string of the time since last reset/power-cycle. Also added that to the debug output – also fixed a couple of minor RGB issues. Source code now works with very latest SDK from Espressif

If none of this means anything to you see:


ESP8266 and Nextion Updates

This one will be on-going.. so the plan was to write a blog about the latest version of our little ESP-12 board and it working with the new Nextion display board.

But as happens in life from time to time, it all went wrong at the Nextion end. However…

BoardOur board: We have updated our little ESP8266 board. Minor to be sure – we’ve added the ability to use an RGB serial LED as the indicator and some other minor items like fixing a missing track on the RGB LED. This board works – no cut tracks, no extra wires  - it is absolutely bang-on. In the image to the right you can see the RGB LED bottom left (LED2), extra grounds (bottom) compared to the last model but one – and of course the DHT22 connector introduced in the last revision.

The adc divider is now on the underside of the board and the “adc-div” is around 4k7 for 20v peak – I use it to measure battery voltage. for software see the home control 2016 project in this blog.

The files for this board are here including Eagle and images for viewing.

The Nextion: I received the latest board from iTead, the NX4024K032_11 which is supposed to be faster and better than the old model Nextions (which, for those reading this freshly – are touch-sensitive serial display boards suitable for a wide range of projects) and I updated the Nextion editor to the latest version.

I had a little difficulty at first because their downloadable editor now insists you tell it the exact model of board – I’d not seen that before. So off I went and made a display with a single button which would send back “Hello” when pressed.

Took me a couple of attempts as I had the serial wiring the wrong way around – anyway, eventually I did the update.  It did not seem to be returning quite what I’d imagined it would so I went in to make changes in the editor. This time around, I could not blow the update. The editor kept coming back saying “Forced interrupt!” no matter what I did. As it happens I have a virgin older design of board – the NX3224T024 – I did the same thing -  and lo – THAT is now dead. I’ve written to the designers and am awaiting an answer, nothing in the last couple of days and I’ve seen others with this problem. Right now the only way to get around it is to put the compiled file from the Nextion editor into an SD card, insert that into the Nextion board and apply power at which point it copies the image across. A LOT faster than using serial but then a lot more messy if you are making frequent changes. On the other hand it means I don’t have to keep disconnecting the board from our test board.

What can I say, everything works as it should do – our board can send commands to the Nextion display and accept input back. For test conditions I set our board to serial2 at 56k {set_serial:2} and created a blank template on the Nextion with 2 buttons – one of which has the pressed command get “nodered~up” and the other get “nodered~down”.  When our board sees incoming with a tilde – it splits the string into two – i.e.  topic and payload – and hence sends a message up or down to the topic nodered via MQTT - easily picked up in Node-Red by the MQTT node.

So no surprises – all works – I did spot a minor error in my manual for the “to_nextion” command – now fixed. So all tested – both old and new Nextion boards, able to both send and receive info to the little blue board.



After a slight hiccup with the new board (LED track missing) here’s the new board  – link for PCB here – as you can see, Aidan has made several improvements – smaller buttons, connector for DHT22 etc, markings for I2c (right now I only have support for the 8-output expander discussed elsewhere but more will follow as time permits) and general tidy up. Both the original LED and the new RGB LED are included – personally I find coloured lights for status a lot more useful than a flashing light – but of course they can use more power. As well as the LCD project this board has become a general purpose ESP-12 board and I now would not use any other.  We’ve not wasted cost putting USB on it because FTDIs are cheap and that reduces the end cost of the board.   The link above has all the files – please note we’ve NOT had delivery of these, the previous version was almost the same and works but for a track on the WS2812b.. so it is highly likely this board will be just fine – will be a couple of weeks or so before we know (delivery from China) and another week before I get my hands on one (Aidan is in the UK, I’m in Spain). The I2C markings are just to make it easier to remember which pins you use – we didn’t have enough room for yet another 4-way connector. If you are looking in for the first time – see the Nextion WIFI Display blog and the Home Control 2016 blog.

I’ll be trying this out on a brand new Nextion board I just received (faster processor I think – not tested yet – will blog when I do) along with some other stuff from Itead

Enjoy. For my next trick – a new board from SEEED…. review coming up later.




Remote checking Home Control Units

Those of you who are aware of the Home Control project (Home Control 2016) will know that the software/hardware combination of a Raspberry Pi (running Jessie, Node-Red, SQLite and Mosquitto) and ESP12 (running the software described in the Home Control project) is proving very reliable – but there are occasions when you may wish to be absolutely sure that units are actually doing something.  One way to do that is simply to put timeouts on every response you expect… but that makes for complicated coding. A simpler way is to regularly ask each unit for the status of one of the outputs. It doesn’t matter what the response is, as long as there is a response.

As it happens I’m having an issue right now – the heating controller part of my system back home in the UK is working perfectly except of an on-going issue with Plusnet broadband. They are denying it is their fault but the broadband fails perhaps once a day, maybe more, maybe once every two days but eventually it will fail. Most of the time the TP-Link TD-9980 router reconnects within a minute or so – but for reasons I don’t yet understand, occasionally it just will not reconnect. The solution to that was simple and two-fold, a standard timer which turns the router off for a minute in the early hours every day. That’s the “belt and braces” approach. In addition, the Raspberry Pi is polling Google every few minutes. If it fails totally over a 15 minute period to contact Google, an ESP8266 unit will reboot the router.

All of this worked perfectly for several days and then… the heating relay ESP8266 refused to log back in after one of these “cuts”. I can only put it down to being right on the edge of signal. The reason I say that is that late last year we had horrendous problems with WIFI here in Spain, some kind of attack. It went away but during that time over several days I was losing WIFI constantly so I made damned sure the ESP units would reliable log back in, in the event of temporary failure of MQTT or WIFI or both etc. And yet just occasionally this particular unit will not log back in – a power cycle fixes the problem but that means I need to know about it and ask someone to pull the plug for a moment.

So – I’ve implemented this for the two most important devices in the building – the main heating temperature sensor – and the ESP that controls the relay to turn the heating on and off.


Timeout NodeWhat you see above is as follows: 2 Node-Red “inject” nodes (standard) fire out requests every 5 minutes to MQTT to ask the relay and temperature units for the state of output 0. 

Which command is irrelevant as long as it is a query which returns a result and otherwise has no effect on anything.  So for example with a topic holly1/toesp and a payload of {out0?} the system is expecting a response of OFF or ON (irrelevant here) from topic holly1/fromesp/out0

The two incoming MQTT nodes (left, purple) pick up on the response and feed them into my “timeout” nodes  (node-red-contrib-timeout).

As you’ll see below, the operation is simple – the timeout node doesn’t care what is incoming as long as something is. if it gets nothing for 60 minutes it will time out and send a payload out – in this case thanks to the standard email node (green) an email to me. 

During that time, normally, the MQTT nodes would have responded every 5 minutes – ie 20 times, topping the timeout node up to 3600 seconds even if most of the messages were missing (and there is no reason why any should be missing).  In this case I’ve not put messages for “safe state” or “warning” – so nothing goes out unless the timeout actually runs down to zero.

Click on any of these images for larger versions.

So while this does not solve the problem, it does mean that I’m alerted to the issue and can ask someone to disconnect and reconnect the relay unit. With what has been 100% reliability of Raspberry Pi 2 boards (with a decent Samsung microSD or similar) I can be pretty sure I’ll get an email if something goes wrong.

I hope this proves useful to others.


Home Control and Nextion Updates

Just a brief update. Thanks to some feedback I was prompted to see if it is possible in the home control project to get feedback as to the state of an output on the same line as controlling it.

hapticSo for payloads you might use {out12:1} to turn on GPIO12 and {out12?} to get feedback – well you can simply join them together as such into one message:


Also on the subject of haptic feedback when using the software for a Nextion display, put a haptic feedback device onto GPIO12. I used these:

In the last couple of days I’ve updated the manual and the software to make the responses more consistent.

Nextion WIFI Touch Display project:  Reader John was trying to send a string to the Nextion display from my software and I said I’d check…

So having put the unit into Nextion mode by sending the relevant command {set_serial:2}  which then reboots the unit….  I sent this command… {to_nextion:"t0.txt=\"Hi there\""} and here is the result coming out of GPIO4 or GPIO5 depending on the labelling on your board….

You can click on the image for a larger version but if you refer to the bottom right – you’ll see the message has been picked up by the logic analyser and it is fully intact with the three FF bytes inserted on the end for the Nextion display.

Logic analyser

As a result of this I realised I was not parsing \r\n properly – not that they are needed for anything I’m doing – and these are now implemented in the latest update (1.3.4 at the time of writing)



Status update

GaleraIt may seem like I’ve been quite the past week – but having arrived safely in Spain we’ve had lots to do.  However I have done some updates to the “home control 2016” blog entry as I’ve implemented some fixes to the node-red-contrib-esplogin node.

For those of you unfamiliar with this – the idea is a node-red node that updates a bunch of ESP8266 modules with time and date info as well as dusk and dawn timings. It does this on power-up of Node-Red, on demand from individual units and every 12 hours – except it wasn’t doing it every 12 hours. It is now. Here’s the link for those interested. The node itself also now has much better status information and help.

cludgeMeanwhile I’ve been struggling with rubbish broadband back home in England as the router failed every now and then to reconnect. Aidan and I have implemented a solution using one of the ESP8266 modules which will check Google every minute and if it gets nothing for 10 minutes will reboot the router.

new layoutAidan is working on a new version of the home control board with a couple of minor improvements – the connection for a Dallas temperature chip is now a 4-pin job suitable for the Dallas chip or the DHT-22 and we’re also putting on-board an optional RGB serial LED as the status LED on the board uses all sorts of flashing convolutions to indicate state and we thought it might be nice to use colours instead. There  is still a question mark over simultaneously using PWM and sending serial data to LEDs and that is being tested right now.

There’s a significant update to the ESP8266 source(home control 2016 project etc.) as I fixed a minor silly in my watering system code. and added a load of improvements including a serial RGB indicator LED

Meanwhile I’m sitting here on the edge of my seat waiting for a new Nikon camera to arrive so I can make best use of the excellent weather out here in Andalusia.


North East Maker Faire 2016

peepsI could not be there at the Maker Faire UK in the Centre for Life in Newcastle – but thanks to my spies – it’s great to see so many people there.

Apparently this couple on the left are into ESP8266 and got some ideas from the blog.  Glad you like it guys and sorry I could not be there. Understand you had a chat with Aidan.

Hope everyone there is having a great time – let us know if you’re looking in.

Meanwhile I’m in and settled in Spain – spent the whole day updating software (and more to go as in many of my older boards there was no OTA software.  Just cracked the problems I was having with PWM on the ESP software and so the repository now along with the .BIN file I made available are all updated. 

And now, while the sun is shining (and it is 23c outside) I’m off to update the rest of my boards.