I’ve always had an interest in electronics and software, and in connecting the two together. I guess it started in my pre-teen years when I figured out I could use the cassette motor relay on my family’s BBC Micro to turn LEDs and buzzers on and off, and it grew as I learned to use the BBC’s 8 bit “user port” with more sophisticated electronics. I’ve used a variety of technologies and gadgets over the years, including various microcontrollers (PIC in particular) accessed via serial (RS232 or RS423), Elexol’s USBIO24 GPIO devices and, more recently, various Arduino and Raspberry Pi models. I’ve built a number of different things such as controls and displays for my flight simulator, computer control and feedback interfaces for my model railway, and miscellaneous gadgets of varying levels of utility. But until recently an area I’ve not explored is home automation – a topic well aligned with my experience and interests. That changed about 4 years ago when the problem of needing landlord permission to run cables and drill holes disappeared and I became a homeowner.
Like most people who venture into home automation my starting point (and mostly still the extent of my experience) was lighting. The automation of lights is both relatively straightforward and safe – there are no moving items under control of my software so no bug can lead to overheated motors or physical damage.
A decade ago I’d probably have started by buying a bunch of relays or triacs and working back from that (in fact I still have a device much like this that I fear to plug in) however I decided that it was time to leave the mains voltage to the professionals and concentrate on the low voltage stuff and the software. When I looked around for suitable hardware I was particularly impressed by the LightwaveRF range. The core of the range is a set of dimmers and relays in various form-factors including inline (which for the light switch types mean they need a leakage current through the lights to power them – something I’m not keen on) and plug-in units. All the dimmers and relays are controlled by 433MHz RF, either locally from handheld remotes or wall-mounted buttons, or via the network using an Ethernet to RF bridge (called a “Wi-Fi Link” despite having no Wi-Fi capability!).
The “Wi-Fi link” is designed to be used with LightwaveRF’s cloud service to enable control of the lights from mobile apps or via REST APIs. However, it can also be used directly by sending suitably formatted UDP packets to it.
When I first started using LightwaveRF my priority was to use the system to replace timer-based security lights simulating occupation while away from home. I initially started with Paul Clarke’s excellent “lightwaverf” tool which can drive the Wi-Fi Link from either command line invocations or from events in a Google calendar. I ran this tool on an early-model Raspberry Pi sitting in the cellar. I coupled this with an IFTTT recipe that runs daily and populates a dedicated Google calendar with a sunset event which was the basis for triggering the switching on of some of house lights.
This was all fine until Google withdrew the ability to share a calendar privately as an XML download. This was the motivation to build a more flexible system that would enable more use-cases for automatic light control (these will be the subject of future blogs). I looked at using Octoblu, an IoT automation platform acquired by Citrix. It didn’t have support for LightwaveRF but I did end up building a simple gateway to allow me to use the two technologies together. More importantly it was, at the time, not particularly stable (it’s much better now) so I ended up building a local MQTT-based system with a bunch of individual services connected via the MQTT broker (all running on the same Raspberry Pi as the previous system). One of these services is the LightwaveRF service which subscribes to messages about light controls and sends the appropriate UDP commands to the LightwaveRF Wi-Fi Link device (turns out there’s a NPM library for this). Another service is the calendar service which uses the Google calendar APIs to regularly pull down the same automation events as I was using with the previous system, but this time using my Google account and an API key, thus avoiding the problem of the missing private XML calendar. This service then issues lighting control command via messages published to the MQTT broker. By adopting the same calendar format as used previously I was able to continue to use the IFTTT recipe to populate the sunset events and enable/disable the security lights based on my travel plans
I’ve since added more services to the MQTT environment enabling more lighting automation use-cases – keep an eye out for more blog posts on these in the future.