Category Archives: ESP-01

32Mb ESP01 and Sonoff

Some time ago I passed comment in here about converting an ESP-01 to 32Mb  (or 4MB).  And here it is in the flesh – a 32Mb ESP-01 – and also – at last - Sonoff Upgrades.

Now, why would you want to do all of that? I would suggest only if you happen to have lots of ESP-01 units lying around – and I’ll bet quiet a lot of you do. As for the Sonoffs – well, put it this way, I just ordered another 10 chips!

CompareI stopped using the ESP-01 a while ago because the standard 4Mb (512K) of FLASH was simply no longer good enough. Richard of RBOOT fame set me using using his RBOOT program so I could easily flash my home control code (see Home Control 2016 and Blowing the Home Control 2016 Code). Partly because I keep adding new stuff and partly because of the size of the Espressif SDK, Although my code will still run in an ESP-01, it certainly won’t OTA (remote over the air programming).  And so my little ESP-01 boards have been sitting gathering cobwebs. The Sonoff mains controllers on the other hand are VERY useful but it annoys the hell out of my that my software is now too big for the limited FLASH in these units – at least, for doing OTA remote updating anyway. All of that, for me, is now history.

A few weeks ago I noticed the Flash chips available for very little money and thought “go on then, why not” despite never having thought of updating Sonoffs – well, today, weeks later, they arrived, all five of them. I mean, at £1.86 for 5, or 37p each – you have to give it a go.

I got my fine soldering iron out (who’s bit is so fine it looks like it will last all of a week) and opened up the package.

Compare[5]The first thing I noticed is that these chips are slightly wider than the one in my little ESP-01 – chips shown side by side in the photo above. To remove the originals, I took my tweezers, put the side of the bit along the side of the chip – and when the solder melted, just lifted the chip a little – then did the other side. Came off a treat.

ESP-01 on motherboardWhat to do about this width problem…,   I decided to hold the new chip and flatten the leads on either side (vertically) by merely pushing against my desk.  You’ll see in the photo on the right – which shows an un-adulterated chip (the upper, larger one), the lower right photo showing in the middle, the one who’s leads I flattened – and the original chip from the ESP-01, lying on it’s back.

Doing that added very little to the height but positioned the leads smack in the middle of the surface mount tracks. With a fine soldering bit and fine solder it really was a doddle to re-solder the new chip back onto the board. I’d say total time to remove the original and put the new chip on – something like a minute.

And here it is – the ESP-01 is shown here mounted on one of a little adaptor board to allow 5v operation and standard FTDI connector etc. As you can see in the picture, the FLASH chip is a tad higher than before – but only by 1mm, it works a TREAT, flashed first time and my test function shows it as a 32Mbit chip.

flashsize=Manuf ID= 239, Type ID= 64, Size=4194304

And on power cycle, works a treat. Ok, yes, only worth it if you fancy a soldering challenge and you happen to have a load of otherwise useless ESP-01 boards – but hey, that’s what hobbies are all about.

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

Use the {debug} command for more information.
STATION mode
Web page control enabled
Waiting for Access Point wififorus
Connected as 192:168:1:34
MQTT connecting
MQTT Broker connected
Device ID is modified
Item published
Time is 10:48:01 06/07/2016
Ok
Tick

sonoff upgraded to 32MbitJust to prove to myself this was not a fluke, I modified a second board -  worked a treat (well, programmed a treat but would not work then I noted I’d shorted pins 3 and 4 together – fixed that – immediately worked a treat). Yes, I’d say total conversion time around a minute or so. Of course now I don’t know what to call them – ESP-01+ maybe!!

Just earlier after I wrote the blog – and LOTS of people took an interest, I received a comment to ask if it was possible to upgrade the Sonoff.

Well, there’s only one way to find these things out – so back to the soldering iron and yes, not QUITE so easy to get the iron in there – but yes, I now have a working 32Mbit Sonoff – this changes a lot and THAT is why I’ve just ordered another 10 chips.

