Category Archives: ESP-12

Weather 2 Board and ESP8266

tmpE044NOT the cheapest board on the planet, I was handed a couple of these little boards by a friend this weekend.. the weather-2 board.

The board uses 2 i2c chips – the BME280 which as you may know is a miraculous little chip offering temperature, humidity and pressure readings all in one chip. I already support that in my ESP8266 code. Nothing new there and the chip works as expected when plugged in using this module.

What this board brings to the party is a chip I was previously unaware of – the si1132 – which in one chip offers readings of visible light level, UV level and IR levels.

The original library for this used floats and I’ve reduced that down to integers – looking at the variations I doubt I’ve affected accuracy at all – and these now come in the form of I2c commands in my ESP8266 code..

{si1132_uv}

{si1132_ir}

{si1132_visible}

Assuming the board is attached (or a board containing that chip that works at the same I2c address) – you can grab readings from this chip no problem.

I could envisage one of these outside – in a cover that protects it from the direct light and direct heat of the sun, offering all 6 readings – handy for lots of things.  Or maybe you just want an alarm when you’ve had too much sunbathing – I’ll leave it to others to figure out best uses.

Makes a useful addition to the home control project. Source of the ESP8266 code available as are ROMS.

Facebooktwittergoogle_pluspinterestlinkedin

ESP8266 Home Control Update

As the blog entry on using my home control code ROMS for ESP8266 is filling up and of course as much of the information is now dating I thought I’d do a new blog to bring everyone up to speed and move the conversation to this blog entry. The good news is  - the code is now running under SDK 2.0 – i.e. bang up to date at the time of writing.

Firstly – yes, everything works – but the procedure for flashing ESP-12 etc has changed ever so slightly. I have updated the binary files to run on Espressif SDK 2.0 and updated the RBOOT code I use for OTA (over-the-air updating) to the latest version.

To backtrack a little

For anyone new in here – some background - I’ve written software for the ESP8266 which has been in operation for some time and is under constant development. It allows the ESP8266 to control things like simple lights, serial LEDs, PWM LEDs and read sensors etc, talking via WIFI and MQTT to whatever central system you have – for example a Raspberry Pi with Node-Red. I’ve written a node to allow endless units to log in and to provide central communications for them. The software is rock solid and runs 24-7.

I use Windows to develop the software using the Cherts unofficial development environment. This provides an IDE using Eclipse for running and compiling C code. It is not necessary to use any of this if you simply FLASH the ROMS which are available – but of course if you do use the IDE you can customise code for your own use.  The projects Home Control 2016  and Nextion WiFi Touch Display both use the same software and are the end result of many years developing home control. Personally I access much of this equipment using Apps like Blynk and more recently Imperihome (see also this article, this and this).  Tools I use in Node-Red include my own BigTimer node.  All of these options were chosen after much deliberation.

So what have I learned and what has changed?

All has been going well until recently when the Espressif SDK for ESP8266 was updated, firstly to 1.54 then very quickly followed by 2.0 and all of a sudden I and other started to have issues starting up ESP8266 boards. This is now resolved incidentally.

Firstly one of my problems was lack of serial output on power-on. Some serial (115Kb) status messages I have on power up, just point-blank refused to show. I figured the code might be starting at the wrong place. But no, a quick port flick at power-up proved that everything was working – but no serial out.

After much debugging, I discovered that there would be no serial output until this function:

  wifi_set_opmode(0);

had been called. Prior to SDK 1.54 this was NOT the case. Simple enough - I put this at the start of my code – I’ve just checked and web updating works just fine - but merely moving this function to the start solved all the serial output issues.

Incidentally much is made of the “garbage” that comes out of the ESP8266 on power up – it is just that Espressif chose to use 78,600 baud instead of a more popular one. If user software is set to this speed rather than, say, 11500 (which is what I use) then things look very different – diagnostic on power up followed by user code – all very seamless. Problem is – not that many serial terminals support 78k.. but I digress.

