Manoj's Blog: Making my home smarter...

Anyone had this idea about building a cloud application for controlling some of your home appliances over web or mobile? Well… here’s something that might interest you.

Taking a look back at my own university dissertation 15 years ago which was about home automation using power line communication, just wanted to build something useful to make my home a little bit smarter :-). At a minimum, I wanted to build an application to control some of the home appliances (i.e. lighting systems, various switches, etc) over web and mobile and use analytics on the statistical data so that I could measure things like power consumption, fluctuations, etc. whilst I am away from home.

What about Hardware?

15 years ago, although it wasn't called as Internet of things (IoT), there was a bit of hype about integrating appliances to a common control platform. At that time, X-10 was one such technology that came out in the market for sending device control instructions over the electricity grid so that you didn't have to wire up a separate control network for passing instructions. What about WiFi?.... well that wasn't even heard of those days, so being able to use the same electricity grid for both power distribution as well as for sending device control instructions was a pretty cool though (reliability aside :-) ). However, none of these technologies had a strong emphasis on leveraging internet as a standard option for remote connectivity, simply for the reason of dedicated Internet was a luxury home users didn't have. Setting up an appliance control infrastructure over highly unreliable dial-up connectivity was not at all a feasible option; hence the peripheries were usually restricted to a closed solution that required a certain control device be wired up to the serial port of a PC for sending out instructions to the power grid.

15 years later, it certainly doesn't look like as X-10 has picked up much momentum on retail appliance control space, but if you search on eBay, you would surely find a number of alternatives that can interface with your home appliances through some sort of a controller device. By the way, don’t be too excited when I say ‘control your appliances’, but at a minimum what I mean is that these technologies currently have the ability to switch on/off your appliances and control the electricity flow (and measure power consumption too).

If you are really interested, take a look at [1] for such hardware you can use here. Again, my intention here was to build a common API layer that should be ‘interfaceable’ for various hardware devices as long as they provide ways to a.] query topology (i.e. device registrations), b.] pass control instructions to each connected device separately, and c.] query for device’s current state as and when required.

Architecture

Following is a quick sketch of what I wanted to implement. For client (a Java agent running on a Raspberry Pi) to server side interfacing, MQTT [2] was somewhat an easy choice to make, given that it’s lightweight and have been designed with interoperability in mind and it fits nicely for low-bandwidth connectivity specifically for IoT use cases. I am still learning about this protocol by the way, but for what I could gather so far, it seems to have some nice features for persistence, connection recovery, etc.

The primary task of the agent is to collect various messages (topology, status) from the appliance controller and publish them to the broker whist collecting instructions from the server side and pass them on to the appliance controller. Obviously both these tasks would require the Java agent to transform these in/out messages specific to both parties. So, if there is a new set of devices I would need to interface with in the future, I will only have to implement the messaging interfaces I have defined (hopefully :-)… umm… may be I should test it out with a different set of hardware now).

Appliance statistics that gets periodically collected by the java agent and published on to the broker will be dumped in a big data store at the server side. I used MongoDB [3] for this, not for any specific reason, but I like its JSON based querying API as well as its pretty fast aggregation framework [4]. At this point, I haven’t made use of any big data analytics product out there, but I could write some code to extract average power consumptions, etc and couple it to a couple of cool JQuery/highcharts graphs.

In case if anyone’s interested of the technologies and frameworks I’ve used for this, here’s a quick summary.

Web App

Implemented using ASP MVC.NET. Used twitter bootstrap + JQuery to make the UI responsive. Highcharts provided the functionality I needed for those charting components (i.e. data range zooming, etc.). Most of the UI functions are bound to Ajax calls making the user experience much nicer.

Broker

Mosquitto [5] was my choice. Actually, this is the first time I used this MQTT broker, hence I may not be the ideal guy to answer all your technical queries related to this (at least not yet :-)).

Paho (which is an eclipse project now) provided me the client libraries I need from both the Java side (Raspberry Pi) and .NET server side [6].

Agent running on Raspberry Pi

This is a lightweight Java application that coordinates messaging between the broker and the hardware. It does involve quite a bit of message transformations and for the hardware I used, I could use the apache HttpClient libraries to send post HTTP requests and also query for status info which I could use to extract the topology info as well as statistical data.