The Sonoff chip is the EXACT size of the new chips I bought so no bending of leads. Just a VERY careful soldering job – you HAVE to have a pointed fine tip to do this – your dad’s Antex bit will not do it – but – I would say maybe 5 minutes this time being careful not to melt the stand-up LED?  I will update my other Sonoff boards now but I’ll have to wait for more chips to arrive – whoever thought it would be this easy. See my original blog on the subject for programming.

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

A little aside

40 ESP-01 Boards

Some testing of 40 ESP-01 processors – all sending MQTT data data back to a database, powered by a 20 amp power supply.

Just two more of the same to go.

Of interest to those struggling with ESP-01 – I normally have a 3v3 supply on board but this time they are just on their own – so I was using the 3v3 output of an FTDI to power them and I had to have the odd retry at programming – something that normally NEVER happens. All my leads are short and properly formed so I’m hazarding a guess while the USB is able to supply enough current (at 5v) the chip on the FTDI is SLIGHTLY under-powered when delivering 3v3 to the ESPs.   Next batch I’ll put a large cap across the power. Having said that out of 40 flashing attempts I think I only had to retry 4 of them.

All working a treat and looking distinctly spiffy as the 40 blue comms lights flash – sometimes in sequence, sometimes out of sequence.

Facebooktwittergoogle_pluspinterestlinkedin

EMW3265 ESP8266 KILLER

EMW3265Erm, no, though you might think so by this headline..  https://hackaday.com/2015/07/13/new-part-day-the-esp8266-killer

Read the comments – the $5 ESP8266 – where?  $2 ESP8266 more like it – less, even - http://goo.gl/VB0V9K

There’s even a claim that this new single-source board (Seeed Studio) has MORE memory – well at least one variation of ESP12 has 4Mbytes – and the EMW… according to the ad, 512K.

And what about the all important Windows and Linux support libraries? Erm, no.

Another comment – Chinese documentation? Well I don’t know about you guys but I have  raft of English documentation that until recently came with the Espressif SDK and which is now maintained online.

And the last – Chinese – guess where SEEED are!

Cheap, reliable, effective, more compatible variations of ESP and more suppliers than you can shake a stick at – and we want to move for what reason?

But – if you like spending money – there’s this – even more expensive - http://www.seeedstudio.com/depot/EMW3162-WiFi-Module-p-2122.html

Facebooktwittergoogle_pluspinterestlinkedin

Automatic Router Selection for ESP8266

I wonder if anyone who has done this can help.  As most of you know, I program my ESP8266 devices in C.  I've been having some issues with weak signal recently and it would be really nice to have a list of acceptable access points and their passwords - and have the ESP, if it loses the signal, check the list (including identical SSIDs) and reconnect.

Has anyone done this already and if so would they care to share code?

Facebooktwittergoogle_pluspinterestlinkedin

ESP8266 Remote Access

Notice I titled that remote access as against remote programming – but that’s part of it.

Years ago, having gotten sick and tired of dismantling my home control Arduinos just to upgrade the code, I purchased a couple of small units from China which I’ve just thrown in the bin.   One had a USB plug on it and plugged into the PC, the other had an FTDI output on it. Both had those black 2.4Ghz antenna.

So the purpose of these units was to wirelessly replace an FTDI – or serial programmer, the idea being that instead of bringing the Arduino project back to wherever one programs the devices, you plugged the unit into the project and over the air programmed it.

At the time I was using Arduinos and those CHEAP £1.50 radio modules – the NRF24L01s, the worst radio boards in the world who’s range could be so bad you’d be lucky to get through one wall. I had high hopes for them with a great mesh network called RADIOHEAD, but ultimately their range and lack of ability to read signal strength doomed them.   However, as you can imagine they were dotted all over the house and I thought this little radio pair would solve the issue of programming them without ripping everything up.

It turns out the “radio FTDI” had the same problem – it was based on the NRF24L01.

Fast forward to September 2015. Here I am in Spain with a new setup of ESP-12 modules controlling lights, watering system and a lot more.  I’ve made some improvements to our “home control 2015” software in the ESPs and once again I find myself having to dismantle kit.

