Category Archives: Internet of Things

New Provider

imageRegular readers will know that we've been having some capacity issues here at tech.scargill.net with our old provider “Unlimited Hosting” who turned out to be FAR from unlimited - and if you're reading this - we're now up and running with a new provider – Smart Hosting – not without teething problems but they’ve been REALLY helpful. Apologies if any of today's comments have been lost in the process, an unfortunate product of changing over. Hopefully now you should see a far more responsive site.  I’ve already seen comments coming in so it’s all working. The next time someone promises me an "unlimited hosting" service I'm going to be a lot more critical of that claim!

Facebooktwittergoogle_pluspinterestlinkedin

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…

Node-Red

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  https://www.facebook.com/esp8266wifi and if you have ideas for improvement – fire away – there are some great conversations in here.

Facebooktwittergoogle_pluspinterestlinkedin

ESP826 + Pi + MQTT + Node-Red Heaven

NetioIf you’ve been following the blog you’ll note I’ve spent a lot of time getting to grips with the Raspberry Pi, Node-Red, the ESP chips using C and of course my earlier home control attempts with NETIO, the NRF24L01 boards and Arduino clones (all of which are working 24/7 – I’m just getting more ambitious).

Well, it’s all starting to come together now. This morning I just put together all the pieces I’ve discussed earlier. On my workbench I have an ESP-01 based board controlling a mains light, I have the Pi with a couple of LEDs on it and I have an ESP-12 based board with some RGB LEDs and a MOSFET driving a PWM channel.

Now, I have to tell you that I’ve discovered something I’d rather not have… the PWM output is , it would seem, driven by software, NOT by hardware. I say that as I’ve realised that if I turn on the PWM output and then start fading RGB LEDs – there is some temporary interference to the PWM – and it is visible. It goes away when the RGB LEDs stop changing however.  This does suggest that it would be better not to run both at once – or indeed palm off the PWM to a serially-driven Arduino-Micro or similar from the serial output of the ESP..  I turn off the interrupts when handling RGB and this no doubt is the cause. It’s not a big deal, it’s just slightly annoying.

However I’ve now put NETIO in charge of this lot and I have to say it’s working a treat. Here is my current test screen on the Samsung S4. I was going to use the NETIO text input box but the author doesn’t seem to have finished this off as it looks awful (it works, it just looks awful) so I’ve missed that off for now.

You can see the S4 screen over on the right. The RGB wheel works a treat, the slider controls the PWM, the LEFT on-off buttons control the LEDs on the Pi, and one of the rightmost pairs controls the mains light on another board.  Node-Red acts as the arbitrator for this lot. TCP in from the NETIO app on the phone is sent through a function block in Node-Red in which I parse the incoming data and make sure I sent back the appropriate response. It’s trivial actually once you get familiar with Node-Red.  For now I’m storing the Pi Pin states in a database but ultimately I’ll store the lot. By and large I’m just sending a message back to NetIO and then sending off an MQTT message to the relevant device as dictated to by the NETIO message.

Node Red

 

var newMsg = { payload: msg.payload.trim() };
var myMsg=newMsg.payload.split("|");

if (myMsg[0]=="gpio") {    newMsg.payload=myMsg[2];
        switch (myMsg[1]) {
            case "0":

newMsg.topic="Update pins set gpio0=" + myMsg[2];
                context.global.gpio0=myMsg[2];
                return [newMsg,null,null,null,msg,null];
            case "1":
                newMsg.topic="Update pins set gpio1=" + myMsg[2];
                context.global.gpio1=myMsg[2];
                return [null,newMsg,null,null,msg,null];
            case "2":
                newMsg.topic="Update pins set gpio2=" + myMsg[2];
                context.global.gpio2=myMsg[2];
                return [null,null,newMsg,null,msg,null];
            case "3":
                newMsg.topic="Update pins set gpio3=" + myMsg[2];
             context.global.gpio3=myMsg[2];
              return [null,null,null,newMsg,msg,null];
        default: 
                return [null,null,null,null,msg,null];
        }
}   
else if (myMsg[0]=="gpio?")
    {
    switch (myMsg[1]) {   
        case "0":
              msg.payload=context.global.gpio0+"\n";
              return [null,null,null,null,msg,null];
        case "1":
              msg.payload=context.global.gpio1+"\n";
              return [null,null,null,null,msg,null];
        case "2":
              msg.payload=context.global.gpio2+"\n";
              return [null,null,null,null,msg,null];
        case "3":
              msg.payload=context.global.gpio3+"\n";
              return [null,null,null,null,msg,null];
     default: 
              return [null,null,null,null,msg,null];
        }   
    }

else if (myMsg[0]=="mqtt") // message and topic passed
    {
    msg.topic=myMsg[1];
    msg.payload=myMsg[2]+"\n";
     return [null,null,null,null,msg,msg];
    }

return [null,null,null,null,msg,null];

Facebooktwittergoogle_pluspinterestlinkedin