So-called standards

An analyst reader contacted me asking for some information regarding home automation standards, and since I felt like having a bit of a rant, I thought I'd write my answer as a blog post.

This has again turned into a mammoth post, so reader discretion is advised, feel free to skip over any parts which bore you... heck, I'm don't even proof-read these posts because they're TLDR :o)

First, an analogy. This evening we watched a documentary made by the BBC called 'The Box That Changed Britain', and a very notable quote from it:

"It's kind of amazing to me to look at all these boxes here, and these were all designed by Keith Tantlinger, back in 1956, and they had patents for all these, and he convinced Malcolm McLean to give the patents to the industry. So that meant everybody could come in with the same twist-lock safe-guard, and it was an amazing system."

"By giving up his patents, McLean made it easier for rivals to copy his design, rather than come up with their own ones. This encouraged standardisation, meaning that today any container can be handled at any of the world's major ports, without any problems of compatibility"

Today, the reason why things are made worldwide, and why we can afford to have those things in our lives is because Malcolm McLean and Keith Tantlinger released their patents for a greater cause. The same needs to happen for Home Automation. Until we have a standard that isn't patent encumbered, and is cheap to replicate and produce, we will not have a 'standard'.

In my previous post I do mention them as 'standards', but the whole nature of a standard is that people adopt it as the specification to use when doing X, and none of the current 'standards' (hence the 's' in standards) have managed it.

We've seen the same thing happen in video and audio media in the past, and although the best standard on paper might not win every time (and hardly ever does), we desperately need this to happen in the home automation industry. The other industries which have fought over this have been in fierce markets, and the winner has been announced in a matter of a couple of years (unless they can live 'happily' in parallel, as with many audio formats), but the home automation industry doesn't have this luxury of a fast-paced cut-throat market, they're a niche, and until they recognise that they need to work together to get into the mainstream, I'm afraid the only home automation people are likely to buy are the cheap 'Standby Saver' type of products.

Where are the home automation standards going?

Every year at CES there seems to be a whole new set of hype around more home automation manufacturers, with even more pretty touchscreen control systems but they never seem to actually get anything to the market.

For now, I personally think it's a fight all of the manufacturers are losing, and if you read the 'homebrew' section later on there might be better alternatives coming from the open source community.

So which standard would I bet on?

The 'official' approach

Well, if you read my previous post you might think I'm routing for Z-Wave, but that wouldn't be the case. I chose Z-Wave because of it's ability to be a retrofit solution, since it's completely wireless, but from comments I understand that C-Bus and Rako both are able to be retrofit, and of course a hybrid hardwire/wireless solution would be ideal, to be able to 'go anywhere'.

Apart from the pricing, I would lean towards C-Bus, from the 'standards' I've looked into so far. They have nice-looking devices, and seem to have a good technical solution

Zigbee, used in Alert-Me's products, many energy monitors, and a lot of industrial use-cases, I would like to see more of it, but for the moment it's too proprietary for me to think about.

What I'm ultimately looking for is to be able to buy a light switch for <£10 and for the average homeowner to figure out how to fit and wire the faceplates and sockets without resorting to an electrician's help. None of the standards seem to be at that stage yet, especially on the pricing.

The homebrew approach

Since I'm a geek, and an occasional hacker, I like the idea of using standard networking for the communication channel.


The xPL Project is an interesting, but somewhat neglected (marketing-wise at least) project, which is creating a standard way to communicate about home automation controls, and building software for servers and nodes in order to connect devices. I haven't been able to look into it too much because I couldn't get it build easily, and the documentation was quite frankly rubbish, but that was a couple of years ago, so that might have changed, although looking at the latest post being from 2009 I doubt too much has changed, but the code repository is still very active.

The slight problem I see with this approach is that it hopes to connect *all* dispersed standards, so they don't have enough focus on getting people up and running with one particular set of hardware, which ultimately means a lot of customisation hassle, but I could be wrong.


On the hardware side, Arduino, an Open Source Hardware platform is here to the rescue. Being cheap and easy to build (My girlfriend and I have even soldered one together ourselves, of the Nanode variety), and coming in an amazing array of sizes and feature-sets for different purposes, from clothing-friendly versions, to ones with built-in networking, to others with radio transmitters.

I urge anyone with the slightest interest in making their own embedded electronics, to buy an Arduino and start sketching, you'll be amazed at what you could do.

This is also the platform Google chose as the avenue for the Android Open Accessory Development Kit (ADK), so there's a rather large community building up, if there wasn't already.


I know very little about MQTT, but basically it's a very lightweight protocol for machine-to-machine (M2M) communication, which includes queueing and retransmissions as standard. It's being used in Arduino projects, most notably the Nanode community, using it for energy monitoring, and over low-bandwidth radio frequencies for remote monitoring of weather, gardens, etc.

Data Stream Communities

