Monthly Archives: April 2015

The Raspberry Pi SD Wear Issue

Raspberry PiReading around the web it is easy to see that SD memory and lifespan are very poorly understood. There are conflicting explanations of lifespan, there are solutions which don’t work because someone didn’t actually test them before writing up … what a mess.

So here’s the deal. SD memory (the type you put in the PI to boot up) has limited write time – SO DOES USB MEMORY.

How long the microSD in your new Raspberry Pi2 will last is anyone’s guess and depends on “disk” activity, i.e. the number of WRITES (the number of READS is irrelevant).

So how to maximise this. It would seem that you CANNOT offload the whole thing to a hard drive.. but you can have the Pi boot up from the microSD – and then do everything ELSE on the hard drive. You cannot power the hard drive off the USB on the Pi as it does not provide enough juice – so you’d need a powered USB hub. This article looks good – I only got as far as transferring files externally so don’t ask me questions on it – but this seems to be one of the better explanations for using an external file storage.

Another way to improve the life of the SD and one that makes sense to me is a RAMDRIVE. That is instead of allowing the Pi to write constantly to log files on your Pi, have it read all log files into RAM at power up – write to the RAM and then on (intentional) power down, write back to the SD. RAM of course, you can write to forever without issue.

This kind of implies reliable power and I suggest you hunt out an uninterruptable supply – you can sometimes use those little phone charger supplies but I have found that some work, some don’t. The easy way, after backing up your Pi, is to try any one you have lying around. Plug power into the supply, plug the supply into the Pi. Watch the Pi on screen and test the keyboard or mouse. Repeatedly remove and reconnect the power to the supply – if the Pi works without any issue throughout this - then you’re probably onto a winner. I have 2 of them that work, 2 of them that don’t.

Ok, so there is a package called Ramlog which does the job of ensuring the logs are only written at power down. I followed two sets of instructions both of which failed part way through because the writer hadn’t actually tested what he was writing down, missing off a SUDO (super-user-do) command or similar. This explanation worked for me.

It would seem that SOME SD memory has something called “wear-levelling” in which the write use of blocks of memory in the chip are evened out so that continuously writing to one block ACTUALLY doesn’t happen as the wear is “spread” – sadly trying to find out how well this works and with which manufacturer’s chips it works – is something akin to dabbling in witchcraft. There is just so much rot out there so personally I’m not counting on it.

Oh and how do you tell if you’re reducing the number of writes – less or no flashing lights on your Pi.

I hope that helps. I’m coming to the conclusion that for long term use an external drive might be a good idea but I think I’ll wait a while until someone comes up with a package or batch file to make this nice and easy – meanwhile Ramlog seems like a good compromise.

About the only thing I did notice is that my SD usage according to WEBMIN before I installed Ramdisk was 3.5GB and after it was 7.10GFB but that’s clearly rubbish – it would be interesting to see it anyone else gets any “special effects”.


ESP8266 Test Board

I mentioned that Espressif were kind enough to send me a test board to play with – and very nice too. Not had time yet as I’m struggling with learning how to make an installer for my Node-Red package – with some great help from the guys involved with this….

So meanwhile here’s a lovely diagram – which I asked Espressif for specifically so you could see what the board does.

If you double-click on the image you will get a larger version. What’s really nice are the logical groupings. Not TOO keen on the tiny connectors on the right – but the main ones are 0.1” standard stuff. Quite looking forward to having a play.


ESP8266 Development Board


Slimmer Raspberry Pi 2

In the process this week of producing a new new Raspberry Pi2 with just the stuff I needed on it I thought I’d have a go at removing unnecessary programs from the Pi – that is the ones that come with it – after all the Debian installation from the NOOBS package is designed to please all.

I have not and never did have a use for the Wlfram engine but I had no idea how much room I’d save – was it even worth removing?


Between Wolfram-engine, minecraft-pi, scratch and sonic-pi I just saved 584 Mb. Now if you’re using an 8GB microSD that is a significant chunk! I’m using a 16GB but I’m still happy to gain that chunk back.


A Fresh Pi2 Start


The thing about rushing in with something new is that you tend to bring your learning mistakes with you.

