Logging the Lights in Your Home

It’s all the rage these days under the general heading of “Internet of Things” (IoT), but I have been a home automation enthusiast for more than 10 years now. In the interceding time, I’ve done experiments and written about the subject. I even published a Pluralsight course, in which I turned a Raspberry Pi into a RESTful server that lets you turn lights in your house on and off using basic X10 technology. You can certainly say I have a lot of experience, both with newer techs and comparably archaic ones.

Because I’ve been in the game so long, you might think that I’m a strict constructionist, if you will, wanting to build everything myself from raw parts. But I’m not. Even though I enjoy assembling these systems from their components, I am a fan of the strides made by various vendors over the years, and I’m thrilled to see different players enter the space and expand home automation mind share in the general public. In fact, I’m excited as a technologist that I can leverage already-assembled techs and services to achieve my home automation goals.

Introducing Wink

Against this backdrop, my mom recently gave me a Wink hub and companion lights for my birthday. Wink is a service that does what I once quixotically sought to do in my spare time on weekends: It unifies disparate smart devices to allow centralized control over them. The hub is synced with the Wink service in general, allowing control from anywhere, and the hub communicates with the satellite devices over house Wi-Fi. I can now turn on a couple of lights from anywhere in the world with the workflow occurring as follows:

1. I pop out my phone while vacationing somewhere sunny, open the Wink app, and tell it to turn on my master bedroom light.
2. The Wink app phones home to the wink servers, communicating this request.
3. The Wink servers pass the message on to my connected Wink hub at home.
4. The Wink hub relays the message over Wi-Fi to the light, which turns on.

It’s really pretty slick.  It also causes me a wry smile of amusement, as I just got a birthday gift that does out of the box something I worked for months to make happen. But then I trade that smile for a genuine one when I think about how much more I can do in this landscape.

Incorporating Other Tools

What I’m talking about here, specifically, is how I can easily leverage other technologies in a way that my home-grown solution of 2006 would never have been able to. For the purposes of this post, let’s say that I decided I wanted to have a globally accessible log of the activities of all of my lights and that I wanted to receive notifications (but not too many) if a light came on in the middle of the day when it wasn’t needed.

In 2006, there’s no doubt about it — this would have meant all home-rolled logic. Pre-cloud, I would probably have needed to buy hosting, have my home automation setup send secure messages to it, and implement logic to let me view the resultant logs. I’d then have needed to put custom logic on that same server to dispatch emails. That’d have more or less been my only option.

In 2016, on the other hand, there is an embarrassment of options: cloud services, IFTTT, the capabilities of Wink itself, and more. But, for argument’s sake, let’s say that I have a Logentries account and that I already use it for my logging needs. It makes sense for me to simply add this as another source of data. Let’s see what that looks like.

A Quick and Dirty Solution

Let’s say that I didn’t want to figure out all of the particulars of cloud offerings and that I had no access to a public server. Limiting as this may seem in 2016, I can nevertheless achieve my goal in a few minutes using Visual Studio and a Windows 10 machine. That, at least, gets my lights up, running, logging, and emailing right now while I search for more elegant solutions later. Here’s what that looks like.

First things first. I created a new Visual Studio Console application and installed the following Nuget packages.

1. Logentries Log4Net plugin/appender.
2. RestSharp
3. Json.NET

With those packages in place, the amount of code necessary to accomplish this is shockingly minimal.

class Program { 
    private static readonly ILog _logger = LogManager.GetLogger(typeof(Program).FullName); 
    static void Main(string[] args) { 
        var winkClient = new RestClient("https://api.wink.com/"); 
        var request = new RestRequest("light_bulbs/1234", Method.GET); 
        request.AddHeader("Authorization", $"Bearer {ConfigurationManager.AppSettings["token"]}"); 
        var response = winkClient.Execute(request); var content = response.Content; dynamic root = JObject.Parse(content); 
        _logger.Info($"Brightness is {root.data.last_reading.brightness}"); 
    } 
}

There are a few things to note here. First, the URL route for the light bulb “1234” is not actually a lightbulb — it's just an example. It is a numerical identifier, but that identifier is not valid so as not to offer up an actual person’s light. Though, even if we did that, it isn’t as though you would be able to access it because of the other concern here: the configuration manager’s “token” setting. This corresponds to a token that you, as a Wink User, are issued along with your account. I put this in app.config because, as you can probably understand, I have no more interest in sharing my token than one of my lights.

To get going with Wink, you should first read up a bit on the Wink API.  That’s where you will find documentation on these REST calls, and you can acquire your token by logging into the Wink at Home website.

But the rest of this code is all something that will work verbatim. A handful of lines of code to compose the request to Wink, issue it, and then unpack it to find the “brightness” property of the light. If you were to repeat this for all of the lights in your house, you would have the code needed for the logging portion of what I mentioned. Of course, you would also need to create a schedule task on the desktop or implement a service to have this code constantly polling, but this is quite easy to accomplish.

On the Logentries server side, the other component of this solution is straightforward. I’ve blogged before about creating Alerts in Logentries. To achieve the email component, you would simply need to set an alert based on the time stamp of the entry (daytime) and the value of brightness being greater than 0.

What’s The Broader Point?

It’s obviously cool to be able to use a cloud-based logging service to log the goings-on in your house, but what’s the broader significance here? As someone coming from a heavily DIY background and later embracing the time-saving value of tools, I’d say the broader significance is that we live in an increasingly interconnected modular development world. API authors are taking more and more care to allow you to interact with their software on their terms.

This means that it’s increasingly likely you can leverage the tools with which you’re proficient to do cool new things — like using Logentries to monitor your lights.