The second problem was a tendency for the unit to run away with itself, firing out garbage as if the ESP-12 was broken. It would SEEM that post-SDK-1.53 or thereabouts – it is NECESSARY on initial run, to flash location starting 0x3fc000 (end of the 4th page in a 4MB Flash chip) with the default file esp_init_data_default.bin which is found in the Espressif development kit.  If this has already been blown (previous installation) then it is not necessary to redo that, but with a CLEAN FLASH, failure to flash this area results in the continuous rubbish on output. Again this did not seem to be the case before SDK 1.53/4 – I have NEVER flashed that location in the past. Once blown it is not necessary to blow this again for OTA. Still – now we know.

I’ve just had a Skype chat with Espressif engineers to try to dig deeper. They have confirmed the small file at the end is essential (I probably didn’t notice it before as I’d generally be using boards already programmed) – the serial issue we’re still trying to understand – but it all works.

System Data

There are 2 relevant files here. A file called blank.bin sits at 0x3fe000 (top of the third MB in a 4MB Flash i.e. ESP-12) and contains default system parameters produced in the SDK.  NOT setting this initially seems to have no effect on my code.

A file called esp_init_data_default.bin sits at 3fc000 and contains default system parameters stored in the SDK. This is a 1K file. This HAS to be blown when first setting up a chip.

What to do

There is a binary file called esp_init_data_default.bin which I have added to the server at www.scargill.net – this is in addition to rboot.bin and romx.bin

In the Espressif setup there is a file called ESPTOOL – there are exe versions and .py versions of this floating around (see below). This is what I use to flash the ESP8266 chips – there are others – you may use them – but I can’t VOUCH for them!

https://github.com/themadinventor/esptool

https://github.com/metalheart/esp8266/raw/master/bin/esptool.exe

In Windows this works for me – you will have to check for yourself.

To completely wipe an ESP12 – including all data and setup etc and assuming COM3 in this case (not necessary but if it makes you feel better)…

esptool.exe  -p COM3 -b 115200 erase_flash

To initially flash the code from scratch… assuming you have the 3 files mentioned above…

esptool.exe -p $(COM3) -b 115200 write_flash -fs 32m -ff 80m -fm qio 0x00000 rboot.bin 0x02000 romx.bin   0x3FC000 esp_init_data_default.bin 

Obviously you can change port, speed and file locations. I usually double up on that baud rate but this one is safe.

If you insist on trying this with an ESP-01 (no way will OTA work) – that 3FC000 address becomes just 0xFC000 as they only have 1MB of Flash unless you upgrade them (discussed in another blog in here – done – easy).

As an alternative, I’ve tried NODEMCU FIRMARE PROGRAMMER and that seems to work…

NodeMCU

Nodemcu[6]

And so there it is – the source is updated on the web and requires SDK 2.0 or better to run. The ROMS are updated and the new file is up there.

Bear in mind there is some data here NOT being erased (see full erase command higher up) – in my case at 0x79000 – or around half way up the first megabyte – this is USER data – stored passwords etc. it was put here for compatibility with ESP-01 but I’m about to move this way up to 0xf800 leaving the best part of a MB for code – plenty of room.

And why?

Why worry about updates indeed? Well, one good reason – is that recently, updates to the SDK have used LESS precious RAM – the kind that programs (not data) run in – so with 2.0 there is more margin for expansion – which means more features and more room for more features! It is fine having 1MB to put code in but that is generally NOT the limiting factor with the ESP8266. The code ultimately has to run in RAM and there’s a slight bottleneck there – the gains of later SDK updates help a lot.

Update 31/07/2016

Having now  added i2c and parallel LCD displays to the board, I set a parallel LCD running from MQTT and updating all 4 lines of the display, once a second from Node-Red. While this was running (it’s been running all afternoon – I thought I’d try a test)… I set my serial terminal program fire out lots of on-off commands in a row – which is WAY over the top…