Firstly for new readers, why am I fascinated with the Raspberry Pi? Well I’ve been working on IOT for some time now and I’ve tried out many ideas most of which you’ll see blogged about in here. I originally used an Atmel 1284 based solution of my own (own board, own software) to control a number of Atmega328-based boards by short range radio. Indeed right now I have 3 properties – two here in the Northeast and one in Spain which are using this successfully. But there were a lot of range issues with the radios and I was running out of steam with the 1284s and along came the ESP8266 chips… This opened up so many possibilities but I really needed something more powerful at the helm without spending more money (many have heard me say “I’m not spending £60 to switch a lightbulb”) – and in the nick of time along came the Raspberry Pi2 – which for £30 is a bargain even though you really have to learn just a little Linux to make good use of it.

The Raspberry Pi 2 was so new to me a matter of weeks ago (never had the original Pi) that I loaded the entire kitchen sink onto it. In anticipation that this might happen I bought a second Pi2. That gave me all sorts of issues, stalled keyboard, memory problems.. I w2as convinced it was the microSD chip… then I realised the other day that this could all be put down to a lousy power supply! I replaced that with something meaty and I’ve never looked back.  Mindful of the fact that my 32Gb microUSB drive for the first Pi2 was taking an hour or more to back up I went out and bought a Sandisk Extreme 16Gb and an Anker USB3 adaptor and that really made a difference – but still I was basing everything on a bloated software base. So this week I sat down and started from scratch.

You can save many, many megabytes by un-installing the rubbish that comes with the Pi2, that Wolfram thing which I cannot imagine any use for, the games etc. Having stripped the Pi down to essentials I then installed Webmin (and if you are not using this, why not?) – which by its nature needs PHP and MQSQL to run – and that’s fine as I have a use for both (graphing). When fitting the WIFI dongle to the board (who wants another wire) I realised I could do with the equivalent of the Windows WiFi properties window and stumbled on Conky – I’ll let you research that one. I then installed Mosquitto with some help from Mike at (and others) and finally with LOADS of help from the guys responsible for Node-Red, put that up (the installation is very different to my first attempt).

With all of that in place and all the latest updates (courtesy of Webmin) I’ve barely used over 3.5GB which is excellent because as time goes on the size of the microSD will start to shrink if nothing else because these devices have limited lives and the more expensive chips have intelligence on-board to move data around as parts of the chip die. I’m hoping to get several years of life out of this when I’m done so the more spare capacity the better.

So there we are, a clean start on which to build my ESP8266 and Arduino-based home control.


Presents from Espressif

envelope from EspressifLet me start by explaining that Espressif are makers of fine WIFI gadgets.. specifically they have spawned a whole new lease of life for IOT… by producing a marvellous little chip that contains a complete processor, memory and WIFI interface needing only a tiny FLASH memory chip and a couple of “bits and bobs” to make a complete working WIFI router, or IOT device or web server – largely limited to the imagination for, well, a couple of pounds ££…  the price is really what does it – you can buy a little board complete with aerial for less than £2 from China which is just a complete game changer.

Espressif packageAnd for everyone else, well, you know I’ve been working with these chips since day one and am just about to start fitting controllers all over the house etc. based on an overall setup that has been years in the formulation (in English lots of false starts) and currently comprises NETIO for the user control end (possibly soon to be replaced by ThingStudio if all goes well with their current alpha software), Node-Red and Mosquito on a Raspberry Pi2, controlling lots and lots of ESP8266-based boards around the place.

And so… with that in mind I’ve been in contact a number of times with Espressif and they’ve been helpful and keep me up to date. So the other day I received an email to say they were sending me some stuff to play with!  This morning, an envelope arrived in the post.

ESP8266 stuffInside a large cardboard box –  inside that, a package and inside that – a development board and some little modules.

The modules look like ESP-12s but have 2 less connectors – which means no A/D output !! They do have an internal aerial and are marked ESP-Vroom-02 and are “developer only.   The pin-out is not compatible with the ESP-12 which is slightly painful as that means a new rig to program them!  At some point it will be clear to me why they made these, leaving out the A/D – but for now it’s a mystery.

More interesting perhaps is the development board.  It is rather tempting to compare it to another development board that appeared on Ebay a short while ago.

Compare ESP


THe Espressif development board is much smaller and neater but contains a unit that has no less than 24 pins coming out – the most I’ve EVER seen. It does not unfortunately have an internal aerial so I’ll have to go and hunt out a suitable screw-in job. The board is marked ESP8266EX Demo Board and has more connectors than you can shake a stick to. It has an infra-red input, but micro-USB uart and general micro-USB inputs, 5 switches…