Now, I know that is it possible to program over the air – a few guys have tackled this successfully and indeed much of the code is built into the Espressif SDK. Right now my friend Aidan is working on adding this to our code but there are two issues, he’s not had luck up to now and secondly as our code comes to something like 300k you’re never going to be able to add this to the ESP-01 modules (we use ESP-01 sometimes, ESP-12 other times…)  as you need as much spare storage as you have code for OTA programming!

It was with that in mind that last night I dragged out the old FTDI boards to see if I could save myself the effort of dismantling the Pergola lighting system to update it.  Suffice it to say that I managed to get a few bytes programmed before that all came to an end despite several attempts. With around 25 WIFI units of one description or another dotted around the place, the old wireless FDTI (same frequency range) simply could not handle more than a few feet.

Bin.

I figured it would not hurt to look around and see if someone has alternative wireless solutions – lots of time has passed since I bought that kit.

And so it was that I stumbled upon this.  https://github.com/jeelabs/esp-link – as it happens it is quite new – essentially what we are looking at is a single unit (yes, that had me going for a while) which will hook into the WIFI system and act like an FTDI – given that you can fire the serial out of your PC over TCP to a port – port 23.   I grabbed the code (the stable 1.04 version) and very excitedly blew it into an ESP-01 unit I had lying around.

Really, nicely done web interface (with remnants of Martin Hanzarov’s code in there) and a really good write-up – indeed there may be enough info in there to help us implement our own FOTO (over the air) updates to our code.

But this has far wider implications – a virtual serial link would also let you monitor the serial line of a remote unit for debugging info – and our units do indeed put out lots of serial debugging info. It would also let you remote program and monitor un-wirelessly enabled Arduino projects.

So the first problem was – I had this unit sitting as 192.168.1.27 on my network and I needed to blast info into port 23 to have it come out as 115K serial.  I have ECLIPSE sitting on the PC running my projects and there’s a line in the MAKE file that says “COM6”.  I have absolutely NO idea how to turn that into a TCP statement if indeed it can be done (FEEL FREE TO START TYPING IF YOU KNOW HOW).

So I turned to a 30 day trial of a PC program that promised to provide a “virtual com port” – and that it did. Serial/IP Redirector let me create a link to 192.168.1.27 port 23 and ship raw data back and forth to COM22 (which doesn’t exist on my PC)- LO AND BEHOLD I set it running, put PUTTY on the PC talking to COM22 and with a real FTDI attached to the little ESP-01 board on real COM6 I set that running on a terminal –at 115K. Utterly flawless raw serial communications – rock solid.

I was getting excited by now. I took my ESP-01 board and cross-connected the serial to an ESP-12 test board. I held GPIO0 to ground and turned the power on, putting the ESP12 into programming mode.

I punched COM22 into the ECLIPSE project and hit the FLASH button on the project. Lights flashed on both units. With a scope attached  to the serial in on the ESP-12 I could see clean 115k data going into my project and… nowt, zilch, nothing.

I was up until the early hours ensuring the baud rate was ok and that my level conversion wasn’t getting in the way – you see all my projects use a resistive divider on the serial input of ESP boards so the whole lot will work just fine with 5v logic on the FTDI and elsewhere.  I wondered if hooking two of these units together with serial cross connected might prove too much but the scope says no – it says I’ve a perfectly reasonable serial signal going into the ESP-12 – but it’s not having it – no responding output whatsoever. Eclipse tries sending out data over and over and eventually gives up just as if there’s nothing connected.

So near and yet so far.

I got up this morning and the unit was still rock-solidly connected to the WIFI and typing a few characters provided perfect results at the other end – but I cannot program ESP units – yet.

Very exciting, yet very frustrating.

Perhaps coffee and a new start to the day will help. BUT I had to bring this to you as the article is really good, the software seems to WORK and there’s a super-bumper version with it’s own OTA updating in the works for larger targets like an ESP-12 (more FLASH) than the ESP-01.

I’m sure this is going to be a winner – just need to get it to work. After all, the ability to add remote programming to any FTDI-enabled project for what, a couple of quid.. well, you just can’t ignore it.