I set up 30 on/off commands for GPIO0 – to run at 80ms each – as you can see clean as a whistle.  I dropped that to 50ms per instruction and the board rebooted – I’m guessing that is a buffer overflow – but then – that simply is not going to happen in real life or anything like it.

I figured I’d go for broke - with 390 (I got sick of cut and paste) commands sent at 80ms it lasts almost to the end then rebooted – again a sure sign of the buffer being in trouble either overflow or wrap – backing that off to 100ms gave zero errors so not a wrap issues – Very happy with this – typically the boards get no more than a few instructions a seconds – often MUCH less. For the sake of it I think this coming week I may just take a look at this – firstly to see if at such speed, my terminal is screwing up – and if not – I’ll see if I can narrow that down but it is utterly academic

serial tester

A complete and utter aside

I don’t use the Arduino setup but as I was thinking about user data, I just checked the Arduino EEPROM library SOURCE for ESP8266 and the Arduino environment does NOT use the 3-sector trick employed in the SDK. When you update the EEPROM (which is actually FLASH on the ESP8266), the sector is wiped (even if you have user data smaller than 4k, a 4k sector is still used) and then updated from RAM – not ideal.  I have suggested to the designer that it might be a good idea to change this. Right now he’s busy working on ESP32 code.

So there it is – all working – hopefully I’ll soon get some clarification on the routine I mention above that I had to move. Time to start adding new features!!!

Facebooktwittergoogle_pluspinterestlinkedin

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…

{i2c:39,0,3}

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

{i2c:39}

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

http://tech.scargill.net/sunday-morning-experimenting/

http://tech.scargill.net/i2c-expansion-for-raspberry-pi/

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

{i2c:8,0,1,20,1}

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.

{i2c:8,1,4,30}

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!!

Facebooktwittergoogle_pluspinterestlinkedin

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 1.5.4.1 from Espressif http://bbs.espressif.com/viewtopic.php?f=46&t=2376

If none of this means anything to you see:

http://tech.scargill.net/blowing-the-home-control-2016-code/

http://tech.scargill.net/home-control-2016/

http://tech.scargill.net/nextion-wifi-touch-display/

Facebooktwittergoogle_pluspinterestlinkedin

Blowing the Home Control 2016 Code

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

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

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

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

tech.scargill.net - home controlI worked with Richard Burton to get RBOOT working on our code– it is his software which allows for OTA (remote updating) when developing, in my case, in C on the ESP8266.

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

flashing

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

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

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

A reminder – what will my software do?

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

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

NOW you can access the board with your mobile phone WIFI as “hack-Setup” and once connected use the phone browser to go to 192.168.4.1/wifi/wifi.tpl 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:

www.scargill.net/rboot.bin

www.scargill.net/romx.bin

www.scargill.net/esp_init_data_default.bin

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

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

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

Facebooktwittergoogle_pluspinterestlinkedin

ESP12 and Memory

Anyone writing large projects with the ESP units in C (and probably in other languages without necessarily realising it) will have come across the problems of .TEXT memory. This is the RAM used to store functions.

Functions are stored in their own part of RAM called .TEXT memory and it is WAY too small. Now most of you will have made liberal use of the “ICACHE_FLASH_ATTR “ directive in your functions. This ensures that functions stay in FLASH until actually needed and this saves lots of .TEXT RAM – indeed without it, larger programs would be impossible.

Despite all of that I’ve been slowly running out, sitting at 7CFF  (you can only go up to 8000) recently and when the latest API came out – that was it – over the top – dead.

So for a while I stuck with the previous SDK and eventually got onto Espressif.

They asked me for a .DUMP file – which of course I neither had nor understood and they suggested that in the project directory I type:

xtensa-lx106-elf-objdump -x -s app_0.out > app_0.dump

WELL I was convinced this was another Linux tool that would not work in Windows – but it DID and produced the English-readable file app_0.dump which tells you where all your functions are sitting.

