Home Automation - Controlling Devices
One of the most important, if not the most important part of a home automation system is being able to actually control devices. This may be turning on heater or a light or perhaps even opening a window.
One of the challenging issues here is working out how best to communicate with the various hardware devices. A single common format is the ideal but this means the hardware has to be either the same or designed to fit which may be difficult to achieve.
Switching mains devices
For my project I started with what I had, a Belkin wemo switch. This is a wifi connected plugin mains adapter which allows devices to be controlled from their mobile app or crucially ifttt. Using a simple ifttt rule I paired the wemo switch with a rest endpoint allowing me to turn on and off devices by sending a post request to a specific url.
This was a great start and allowed me to get a couple of mains devices up and running in no time. I created a database table to hold a generic object called a device, this was where I kept the urls that needed to be hit to control it along with the room the device belonged to and the type of device. It also stored the desired value of the device, on/off or in the case of lighting the brightness or colour.
I am a big fan of queues and background processes for isolating systems and reducing the impact of failures so I set up the the user interface to update the the device state in the database rather than trying to control anything physical. I then setup a separate sync process which looped over all of the devices every minute and send the relevant on or off commands, this ensured the devices reflected what was wanted in the database. This had the odd effect of meaning you couldn't control any of the devices directly, if you tried to turn something on or off the sync process would quickly put it back to what it was in the database.
Events to the rescue
This system worked well for a day but not having a device respond immediately to your command gets annoying, I ended up changing it slightly so that when a devices is updated it changes the database and then broadcasts an update event. This event lands in the queue and gets processed quickly but still separates the user interface from the actual device control. I still have a delay of a few seconds as the queue gets checked for jobs and then it gets processed but it responds quick enough for the action to feel like its connected to the UI update. The sync job still runs but at a much longer interval and operates more as a backup to keep things in check.
The next device I added was something a bit more custom yet remarkably simple. I setup a strip of WS2812 led's and connected these to a Photon from Particle. I then used their public function control to setup a url that I could call with a series of parameters, these would then get parsed and used to control the brightness and colour of the led strip. This worked nicely and I ended up adding a couple of sliders to the web app to control the brightness, hue and saturation of the light.
Hopefully the simple system I came up with should be capable of working with most future devices, providing they can be controlled through an endpoint of some kind.