Meanwhile if anyone reading this firstly knows how to set COMX on Eclipse (on Windows) to TCP – do let me know – and if you really think you know what I’m doing wrong here and want to jump in before I figure it out – by all means – you have the keyboard…

Facebooktwittergoogle_pluspinterestlinkedin

ESP8266 RAM

I recently put out a question about the RAM in the ESP8266. In a typical compile, for me I might see…

Sections:
Idx Name Size VMA LMA File off Algn
0 .data 00000894 3ffe8000 3ffe8000 000000e0 2**4
CONTENTS, ALLOC, LOAD, DATA
1 .rodata 0000275c 3ffe88a0 3ffe88a0 00000980 2**4
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .bss 00009a80 3ffeb008 3ffeb008 000030e8 2**4
ALLOC
4 .text 00007786 40100000 40100000 000030e8 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
5 .irom0.text 0003ce04 40202010 40202010 0000a870 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE

All very confusing.  So .irom0.text is FLASH – why they can’t just call it FLASH I’ll never understand. The rest are various kinds of RAM.

.data is used for “initialised” data, i.e. that which needs copying from FLASH on powerup. I’ve used 0x894 in the above example.

.rodata is used read only data – this is in ram (again I don’t understand, if it is read only why it’s not in flash – most likely for speed). I’ve used 0x275c.

.bss is used for variables which are not initiased. I’ve used 0x9a80.

.text is used for CODE that is not in FLASH – i.e. it is in FLASH on powerup – but gets copied to RAM for speed.  Sadly due to lack of RAM we usually end up using a directive to put code into FLASH to save space – but REALLY time critical code should be left in RAM. Of course it does get copied into RAM (cacheing) but that could mean execution times which are different first time around – not good for RGB LED lighting etc.

A fellow by the name of Don Kinzer replied and here’s what he had to say.. very useful.

“There are no individual limits for the sizes of .data, .rodata and .bss (but see caveat below). The ESP8266 has 80K of User Ram which is occupied by .data, .rodata, .bss, the stack and the heap. Basically, the space represented by (80K - sizeof(.data) - sizeof(.rodata) - sizeof(.bss)) is used by the heap growing from one end and the stack growing from the other end. If the heap and stack collide bad things will happen (probably an exception, eventually, and a reboot).

The caveat that I mentioned is that the .data and .rodata sections, along with the .text section (itself limited to 32K) must fit in the first 64K of Flash. The sizes of each of these sections is rounded up to an integral multiple of 4 bytes and an additional 8 bytes of overhead are added for each section plus an additional 8 bytes of overhead. Finally, space for the checksum is added (between 1 and 16 bytes) so that the overall size is an integral multiple of 16 bytes. The total of all that must be 64K or less. The image containing all of this data is often called app.v6.flash.bin but the name itself is not important.

As for the limit on the size of .irom0.text, that depends on 1) the size of your Flash chip (commonly 512K but can be 16MB or more), and 2) where you load it into Flash and 3) if you want OTA upgrade or not. For non-OTA upgrade, it is common to load the .irom0.text at 0x40000 but it can be loaded as low as 0x10000. Since the system parameter area exists at 16K from the end of the Flash chip, the size of .irom0.text is limited to sizeof(Flash) - 16K - loadAddress.

If you want to load the (non-OTA) .irom0.text at an address other than 0x40000 you'll need to modify the linker script accordingly.”

Facebooktwittergoogle_pluspinterestlinkedin

BASIC for ESP8266

Don’t get me wrong, we don’t yet have a fully working interpreter, but a link appeared on my ESP8266WIFI Facebook page thanks to Michael Molinari this morning and I thought I’d give it a whirl.

http://esp8266basic.com/

I grabbed the Windows loader (Windows 10 put up a SEVERE warning about this which I totally ignored), plugged an ESP-01 into my FTDI and blew in the interpreter, all of which took a couple of minutes and zero effort.