They suggested I add the "ICACHE_FLASH_ATTR"  to my EASYGPIO functions. Well of course as that was an existing library I’d not touched that – and sure enough – I got just enough memory back to be able to use the latest SDK!!   I was now sitting at 7B52 on the latest SDK – not good – but better… and at least I was using the latest SDK. They then suggested I use "os_memcpy, os_memset, os_strcpy" instead of "memcpy, memset, strcpy" so I systematically went through all the code and did this.

On recompiling – I now find the .TEXT RAM sitting at 79C2, the lowest it has been for AGES – another 512 bytes back just by using their functions instead of the standard ones!

I’m making no claims about reliability as I’ve not given this a thorough test – but that is for me a very worthwhile improvement in memory. Of course that means a tiny slow-down as functions have to be pulled out of FLASH to use… What speed would we have gotten out of these devices if they’d just done the RAM differently. Still – given the price of ESP devices I suppose we can’t complain.

Facebooktwittergoogle_pluspinterestlinkedin

ESP8266 Lessons Learned

ESP-01The Trip: As regular readers will know, I’ve just returned from working on the first stages of a project in Spain to analyse information from ESP8266 chips. Without going into any commercial detail, this is what I brought back from that trip.

The scenario: The tests were done in a rural environment, initially with a bank of 40 ESP-01 boards. These were powered by a single 20 amps 3v3 power supply. Yes, a switched supply. The boards were mounted on Veroboard and power applied. You really don't get a lot worse than this - no linear regulator to smooth out the crap ( I would normally run 5v switched and a linear 3v3 regulator on-board for each device), lossy tracks on Veroboard, signals interfering with each other..  except it DOES get worse - read on.

The Place: The location we conducted our tests was off-grid, relying on solar power and a generator - and the weather most of the time was cloudy - that meant at regular intervals the remote generator kicked in and when it did a couple or so mains cycles were lost as the set-up there uses a combined inverter/charger. The result of that was that at regular intervals, the router reset.

boardsAside from actual power cuts you don't get much worse than this. At first when we switched on the boards - which are running a modified version of my home control software which is in turn based on TUANPMs MQTT code with a boatload of stuff added and a lot of tweaking over time, only some of the boards would report back. A quick check of the router revealed that by default it only allocated enough room for 32 connections on DHCP. That was quickly doubled and lo and behold, all the boards logged in by MQTT to the PC (running Node-Red and MQTT and firing off data to a database).

Useful outcomes: Well, any thoughts I may have had concerning reliability completely vaporised this last 2 weeks as day after day our little bunch of 40 boards (not even all from the same supplier as some were blue, some were not) just sat there constantly delivering information. This is soon to be increased to 120 and with a power supply currently running freezing cold I am confident there won't be any issues. And all of this for far less than the price of a half pint in London.

So if you're just starting up with ESP chips - bear the above in mind before jumping to conclusions about board reliability. The boards used in the test, running as I speak, were the early 512K versions, today I always use ESP-12 boards in my own projects as they have eight times the amount of FLASH which means OTA, big programs (up to 1MB of C code (that's a lot)) and in the case of the "F" version arguably better antennae.

Coming up: I’m sitting in front of a set of WIFIThing kit – and I’ll shortly put together a short review of this equipment including a very nice WIFI wall socket.  Also – is there really an advantage in using USB3 memory sticks? I’m sitting in front of a couple of 32gig units and I’m about to run some tests. Check in later.

Facebooktwittergoogle_pluspinterestlinkedin

Home Control 2016

Introduction (Latest update December 15, 2016)

HomeSick 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 – low cost, DIY.

If you’ve read my early blogs you’ll know that Aidan Ruff and I have been working in home control since the late 20th century. Together, we ran an electronics R&D company for many years and one of our products was a home control system called APPCON.

That range of products  achieved much coverage in the UK tech press at the time and many loved it but the design involved spouse-unfriendly WIRES – bad mistake. So now we’re back – this time for fun –  with a vengeance!

Home Control 2016

Add to that lot above, the SI1132 unit which returns light values for visible, UV and IR - and a host of other I2c boards around the corner.

