Pi 2 Pocket Control

Update July 2015:  Hard to believe it is months since I wrote this – anyway a few of you have had trouble with this so I’m making some changes.

Those of you who’ve been following my exploits for some time will know that initially I started using Arduino to control the home – typically I would use an Atmega 1284-based controller which in turn would talk via TCP/IP to my mobile phone and controls it’s own IO pins plus those of a number of simple Atmega 328-based boards (i.e. home-made customised Arduinos) via the hated NRF24L01 boards using a simple internal network.

I had this running in 3 buildings including heating and lighting. What I don’t like is having to go in and re-compile code every time I come up with a new idea for using the same inputs and outputs – and that’s where the new thinking with the Raspberry Pi2 and Node-Red is already starting to get me excited.

So that worked and all of that was fine except for the range of the NRF24L01 and the fact that they can’t listen and talk at the same time.

As for the network finding the best route – forget it as the NRF24L01 can’t even report signal strength. My next move was to be to start using 433Mhz based radios with spread spectrum etc. and that was coming along nicely when the ESP8266 devices turned up on the market. (All of this is documented in previous blogs if you’re interested in alternative routes to home control nirvana).

Don’t get me wrong, there’s nothing wrong with the home control setup I have using Arduinos – indeed this summer I will be spending the summer in Spain while the heating back home in the UK is controlled by an Arduino with just this kind of setup, I just want to move on to something more ambitious and with less compiling – especially when one of the rigs is on another continent!!

So the idea of using the Ethernet for everything appeals and that’s how I plan to proceed.

Shortly after the ESP8266s came about, the marvellous TuanPM MQTT library for these appeared and most of my earlier ideas went in the bin – this is just SO much a better way to do it. However there remains a problem….

If you want to roll your own as against using the rather restricted graphics (and somewhat steep learning curve) of the likes of OpenHab then there are not too many choices.

What I’d really like is for the designer of NETIO to get a move on and introduce MQTT – apparently that is in the works but don’t hold your breath and I’ve not found an equivalent for MQTT that is not attached to a particular system – so in the meantime I’m playing with TCP/IP and NETIO, which is what I use in the original system. NETIO lets you use any graphics you want and easily move it around the screen – it does have some issues however. If for example on your mobile phone,

You have a couple of buttons to turn a light on and off and an indicator to show the status, they are completely separate – and that means you need to poll the light (say every half second) so you get realistic feedback from the light. I don’t like the old X-10 method of simply ASSUMING the state of anything.

So some time ago I thought it would be useful to recreate what I have already but using Node-Red which fascinates me more and more, on the Raspberry Pi 2. 

I should stress right now that there are no security measures with this – which is why I wanted MQTT in the first place. In over 2 years I have had ZERO problems with this (read later comment)  but you are warned if you replicate what I’m doing here. You could of course also arrange some setup that as soon as your APP powers up it triggers a VPN which would give you some security. Actually, that’s not a bad idea.

The image you see above right is typical of the control screens on my phone, I can control heating and lighting etc. and monitor the status of all outputs, the temperature, humidity and more – all using NETIO on my Android phone (it is also available for IOS). The control has several pages and only the current page generates Internet traffic so it is easy to end up with a really complex setup.

In order to replicate this whole thing on the Pi using ESP8266 boards, I’ve put most of the pieces in place as you’ll see from previous blogs. But now to test TCP/IP control using a much simpler example. Over on the left we have a simple NETIO screen with  some buttons and labels – the latter will be the indicators – a pair of images  to show status off and on of GPIO pins on the Pi 2.  I’ll refer to this as the Pi from now on but I’m making no promises about the original Pi which I always assumed was too slow to bother with. I could be wrong.

So I press ON, the relevant LED comes on in the Pi, press OFF and that LED goes off – in addition, the indictor light on the APP reflects the true state of the LED.

Right now the NETIO app is using an external address using a port redirect on my router. I tend to insist on fixed port addresses from my service providers but you can easily get around that with services such as no-ip (DYNDNS) which are free if you don’t mind being harassed to update your details from time to time. remember – no security here so beware. As well as the host address and port – and protocol TCP/IP – I have EVENTBASED button ticked (add attribute if it is not there initially.

The NETIO setup is easy enough, you tell it you want to use TCP, you set the address of your Pi and the PORT number and for each button you define what it is going to spit out. Generally speaking the package would expect the reply to terminate in a new line – you can add a TINY amount of security though not much by adding a string of characters in there. It would not stop anyone getting in but might protect you against any random rubbish coming in (again I’ve not seen that since I started 2 years or more ago). Anyway you have to send SOMETHING back or the buttons just lock up.

On the right you’ll see a typical button setup.. when you press the button it sends “gpio|1|1” out via TCP to the Pi2, which then needs to send nothing more than a new line for acknowledgement. The text and the format is entirely arbitrary. Since I discovered the SPLIT function in JavaScript  I figured this was the way to go, sending vertical line delimited arguments. I have also done RGB control but to keep things simple I’ll not discuss that here.

So what I’ve defined so far is simple enough… gpio,0,1 turns light 0 (pin 11 on the Pi connector) on… gpio,0,0 turns it off. I’ll leave you to ponder what gpio,1,1 and gpio,1,0 might do (hint, pin 12).

In addition I wanted to monitor the state of the outputs so the message simple becomes gpio?|0,  gpio?|1 for the two respective pins.

And here I came across my first issue with Node-Red… once you set a Pi pin to output – I could not for the life of me figure out how to read state the state of the pin and the program chucked out objections when I treated it as an input – thankfully there is always the dreaded global variable and that’ll do the job nicely.

So this is a simple visually designed process in Node-Red. The TCP comes in – it is processed by a server-side JavaScript function in node-red – which then shoves out commands to the two ports (in the case of output, not status) – and replies to the TCP by using the original incoming message (so it knows where to send the reply).

The TCP in and out setup are trivial (double-click) so I won’t go into them (Node-Red doesn’t need any init or anything for the GPIO pins  -they just work) – the fact that the FUNCTION has multiple outputs may worry you – I didn’t even realise you could do this until a while ago – it’s simple. The function button in node-red can return a single argument – or many using an array – in the case of an array, you can define more than one output – and send the relevant array subscript automatically to the relevant output without a single line of code. You want to return a message to a single output, then it’s simply return msg; if you want to send to more than one output it’s return [msg1,msg2] etc.  If you only want to send anything to one of the outputs, make the others null. The guys who designed this were brilliant imho.

And so without further ado, here is my simple function that handles the lot!!.  Note that a context variable can be used over and over for the same function block. Sticking .global. in the middle means it will work across all blocks – I figured I might want this information elsewhere.

That function has 6  outputs. I’m controlling up to 4 ports and also I’m storing the state of the ports away when I change them into a MYSQL database, the result is that on power up I can now read that database and restore the outputs to their former glory.

and for initialising the ports on power up, a one-off trigger.. it doesn’t get any easier than this.

What is needed now – is a block to control and monitor an ESP-12 board and all it’s I/O over an MQTT link.  Later I mess around with TCP/IP sockets and my own graphics but it has to be said it is hard to beat NETIO for simplicity.

Have fun.