Pachube, among others, are getting more popular, and the power of these services to do real-time analysis, complex event processing (CEP) and triggering remote events is really going to push the boundary of what home automation, energy, and environmental monitoring can enable.

Increasingly, it seams, these services are going to be provided by communications companies, possibly in partnership with energy providers, but ultimately the communication is going to be the deciding factor for a lot of these platforms... whether we can get telemetry data from vehicles cheaply and pervasively is in their power.


In short, I think the 'old boys' are risking being bypassed completely by entrepreneurial 'amateurs' if they don't start to reduce prices, geographic coverage, and increase the amount of devices/controls that are available in all markets outside the US.

Arduino and other low-cost Open Source Hardware solutions are going to start playing a strong role in turning the tides on the home automation scene with a community spirited approach.

Patents are the worst thing to happen to innovation, and luckily most of the latest projects to start know that being open will get them further than staying isolated and closed, but the old-fashioned corporations don't 'get it', as usual.

For installation and home design companies the current standards going to serve fine, with people/business that are able to afford the 'job lot' being catered for, but for the average home owner who just wants to turn a few lights on and off, spending a fortune on a couple of light switches is turning them to cheaper, crappier solutions.


Hi Duncan, interesting post. I'm part of the MQTT community so I thought I'd chip in to mention that it's currently in the process of being handed to a standards body. It's far wider than simply a home automation protocol - it has been in use for over a decade in industrial automation and networks. It's also very simple and as you noted, lightweight which has major advantages in both reducing the cost on the network, and reducing the need to do anything clever on the devices. You mention that you know very little about it, but it might be worth a look :-)
Friday 2 September 2011 17:18 | user icon Andy Piper
Thanks Andy. I actually first heard about MQTT at Oggcamp, which I think you attended too. It's certainly an interesting thing for me to look at. Something I wonder about the actual 'payload' data of various messaging systems is really how lightweight they are... There was SOAP, which was basically XML passed over a long-winded handshake, so not lightweight, and now REST and XMPP are more popular, with XMPP following a similar process to SOAP (XML with added signalling around it), and now JSON on top of REST makes that (putting aside the HTTP wrapper) a lightweight message format (compared to XML).

Of course if you know the data you're expecting you can use CSV format, which adds only 1 character per value, but in anything I make I like to be a little more flexible than that, so adding structure to the data is a must. It'll be interesting, after a little more research into MQTT, how it compares to REST on the messaging level, and ActiveMQ, et al on the queueing side, and whether it could even replace those for internal messaging in my projects.
Saturday 3 September 2011 13:26 | user icon Duncan Sample
Hi Duncan,

I think MQTT is regarded as lightweight because it's easy to implement and has a low message overhead. Publishing a message results in a command to the server of length 7 bytes plus the length of the topic you want to publish to, plus your actual payload.

The actual payload is whatever you want it to be, JSON or whatever, the server doesn't care.

"Putting aside the HTTP wrapper" is the key point. Assuming you want to send the same message regardless of the protocol you're using, HTTP has more overhead than MQTT.
Saturday 3 September 2011 20:58 | user icon Roger
I was indeed at OggCamp and I gave the MQTT talk there this year (slides and audio at, video available on the OggCamp Lanyrd / Blip.TV pages if you missed it on the Sunday). As Roger says, the point about the messaging vs protocol is important here. MQTT is just a transport - it doesn't care about the data one jot (well, apart from attempting to deliver it reliably, dependent on your selected Quality of Service). So, typically, that can make it a lot more lightweight than a bunch of HTTP POSTs etc that you'd typically do with REST/JSON interactions, or XMPP. As for ActiveMQ et al - well that's an interesting comparison too, and again I'd point to the fact that MQTT is built from the ground up for unreliable low-bandwidth networks whereas other "MQ-like" protocols are typically more enterprise and persistency-oriented.

In case you'd not come across it, there's a messaging event in London later this month - - MQTT, RabbitMQ and ZeroMQ - may be of interest. Totally free.
Saturday 3 September 2011 22:29 | user icon Andy Piper

If you don't have a Google+ account you can comment using the normal comment form below

About the author

Portrait of the author

On weekdays I'm a Senior Software Engineer at, having previously been a Solution Architect at Nokia & Nokia Siemens Networks, creating creative software solutions for mobile operators around the world.

In my spare time I'm an avid new technology fan, and constantly strive to find innovative uses for the new gadgets I manage to get my hands on. Most recently I've been investigating Mobile Codes, RFID and Home automation (mainly Z-Wave). With a keen eye for usability I'm attempting to create some cost-effective, DIY technology solutions which would rival even high-end retail products. The software I develop is usually released as Open Source.

I have a Finnish geek partner, so have begun the difficult task of learning Finnish.

Add me to your circles on Google+

The blog
September 2014
01 02 03 04 05 06 07
08 09 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 01 02 03 04 05

Zap the link below with your qrcode enabled mobile to send this page to it
Mobile Code for this page
What's this?