By the time you look at the diagram above it will likely be out of date as new features are added – thankfully there’s a manual along with source code and diagrams available online and kept up to date. This is all free incidentally and without warranty. We have software, diagrams, board layouts… and this blog has a range of articles on the subject.

The diagram pretty much says it all – a Raspberry Pi (2 or 3) or similar,  talking to your PC or smartphone via a range of potential technologies – and using a powerful communications protocol called MQTT over WIFI to talk to small yet incredibly powerful ESP8266 units – these can be bought very cheaply and programmed – or you can take our board designs and have some boards made in China if you really want to DIY (we do!).

There are no real limits to the number of 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 3 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 £50 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 “Unoffical Development Environment” for the ESP8266 – but that won’t stop Linux users from bending the makefile to their will!!

There is a DOC file here which is fully up to date with all commands – 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:  http://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. Using up GPIO13 to 16, 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.

How useful this is depends on how many other pins you need! We need an ESP8266 with many more IO pins – I guess that will be the ESP-32…

Background: I’ve been using ESP8266 chips since they first came out – and I have the development kit for their new ESP-32 –just waiting for some decent software tools to emerge 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. I’ve also recently been 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 for some time now, the ESP8266 boards have been turning the world of IOT upside-down. I’ve long-since scrapped various 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 RPI3 and other exciting boards such as the tiny FriendlyArm NanoPi Neo.

Hardwired to Ethernet (or WIFI if you prefer), 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 REALLY 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).

There are a number of variations on the ESP8266 boards, the first shot at this being the 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 of course use 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’m giving 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 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. Instructions here may not be fully up to date but always check the WORD document in the repository. You might also want to look at the Nextion WIFI touch display board and links – I discuss another control board in there as it can be used for general purpose. This board has neither a relay nor power supply (other than 5v to 3v3 conversion) on-board but it’s a better job for general use.

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.

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 the latest Espressif SDK version 2.0

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

The Boards

For the reasons stated I’ll discuss here the ESP-12 (and variations, ESP-12F being the latest with 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 new board version 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 them 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). Again in the latest version we’re moving to 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)

rearview

Note that a particularly 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
  • 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
  • All signals brought out to edge connectors
  • Uses inexpensive power supply (or DC/DC converter) available on EBay
  • De-bounced input with automatic debounce 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 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
  • A new SPi-based experimental terminal
  • 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.

Whatever controls these boards(Raspberry Pi?)  should now 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. Last summer 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 (output 4 goes to pin GPIO4).

{out4:1}

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