At first I didn’t know what to expect, I looked at the serial port – nothing.. then realised it outputs at 9600 baud, not my usual 115K…. I then started typing stuff into the serial – nothing – at which point I noted it already knew about my router – I can only assume that is because the WIFI passwords were already in the board, normally you’d have to use the board as an access point just to put in your WIFI details… anyway, I managed to bypass that.

I checked the examples on the page – hello world and a graphics example – which worked right out of the box!! Imagine that – simple BASIC commands putting out graphics on a web browser from a twopenny WIFI board all on it’s own!!

At this point, things went down a little. I tried editing the code (in the web browser!!) and it wasn’t having a SAVE – I noted on the serial that it had crashed… but then if you look at the dates this is all very new.

Seriously this has to be worth a few minutes of your time – assuming the project continues and these niggles go away, you just don’t get a quicker, simpler and cheaper way to get a web page with buttons into an embedded device – even if just to do some simple stuff. This is now ENTIRELY down to how much effort the author puts into this.

Go take a look! These images should enlarge on click/touch. Well impressed IF development comes quickly enough….

Basic Interpreter for ESP8266   Graphics on the ESP8266

Facebooktwittergoogle_pluspinterestlinkedin

RGB versus HSV

Image author SharkDIn implementing my own home control solution which you’ll find in this blog “home control 2015” the software has been and remains a work in progress – mainly because I keep finding bugs and adding new features.  I’m fairly confident that most of the bugs that have plagued me over the months are gone. For example NONE of my boards has failed in the last week – running constantly, turning things on and off, monitoring temperature and humidity, powering RGB LEDS…

And that brings me onto tonight’s subject.  You may have  noticed elsewhere that I’m getting fanatical about the Nextion displays because now at last I have the potential of a nice touch display for the wall to control things. You’ll also notice I’m realising their code is VERY early – but that’s another subject.

The first addition I made today to the home control system was to allow any of the ESP boards to send an MQTT message to any other board. Of course that is built into the MQTT library in the first place and there would not be a lot of use in having the Raspberry Pi brains send a message to one board to send a message to another.. but it occurred to me that an essential feature of a serial wall mounted display would be to control more than just the ESP8266 board that it is actually attached to!

So – in went a new command to send out an MQTT command from the serial input on the board so that the ESP board could pass the message on. That’s a little tougher than it sounds as I only had one string argument available in my line parser so I had to delve into that – however, it is now all done.

And that led me to thinking about how my wife Maureen would control the coloured lighting around the house, from the wall.

RGBObvious really, RGB sliders – you can make any colour or hue from RGB can’t you – any techy will tell you that for free.  Sadly the rest of the world does NOT know how to manipulate RGB. Any paper artist will tell you that the primary colours are red, yellow and blue! Not in my world they are not.

And so we have a problem – how to better enable any old user to play with colours – and hence I started reading and it is pretty clear that a better model is HSV, or hue, saturation and value - brilliance in other words – I looked up HSV on Google but the best I could find was Herpes Simples Virus. I’m going to continue to refer to brilliance as the word “value” means nothing to me in this context.  The problem with RGB is – let’s say you get a really nice pink. That’s fine at full brilliance but how would you keep that shade of pink as you turn down the brilliance… even for a techy that is not easy faced with 3 sliders.   With HSV it’s a snap.

And so I’ve been looking at code – I found some great Javascript code and in fact I now have that running on my little WEBSOCKETS project – but what about C to put into the home control project… I found this after much searching. http://www.ruinelli.ch/rgb-to-hsv  Excellent code and simple to implement – do I put that into the ESP C compiler? NOPE – it needed a couple of includes that screwed everything else up because of the FLOOR function… so then I found this…

int inline fasterfloor( const float x ) { return x < 0 ? (int) x == x ? (int) x : (int) x -1 : (int) x; }

That solved the floor function and I was up and running.   H values 0-359, saturation 0-255 and brilliance 0-255.

Thinking about a display, a simple colour wheel with touch points along the way, then 2 sliders… that’s it - full intuitive colour touch control.

Well, it was enlightening for me – I hope you found this useful.

Facebooktwittergoogle_pluspinterestlinkedin