and that’s about it  - just got this in the post, thought you might like to see the stuff – not done any experimenting yet, no doubt that will follow soon.


Mosquitto and Web Sockets

This entry is about ThinkStudio (, Web Sockets and Mosquitto in my quest for ESP nirvana.

So TODAY I was alerted to an early version of a new service which I think you might like… so check out 

Clarification: This is ALPHA software but already, provided they keep at it I think this has the potential to replace the rather slow-moving NETIO app which provides a nice user interface for IOT. 

mqttThis software uses MQTT which is right up my street.

Well, always one for a challenge, I went to the site, set up an account and…. nothing – not a thing. I put in my MOSQUITTO (MQTT) credentials and got absolutely no-where apart from having a nice pretty interface. They have a nice pop up live help (pretty amazing for an alpha product) and before long I was happily chatting away to Michael Karliner. It turns out that the product needs MQTT to have Websocket support which my Mosquitto on the Raspberry Pi does not.  I’ve been putting it off because every explanation I’ve seen up to now involves compilers and all sorts of horrible things.

I was pointed to this link… which Michale had just completed - and in there is an article about installing Mosquitto with websockets. I was in one of those “devil may care” moods and so figured there was no reason why this could no upgrade my existing Mosquitto.

So I did – I followed the instructions from the start right up to but not including the bit about installing Node-Red as I’ve already done that.

WELL BLOW ME!!! it worked. Well… not quite. It over-wrote my mosquitto.conf file with a virgin one so now my security was bust and my local boards could not talk to anyone.

I opened the virgin mosquitto.conf which had everything commented out and added these lines as per the blog

listener 9001

protocol websockets

So now I could run a websocket on port 9001 (I tested that by redirecting the port on my external address then trying – worked a treat)

That allowed the websockets to work – on port 9001. But… my normal port would not work any more – 1883.. so I added this.

listener 1883

protocol mqtt

That got both pipes listening – all that was needed was to restore my user access.

allow_anonymous false

password_file /etc/mosquitto/passwords.txt

And Bob’s your uncle – the latest Mosquitto (which is just excellent) and now websockets.. which means I can write my own web pages to access MQTT if I want to!!! And no doubt I will – but if works out –  I might not have to. Ensure you are registered to get updates in here or follow my usual Twitter and Facebook accounts to make sure you don’t miss out – I have a hunch about this one.

Update: Oh I found another link with instructions for installing websockets – and a little info on the mosquitto.conf file…


The DTR Line and ESP

Hitting an issue with ECLIPSE on the PC and the TERMINAL program.

So in our little board we’re using an ATTINY85 to control the programming process for the ESP12s…  

I have some issues..

If you’re using GPIO as an output to a relay… this whole process can cause the relay to click… the last thing you want to do if you have a lamp or heating system on that output.

Keeping things simple with 5v relays you really need to use an NPN transistor so just basing stuff on the 3v line is out.

In the ECLIPSE programming environment when programming, DTR goes low as does RTS, then RTS goes high, then DTR goes high then you program the chip. You can control all of that in ESPTOOL.PY

In the TERMINAL program addon for Eclipse, opening the terminal causes DTR to go LOW, HIGH, and LOW and STAY LOW!!!!

So my thoughts are to buffer the GPIO output to the relay via the TINY. On powerup the TINY output to relay is LOW…

So if the TINY sees DTR go low, it would pull both DTR and RESET LOW… if DTR STAYS LOW for more than a second… GPIO-0 is floated (Tiny pin becomes input) then RESET is floated (tristate on the Tiny) and  from that point on the relay output follows the input from GPIO  until DTR goes high then low and we start again.

If on the other hand DTR goes low then high, we assume programming, release RESET first then GPIO-0…  then we wait for no serial activity for a couple of seconds before resetting again and then following GPIO-0….

Make sense? I can’t find any way to control DTR on that Terminal program so this is the best I can come up with for now…



Node-Red Scheduler

I’m Peter Scargill and this is a scheduler for Node-Red (well, more of a timer really but someone surely has already used the term timer) for Node-Red which includes days and months, dawn and dusk with optional offsets and a time-out mode, You may notice this has improved since the first version – I’m learning as I go along.

Please note: This program was replaced some time ago with bigtimer – there is no down side – bigtimer is better. See

As you may know, I’m interested in using Node-Red on the Raspberry Pi (though for this purpose it could be any piece of kit) to control ESP8266 boards via a variety of mechanisms, one of them being MQTT.

Up until recently I would use a Node-Red standard  Inject function to trigger an event, lets say once a day. The Trigger function however is very limited. It does not know about months and it has no idea about concepts such as “dusk” and “dawn” which you might reasonably want to use for a porch light.

SunriseSo, I buckled down and learned how Node-Red nodes were made (with some help later from dceejay Dave and others in the googlegroups node-red group – for which I’m grateful) – and the first thing I did was to start off with the sunrise/sunset node (you’ll need that installed as I rely on one of their routines) to send the time, date, sunrise and sunset information to my boards based on longitude and latitude. In essence, in my case I use MQTT to tell boards about the time when they power up and at 12 hour intervals and in the meantime they maintain their own time in software.

However the more I get into Node-Red the more I see it doing the actual control… so the next thing I did was to sit down and wrote a node – again borrowing from the Sunrise calculations for dusk and dawn settings but gutted to actually send one of two messages (settable) to a message topic (settable and suitable for passing onto an MQTT node for example) at any given time with presets for dusk and dawn and allowing control over days and months as well as a time-out function (i.e. turn on at 10am for 5 minutes).  So a typical example might allow us to turn something on every Wednesday at dusk until midnight but only from November to January. My node of course does not actually send an MQTT message – it just passed the topic and message onto the relevant node (the MQTT node shown in purple here). You could use that message for a variety of other purposes – like sending you a tweet at regular intervals. That is so easy in Node-Red.

The code handles summer time adjustments (well, it did this time, you might want to check that very carefully). You can even offset the dusk and dawn offset times in minutes to save, say, lighting energy, I find garden lights come on WAY before you need them – hence building in the offsets.

Here’s what it all looks like.


So every minute, my node (in blue) self-triggers  (my thanks to dcjay for showing me how to add JS timers) to do it’s calculations and decide whether or not to send a message to the MQTT output node in purple (you could easily alter the code to do something other than send an MQTT output. You will notice in the image above that there are now TWO outputs.. the top output sends a message on change – i.e. when it wants to turn something on or off.. the lower output sends a simple 1 or 0 message every minute regardless – think of it as a regular status output just like the little text and icon indicator under the node itself in the picture above. In this case each output is also sending out a debug message to the debug window in green – that’s just for testing purposes.

If you double-click on my scheduler node, here’s what you get…



Simple enough, give it a name (any name), on-time and off-time which includes every 15 minutes of the day and dusk and dawn dropdown options as well as timeout options for off time… then set your longitude and latitude (from Google Maps or memory if you are like that), the topic you want to send and the two messages – one to turn something on and another to turn something off. In my case I have an MQTT message system going to ESP8266 units – I’ve detailed this elsewhere in the blog.

Tick or un-tick boxes for the weekday/month combination you want. The code is checked once every minute but the top output only sends something out at power up or when the state changes.

If this isn’t powerful enough for you? – let’s say you want something to happen twice a day? – put two of them in there.

2 schedulers[4]

So – to make this work – i.e. to make your own node there are two files – and you just create a directory in your node-red/node-red-nodes folder called scheduler, dump these two files in and restart Node-Red.

The two files are the HTML file and the .JS file called scheduler.html and scheduler.js respectively.

If you make good use of this mode, a credit would be encourage me to support it.

Also if you spot any mistakes especially in the timing – or have ideas for improvement – do let me know.

The purpose for the timeout to the end time options – is so you can say for example – turn a sprinkler on every night for 5 minutes after dusk. And that’s exactly what I plan to use it for – but only in the summer months!

Attach for example an MQTT node onto the first output and put your broker details in there. The node will pick up the topic and message from my node.

And finally  – this code is deliberately NOT constantly sending out the ON instruction every minute but only when the state changes. At any time you can press the button on the left of the node to force an output of the currently relevant message.

Enough of this – here are the goods – no guarantee implied.

Some folk had issues reading the SOURCE CODE files – so I’ve put the files on Github here..

This node is relatively simple but I think that’s the point. It still took me several days to get it right and I’d appreciate any testing reports.  My next job is a thermostat node and that’s coming along nicely.

Make sure you sign up to the blog to be kept up to date or, if you prefer social media – there’s always  or


Making ESP8266 Programming Easier

Updated ESP-0109 Apr 2015 – code fix: A little something here from my guest writer and friend Aidan who’s been working with me on the latest home control successes to follow after this blog!

If you’ve successfully written and uploaded a piece of C code for the ESP8266 in any of its’ guises such as the ESP-01, ESP-03 or ESP-12 modules, then you must also be familiar with the process of holding GPIO0 low then applying a reset to get it into upload mode… it’s a PAIN IN THE REAR!!

If you’ve attempted anything more than a simple flashing light program for the ESP8266, then you have probably become frustrated or bored to tears with this process. This goes especially for anyone who is used to programming with the Arduino IDE, where programming the board is a as simple as pressing the upload sketch button. Well, weep no more, salvation is at hand in the shape of another Atmel processor, the TINY85. This chip is a few tens of pennies from Mouser, RS, Farnell or Ebay and we have used it to handle the programming pins for you.

The process is very simple. When you attempt to upload your complied C program using the Espressif SDK in Windows, or I guess Linux (not yet tried), then the DTR line on most FTDI USB to serial units will be pulsed low then high. This is normally used to reset an Arduino which goes into sketch upload mode for a second or two after reset, although you may not be aware of this once you’ve uploaded a sketch.

In our case, the DTR line is used to reset the TINY85, not the ESP module. When the DTR line goes high again, the TINY85 starts up and monitors the serial line coming from the FTDI. If you have started the program upload process using the Espressif SDKs Upload Tool, then it will be attempting to negotiate a connection with the ESP8266 bootloader and so there will be serial data being sent out.

As soon as the TINY85 sees this attempt to negotiate, it drops the GPIO0 line to zero and issues a reset to the ESP8266. Of course, as soon as the ESP8266 comes out of reset, it sees attempts by the ESPTOOL to communicate and the programming process starts.

The TINY85 continues to monitor the serial data stream and holds the rest line high and the GPIO0 line low until the data stream stops. At this point, GPIO0 is brought high and another reset is issued to the ESP8266. This then triggers the normal start-up process in the ESP8266 and your newly uploaded program runs.

Just to keep things tidy, we then turn the reset control and GPIO0 lines into inputs so that you can do whatever you want with them until the next power up or reset events occur.

The code for the TINY85 is shown below and the diagram of the ESP-DEV3 board is here. So, you can see how the lines are connected across between the TINY85 and the ESP8266 if you want to breadboard this. However, the ESP-DEV3 board has all of this already in place, and we’ve put a few other useful items on as well:-

  • Choice of a 10A relay or an optically isolated mains switch with switch terminals
  • DS18B20 or DHT22 temperature/humidity detector
  • LED Indicator
  • Footprints for three of the most popular mains to 5V power supplies to drop into the PCB – we regulate to 3.3V after this as these supplies can be a little bit noisy electrically.
  • A PCB button which we use for triggering a web setup process. If you hold the button down for about 10 seconds after power up, the ESP module generates a WiFi access point (AP) which you can then connect to using a phone, tablet or WIFI-enabled device capable  of viewing a web page. Using this you can also toggle the relay on and off, read the temperature, set the LED etc. We’ll be developing this theme more in the coming months. A really neat addition is the ability to setup a serial, WS2812 LED output.
  • All of the GPIO lines broken out to a 0.1” connector.

MUCH more on that in the NEXT blog entry. We have been mounting the ESP-12 module onto pins and putting the matching 2mm header sockets onto the ESP-DEV3 PCB so that you can just plug a module in and program it. Then it can be removed and added to another project.

If you want to program the TINY85 chip and you don’t have a programmer, then there are plenty of instructions out there on how to do it using an Arduino board.

So, no excuses then…

#define  F_CPU 1000000

#define RST_ESP 3
#define ESP_PROG 1

void setup()
digitalWrite(RST_ESP, 1); // Clear reset }

void loop()
unsigned long st = millis();

digitalWrite(ESP_PROG, 0); //  program mode digitalWrite(RST_ESP, 0); // Reset ESP module delay(200); digitalWrite(RST_ESP, 1); // Clear reset

//digitalWrite(ESP_PROG, 1); // program mode

st = millis();

for (;;)
    if (!digitalRead(SERIAL_MONITOR)) // Got any serial comms?
        st = millis();
    if (millis() > (st + 3000L))
        break; // Comms finished so exit


digitalWrite(ESP_PROG, 1); // Set ESP program pin high - not program mode digitalWrite(RST_ESP, 0); // Reset ESP module delay(200); digitalWrite(RST_ESP, 1); // Clear reset delay(200); // Slight delay to allow ESP module to see GPIO high at power up

pinMode(ESP_PROG, INPUT); // Allow the ESP pin to be used for other things by making the TINY85 pin an input pinMode(RST_ESP, INPUT); // Allow the ESP pin to be used for other things by making the TINY85 pin an input for (;;); // loop forever

For updates don’t forget if you’re a Facebook fan to follow updates on Facebook


And now… SMING Framework

As if the LAST announcement about an Arduino development environment wasn’t good enough (if you read my blog I acknowledged that the Arduino IDE was not as good as Eclipse) – there’s an ECLIPSE Arduino environment called Sming Open Source Framework.

They’ve not YEY gotten MQTT working apparently but there is so much stuff they have – it has to be worth following..  and here’s the rub – it is C++ as against C – and that suits me down to the ground!

So what do you get apart from normal Arduino stuff?

File system, EPROM support (again doctored as the ESP chips have FLASH), json library and again this is based on the 1.0 API so it’s bang up to date.

May battle commence.


An ESP8266 for Arduino Game Changer?

Arduino(updated 2/4/2015)

Here we go again – just as you thought it was safe to start coding, another game-changer comes along.

This time not only do we have an Arduino IDE for the ESP8266 (which isn’t a stunningly good IDE but it’s awfully familiar to many developers) but also what looks like Arduino library integration.

Do you remember way back in the distance when programming life was simple?

void setup() {
  // initialize digital pin 13 as an output.
  pinMode(13, OUTPUT);

void loop() {
  digitalWrite(13, HIGH);   // turn the LED on (HIGH is the voltage level)
            // wait for a second
  digitalWrite(13, LOW);    // turn the LED off by making the voltage LOW

Yes, that long ago.. well that was when programming Arduinos was a doodle, before we discovered the ESP8266-type boards and the unbelievably cryptic commands for port control.

Could all of that be about to change? I just STUMBLED on an article about programming the ES8266 in an Arduino environment. At first this sounded like a backward step, after all the IDE isn’t a patch on the Eclipse environment (IMHO). Anyway I thought I’d investigate. They’ve recently released a new version of the Arduino IDE so I downloaded that and started to investigate. I then found this link

It seems there are a small number of people involved in the development of this – Sandeem Minstry and ivan Grokhotkov – I hope I’ve not missed any names out – but I have to say WELL DONE CHAPS!!!.

In the link above there it seems some had some issues with installation or maybe wanted to use this new tool with their existing Arduino, so a fellow called Roger Clark made a variation – check out his link in the link above. I downloaded the rather large zip file – took out the folder within – and dumped it in the ARDUINO/HARDWARE folder in MY DOCUMENTS.  I restarted the Arduino IDE and went to change the programmer and the device and…

My God it’s Full of Stars

Yup, that worked. I took the standard blink sketch and changed the reference from pin 13 to pin 0 as I was about to test this on an ESP-01.

I can’t tell you how nervous I got as it came to pressing the compile button. I did – and it compiled in about 1 second flat. I put my programming link in, reset the board and…. VOILA – a working BLINK sketch.

But there is FAR MORE to it than this – APPARENTLY it will run the standard Arduino WIFI library – now I CANNOT confirm that as I’ve lost the example code – but if that works – then our struggles with making setup pages are over. And if the MQTT library for Arduino works – well – the SKY is the limit.  I’ve already tried analogWrite(0,128) and that doesn’t work so the NEXT thing is to find some documentation to discover what works and what does not. DELAY() works – at least, it works without setting off the watchdog timer – so those who like LOOPS with DELAYS might be in luck!! No guarantees whatsoever because if you are reading this for the first time, I am only one step ahead of you.

The power, memory and WIFI capacity of the ESP8266 with the vast collection of libraries for the Arduino…  I can tell you… I’m shaking already.

Please do come back with your experiences on this – let’s find out just what we can and what we cannot do with this great new opportunity.

First stop – LCD libraries – I have a GREAT little LCD 240*160 colour display I use for everything but there was no way to convert the library over to ESP8266 – is it even remotely possible I can get this to work in this new environment? The WIFI library works and apparently MQTT works along with simple web page serving – check this out -

Ok so here’s the original link… and instructions as to what works and what doesn’t. They’ve no cracked analogWrite yet but  serial DHT11, onewire, SPI, i2c master… the list goes on.

This just gets better… and better….


Home Control The Next Step

NETIO screenAs regular readers will know I’ve pretty much gotten to grips with the whole home control thing having after much research settled on a largely MQTT-based setup using the excellent new Raspberry Pi2 as a hub with Node-Red.

Though it could just as easily have been any proper Linux or Windows based setup, I could not justify in my own mind using an expensive piece of kit to do this as I’d previously been using an ATMEGA1284-based controller of my own design which cost just about nothing – but was constantly worrying about running out of resources on this – and then along came the Raspberry Pi 2.

Funny how things like that make a step change in how you do things and so it is again with the controller side of things – read on.

I’ve messed around with a number of solutions for the remote hand-held part of home control, ranging from simple infra-red controls, through radio, but always coming back to the not-too-well supported NETIO. I say that as it takes AGES to get changes made. The product costs very little, sits on Android or IOS phones and makes for a very pretty button-and-icon interface for home control – a LOT prettier than most of the other solutions out there and a lot easier to use – basically you move items around on a browser-based IDE, change properties and Bob’s your uncle.

The problem with this up to now has been the way NETIO handles the interface with your home control. It can use HTTP and UDP but I prefer to use a simple TCP interface. Up until now, each button or icon on NETIO would send a message and expect a response. So a button would send a message when pressed and simply need an acknowledgement.  An icon to say show the state of a light would regularly request updates and expect the status to come back. The problem with that was – if you expected a quick response when pressing a button you would be disappointed – imagine the icon requesting a response every half second in order to stay updated – and you had a dozen of them on screen at once-  that’s a lot of updating and on a poor connection this was disappointing.

Until now there was no way for a button to talk to it’s own separate icon. That has now all changed. NETIO now features event-driven operations, that is the home control system once the TCP connection is made, can arbitrarily send a message to the phone and to one or more icons at the same time. Each icon is now responsible for checking to see if a message is for it.. and that is done with a simple regular expression.

Trust me – this is a major step forward for this program – as it enables almost instant feedback – rather handy if you’re not in line of sight of the item.

Ok this all sounds really painful but it isn’t.

If you take a look at my picture above – one of my test pages, there are a bunch of on-off buttons and indicators.. The indicators need to do two things… at power up they need to poll the state of whatever it is you are controlling – that is so as to set their initial state. From there on they need to be watching out for messages which could come at any time. Each one must have something unique so so to identify it.

NET Control

On the NETIO control page here on the left you will see there is a READ instruction – that is to read in this case the state of the GPIO control on the Raspberry Pi2.  I’ve adopted the vertical line as a separator. So gpio?|0 sends off a string to the Pi which is picked up by Node-Red and sent to a function, which then returns (let’s say the light state is 1) status1=1

The parseResponse field will only do anything if the incoming string contains “status1=” and then pulls out the value to determine which of two images to use for on or off. The point here being that not only can this icon request the status – but any other event can return status1=1 and affect the icon, so you get a one-off refresh on power up and then whenever you change the state of a button, a message is sent from the Pi to the phone to change the state of the icon, in most cases instantly – no more polling.

And there you have it – the ability now to have WAY more icons than before on a page without ridiculous amounts of polling – If ONLY the NETIO author would do this via MQTT it would be SO good but for now this is just about the easiest interface out there without the limits of some predefined program. There are plenty of icons in NETIO and you can add your own images at any time.

At the Node-Red end…


There is an incoming TCP connection from the mobile phone, that data is processed in a simple function (and in the case of the simple local IO pins I store the outputs in a database but that’s not relevant here, nor is the MQTT output) the outputs are controlled as requested and also a TCP reply is sent back out to the phone. In the case of queries, no outputs are modified, the state of the outputs is picked up from global variables and send off to the TCP output…. a simple string.

House-building is commencing in the new cottage – the electrician is putting in my networking cable and ensuring I have a wire coming from most lights etc. to offer an over-ride function to normal manual control – once our boards turn up they will be pressed into service using a vastly expanded version of what you see above. It is all coming together.

If you want to keep up, subscribe to this page – or subscribe to my Facebook page and if you have ideas for improvement – fire away – there are some great conversations in here.