{out4:1;out4:0}

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 2 (you could use 3 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. 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 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 the 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.

clip_image002[6]clip_image004

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

Preliminaries

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… but I prefer per-unit linear regulation.

We done just that in all our own boards, using a switched-mode 5v supply (or DC/DC convertor for 12v use) with a 3v3 linear regulator. I suspect most complaints about these boards 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.

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…

clip_image006

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 manual that comes on BitBucket with the code is way more comprehensive than this blog in terms of commands.

Command set

Controlling and monitoring outputs

The potential outputs are GPIO0 (that’s the one on the board with the relay – future boards 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 it 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 {out0?}

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

{out0:X} responds to the following for X:

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 0. 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 {out1?} {out2?} etc. Should unit “kitchen_light”  be asked for the state of out1 – the MQTT message sent back will be in the form

topic: kitchen_light/fromesp/out0

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.

PWM

We’ve added PWM onto 4,5 and GPIO15 using the latest 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 ones (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 (needs work).  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 i still running – so if you run PWM with a board, don’t expect reliable SERIAL LED operation as the PWM has a minor effect on really critical timing as needed for serial 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):

{peak:X}

{off-peak:X}

{frost:X}

{on_1:X}

{off_1:X}

{on-2:X}

{off-2:X}

Time settings

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

{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 ADC

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

Debugging

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.

Expansion

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.

{out0:1;out2:0;ext:”out0:1”}

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!! You can develop in the C language for the ESP boards using the unofficial Eclipse development environment.

http://programs74.ru/udkew-en.html

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

clip_image008

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.

i.e.

{id:”123”}

You can also 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 192.168.4.1/wifi/wifi.tpl 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.

Reset

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

Inputs

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?}

Manual Override

If we wish to manually over-ride the status of GPIO-0 – for example wall control of a light – set {override:1} to do this – the input can then be attached to an on-off switch and will over-ride the output for a length of time in minutes determined by “override_time”.

RGB LEDs

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 currently 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. I’ve contacted Espressif about this.

The 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:

{rgb:12,255,0,0,20,10}

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.

Other

When the board powers up it sends a message “esplogin” and in the body the the name if its 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.

Node-Red

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 MySQL database with ease. 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 a 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 yesterday wasn’t that sunny.

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

 

tmp3A16

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 that important but can be shoved away in a database.  So that sets off the esplogin node  putting info to it’s 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 – and will then do that every day 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 ESPs can be updated 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 a SCRIPT. You can grab a Raspberry Pi(2) and put everything on there. The script works with JESSIE version of Raspbian. I made this script for “Jessie”. Follow the instructions precisely or it will not work. You must be user PI and NOT ROOT. Read more about the script here...  and

I use the Pi2 – after testing many boards this seemed a while ago to be the best for the job IMHO 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-dsahboard 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.

Notes:

[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] GPIO0 (out0) is special in that it responds to more than “1” and “0” and can be used as part of a heating control system. Ultimately we will scrap 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.

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

 

Enjoy!

Facebooktwittergoogle_pluspinterestlinkedin

The Nextion Experiment

Nextion BoardOur latest experiment! The board you see to the right should be with us in a couple of weeks. This little number will sit on the back of a Nextion board, from the smallest to  the largest without adding any height (hopefully) and contains as you see an ESP-12 and supporting components.

The extra connectors are just to give it a more general usefulness.

Having implemented software serial on GPIO4 and GPIO5, the board will allow for sending messages via MQTT directly to the Nextion while still allowing debugging and programming of the ESP using the normal ports. 

Far better I think than strapping a Raspberry Pi onto the things. We’ve not tried to do anything too clever here so this all assumes the display is already programmed up.

My own use for this is a couple of simple wall units to show and control heating and lighting… I already have a display hooked up to a Raspberry Pi for general control but it’s a tad excessive having those plastered all over the house hence this board which we’ve had made as thin as possible.

Can’t tell you much more until we get the boards back and give them a go.

Currently ending my first week of a 2 week contract (well for now anyway) over in Spain so my ability to experiment is severely hampered as you might expect (but that is compensated for by sunshine). 

By the time I get back to the UK  I’ll have some more Sonoffs to play with (hopefully the later types with one of the LEDS attached to GPIO13 on the ESP8266) and some new ESP-related stuff to review.  My new workshop is up – just needs electricity, insulation, desks, shelves – no problem really!

Facebooktwittergoogle_pluspinterestlinkedin

APDS9960 Gesture Sensing with ESP8266

APDS-9960A thought for a little display project. I recently came across some code for an LCD display (160*240 - detailed in a previous blog) using the ESP12 and an LCD display. But I'm inclined to use the Nextion display (also detailed in a previous blog) because it is touch sensitive. The only problem with that is that the Nextion is somewhat more expensive and larger.

One of my pals brought this chip to my attention – the APDS9960 Digital Proximity, Ambient Light, RGB and Gesture Sensor.

It is i2c and not only reports back RGB and general light levels but also has it's own IR transmitter and logic inside to decode simple up, down, left and right gestures. So here are my thoughts - for example for a simple thermostat. Put next to the display it would offer simple up/down control of temperature as well as left/right perhaps to show a graph.

For more complex operation, one could make some kind of convoluted movement which would then trigger off a menu - with left/right selection and up/down change.

Worthy of further thought and has anyone already implemented the i2c code (Arduino ESP8266 C for example) to talk to this device?

Facebooktwittergoogle_pluspinterestlinkedin