Category Archives: WIFI

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

Onion Omega

You (probably) saw it here first…  I thought I’d seen it all in the ESP8266 but this is looking impressive already. Yes, that IS a complete WIFI controller with Linux  and plenty of RAM in a matchbox. Early days, I should have one to test in a matter of weeks so be sure to look in here… I’ll likely do a short video on the subject. And yes as best I can tell that is also 0.1” pin centres. With an extension it also handles wired Internet though by the time you start putting extra bits on my guess is it would be competing with the new Raspberry Pi. On it’s own however I think this one might just have wings! More when I get my hands on some hardware.

Onion Omega

Facebooktwittergoogle_pluspinterestlinkedin

ESP8266 and MQTT Exciting Times

I don’t want to jump in prematurely here but those of you who have been reading the blog will know that I’ve had no end of problems with the MQTT stand-alone software on the ESP8266, but as each problem has emerged, the author (Minh Tuan) has been keeping in touch and working with me.  

MQTTLast week having apparently gotten everything working (that’s a real project continuously firing out temperature, responding to incoming time correction signals and accepting commands to turn GPIO0 on and off,  connected to a solid state relay controlling a lamp) when I realised that one of the real-life tests I’d missed out was … what happens if the broadband went off.

To my horror, it resulted in absolute failure.  The software would not reliably reconnect. I had some great suggestions from people – including one to think outside of the box, could it possibly be the MQTT broker not reconnecting properly. I worked on everyone’s suggestions to no avail.  I even updated my development environment (Windows 8 with Eclipse) to the latest SDK + patch (0.9.5) – no difference.  I can’t tell you now many evening hours I spent on this.

ESP-01Then this morning I had a contact from Minh to say he’d sorted the problem. I downloaded the code – and tested it – turned the WIFI off for a few seconds – turned it back on – HURRAY, reconnect no problem, re-subscribe no problem, queued outputs sent no problem. I was just about  to report success when I thought I’d see what happened if I left the WIFI off long enough to fill/overflow the queue (there is a RAM queue for messages and it includes incoming subscribes and outgoing messages, I had a hunch that a full queue might stop re-subscribes). Sure enough… the grim news on leaving the WIFI off for several minutes and reconnecting was that the software started up again – but all subscribes were lost – no room for them.

Thankfully Minh was around and immediately spotted this – we agreed that if the queue filled up completely and the WIFI restarted, the queue would be SCRAPPED.  Ok there are better ways and I’ve asked him to look at this – but for a quick fix he sent me a replacement mqtt.c file and… I put it to the test.

MQTT[6]3 hours later I cannot crash the software. No matter how long the WIFI is off it always reconnects properly. Some earlier strange issues on power up have disappeared (I feared they might be my own non-volatile variable storage additions.. but no).

The library has been updated accordingly just minutes ago and is here https://github.com/tuanpmt/esp_mqtt.

You really should take a look at this. For the first time we potentially have the means to make an ultra-reliable control system with the ESP8266 boards. Recent mods to the code free up RAM (an issue for example with the Lua software) and so I have no doubt there is lots of room in there to add your own bits.

To recap for those who’re looking in for the first time, anything I refer to here will be covered in other blog pages – but I’m using MOSQUITTO – in my case running on a Diskstation NAS Drive for reliability but it will also run on various platforms and there are servers out there for people to use as well. I’m testing this with the excellent MQTT-SPY and all of this without having learn a word of Linux Smile  thanks to the excellent feedback I’ve had on this blog and the work of others around the world who like me are so keen to get this working.  If all goes well I can now concentrate on mastering the likes of Openhab so that once I have boards in place controlling stuff, I can easily monitor and control the boards themselves from a mobile phone – and for the first time with a little security in place – the point of investigating MQTT in the first place!

phpIncidentally, the PHP page I use under CRON to push the time out to my MQTT broker – I had some fun with that as I realised it was pushing out rubbish (wrong time) and further to a PHP upgrade at my provider – was throwing in warning messages to boot. Here is the latest working version (been up there running 24/7 for a week now) with security information altered to protect the innocent. To keep things simply, the dawn and dusk information is only accurate to the nearest minute. That lowers the number of times it will be updated and as I keep this in FLASH, the number of times the FLASH is updated.

<?php
error_reporting(E_ALL ^ E_NOTICE);
require("../phpMQTT.php");

function varcheck($var, $default)
{
return isset($var) ? stripslashes($var) : $default;
}

$locn = varcheck($_GET[‘loc’], "Europe/London");
$lon = varcheck($_GET[‘lon’], 55);
$lat = varcheck($_GET[‘lat’], -2);

date_default_timezone_set($locn);   
$dateTimeZoneLocal = new DateTimeZone($locn);
$dateTimeLocal = new DateTime("now", $dateTimeZoneLocal);
$localDateTime = date("H:i:s d-m-Y", time());
$localDisplayDateTime = date("H:i l d-m-Y", time());
$localTime=strtotime($localDateTime);

$mqtt = new phpMQTT("your.mqtt.server", 1884, "whateverYouLike");
if ($mqtt->connect(TRUE,NULL,"yourwifilogin","yourwifipass")) {   
            $mqtt->publish("time",$localTime,0);
            $mqtt->publish("timestring",$localDisplayDateTime,0);
            $sun_info = date_sun_info($localTime, $lon, $lat);
            foreach ($sun_info as $key => $val) {
                if ($key=='civil_twilight_end') $mqtt->publish("dusk",(int)(($val %86400)/60),0);
                if ($key=='civil_twilight_begin') $mqtt->publish("dawn",(int)(($val %86400)/60),0);
            }
    $mqtt->close();
}
?>

Hopefully now I can stop worrying about reliability and start having some fun. I have suggestions for better ways to store things in FLASH and there is much to learn about Node-Red, OpenHab and much more so this is really just the beginning.

Facebooktwittergoogle_pluspinterestlinkedin