About this blog

Entries in this blog

The newest version of Hobson, 0.10.0, is now publicly available. There are a lot of changes in this release including:

Added "Home" and "Away" modes to the hub.

Added WebSockets support so web UI updates are immediate rather than delayed by 5 seconds.

Added support for long-running, complex plugin and device actions.

Added ability to disable tasks.

Added support for manually deleting existing devices.

Created new plugin for Pushover notification service.

The Hobson runtime now persists meta-data about all published devices so plugins can obtain device information even if the device hardware is unavailable (e.g. sleeping nodes).

Hub authentication and authorization are now managed by an independent plugin. This allows third parties to create custom plugins to support different identity stores and authorization implementations.

Added device tagging API endpoints.

Simplified event subscription model for plugins.

Improvements to OpenID Connect implementation.

Improvements to plugin and device configuration validation.

Improvements to device availability tracking and reporting.

REST API documentation is now in Swagger format and can be accessed directly from the Hub.

The upcoming Hobson 0.10.0 has a lot of new features including real-time web socket support, arbitrary plugin & device actions, hooks that allow users to manually add plugin devices and runtime device meta-data persistence. Undoubtedly, with a lot of changes comes a lot of testing. Since a lot of Hobson's recent changes were to support sensor use cases, it made sense to perform testing using sensor devices. The question became what kind of sensors to use?

I was turned onto the MySensors project by a Hobson user and have been very impressed with it. I was able to quickly build an Arduino-based sensor gateway and a couple of basic sensors very inexpensively and quickly. Furthermore, I was able to write a MySensors serial controller plugin for Hobson quickly and painlessly which both confirmed that the MySensors ease-of-use claims were true and that the recent slew of Hobson API changes were taking things in the right direction.

It's safe to say that Hobson 0.10.0 has taken longer than expected but I think the changes are excellent and will help the platform to grow. Look for it and the Hobson MySensors plugin in the coming weeks.

The Amazon Echo speaker and accompanying Alexa voice assistant were released in November 2014 to much acclaim. It's one of those devices that takes a number of existing technologies and combines them into something that feels magical. If you've ever jealously watched the Star Trek crew interact with their computer via voice commands, you know what I'm talking about. The Echo gets us closer to that than anything that has come before.

However, this article is not about the impressiveness of the Echo nor the privacy concerns that its approach to cloud-based voice recognition creates. This article is about what's involved in developing IoT applications for the Echo - called "skills" in Amazon parlance.

Cloud-to-Cloud Architecture

Let's start with one significant limitation - for the most part, Echo skills use a cloud-to-cloud integration architecture. This means that your custom skill will need to be exposed via an Internet-accessible endpoint with all the security concerns that implies. This is a significant impediment to the Echo becoming a true IoT hub device since you can't talk to local devices directly.

The basic model is:

You send a voice command to your Echo.

The Echo sends the captured audio to the Amazon cloud to perform voice recognition.

The Amazon cloud associates the voice command with a custom skill and invokes a custom HTTPS endpoint or AWS Lambda function (depending on how you've configured your skill).

Your custom code processes the request and responds with a success or failure (including what the Echo should say to the user in response).

It's worth noting that this approach does not appear to be driven by technical limitations of the Echo hardware - other companies have created skills that can communicate with local Wi-Fi devices (Philips Hue lights being a notable example). So the capability exists but is not currently part of a public API. So unless your company is at the scale of Philips, cloud-to-cloud is currently the only way to go. I can't say this limitation is surprising given Amazon's position as the leading cloud provider.

Smart Home vs. Custom Skills

An Echo skill has what is called an "interaction model". The interaction model defines how you map voice utterances to commands - called "intents" in Amazon parlance. There are two types of skills you can create: "smart home" or "custom".

A smart home skill has a pre-defined interaction model that currently knows how to deal with lights and thermostats (Amazon says more device types will be implemented in the future). If your skill only needs to interact with those two types of hardware, you're good to go. From a user interaction perspective, a smart home skill facilitates searching for controllable devices in the Amazon Alexa app and identifying the ones the Echo will control. Voice control becomes a simple matter of the user saying things like "Alexa, turn on the kitchen light". Because the user explicitly set it up in the Alexa app, the Echo knows that "kitchen light" requests are serviced by your smart home skill.

A custom skill is much more flexible. Among other things, it defines both an "invocation name" and a custom interaction model. The invocation name is used by Amazon to identify the appropriate skill to route voice commands to. The drawback here is that the voice command becomes a bit more wordy. Instead of "Alexa, turn on kitchen light" the user will need to say "Alexa, tell Hobson to turn on kitchen light" where "Hobson" is the invocation name. The custom interaction model requires you to think through every variation of how a user might say a command and include it in your skill definition. It's a tedious process but a worthwhile price to pay if you need more capability than a smart home skill can provide.

According to Amazon, you can also take a hybrid approach using a smart home skill to take care of lights & thermostats and a separate custom skill to take care of everything else.

Integration

I mentioned earlier that there are currently two choices when integrating your custom skill code with the Echo -- an HTTPS endpoint or an AWS Lambda function. Essentially, when AWS processes a voice request, it uses the skill's interaction model to convert the speech into a JSON document that describes what the user is trying to do - the "intent request".

If you take the custom HTTPS endpoint approach, the Amazon cloud will post the intent request to your custom URL. That URL will need to know how to directly process Alexa intent requests and provide the appropriate JSON response.

If you take the AWS Lambda approach, the Amazon cloud will automatically invoke a custom Lambda function you define with the intent request. That function can, in turn, service the request itself, make a request to your API, etc. I tend to view the Lambda approach as a way to create a lightweight bridge that converts Echo-specific requests into custom API requests and converts custom API responses into Echo-specific responses.

Account Linking

It's a good assumption (I hope) that IoT service providers don't have unprotected URL endpoints sitting around. Most likely there will be some form of authentication required to invoke those endpoints and incoming API requests are generally associated with a specific user. How then do you map an incoming Echo request (associated with an Amazon user) to a user in your system? This is where account linking comes in.

First off, account linking assumes that your API is OpenID Connect (OIDC) enabled - specifically that it supports the "Authorization Code" or "Implicit" grant types (Smart Home skills currently only support Authorization Code). If you meet that requirement, a user can use the Amazon Alexa app to perform an OIDC login to your identity provider and the Amazon cloud will retain the necessary tokens to include in intent requests that it sends to your endpoint or Lambda function. It should also handle using a refresh token to renew access tokens where necessary.

Developer Support

This is the one area where Amazon seems to be struggling. When things go wrong, it's not always easy to tell what is happening and Amazon's tools that allow developers to troubleshoot problems directly are sorely lacking. That leaves you in the hands of the Alexa developer support staff to help you through certain problems. My experience in this area has been awful.

For example, I opened a support ticket with Amazon 5 months ago because the account linking feature was not working. The problem occurs in their backend in an opaque manner that prohibits any troubleshooting on my part. To this day, I'm still going back and forth with them on this problem with no resolution. It usually takes 4-5 days between responses and most of the time they are asking me to try the same things I've already tried numerous times or pointing me to same developer web pages over and over again asking me to make sure that I'm following their guidelines correctly. Meanwhile, I've spent hundreds of dollars running AWS infrastructure so they can actually troubleshoot the problem end-to-end with an account I created specifically for them. It honestly feels like they have no real interest in resolving the issue and just want to make it look like the support ticket isn't stagnant.

Conclusion

If you're willing to accept its limitations and already have IoT cloud infrastructure in place, the Echo is an amazing interface for users to interact with. If you do plan to integrate your service with it, you'll need to give AMPLE time to get things working. And if you have to work with the Alexa developer support for any reason, prepare to have your project timelines significantly blown out

I'm hopeful that the impending release of Google Home (and Apple's rumored entry into the space) will create some competition and motivate Amazon to close some of the gaps in their ecosystem and better support developers in getting their applications working.

I've recently received some questions from Hobson users about its presence capabilities with regards to mobile applications. As a result, I've created a wiki page that explains the current presence capabilities and details an example of how they might be used in a mobile application:

Last week, Sigma Designs made significant parts the Z-Wave specification open the the public. This includes its device classes, command classes and security protocol. Prior to that, developers had to sign an NDA and purchase a development kit in order to make use of Z-Wave in any significant way.

This is great news for Hobson. I developed the WZWave library that Hobson uses without access to official Z-Wave documentation and instead relied on work done by the OpenZWave project and other miscellaneous resources found on the Internet. With the official documentation, a lot of questions can be answered and the WZWave library vastly improved. I'm actively in the process of bringing WZWave into alignment with the official documentation and introducing support for secure devices.

One piece of documentation notably absent from the public specification is the serial protocol used to control Z-Wave PC controllers (e.g. USB sticks). I still have quite a few unanswered behavioral questions in that area so I'm hopeful that additional documentation will be released. If not, Sigma Designs says they are setting up a community forum to answer Z-Wave questions which may be helpful.

The past couple of weeks have seen a lot of press around Google's announcement that they are shutting down the Revolv automation hub. Many of the articles I've seen use Revolv as an exampleofthe "pitfalls" of IoT. The whole debacle has hurt consumer perception of a market segment still in its infancy and left a lot of people with a $300 paperweight.

But let's be fair - Revolv is an example not of the dangers of buying into IoT but of buying into a closed system. More specifically, it represents the danger of buying into an ecosystem dependent on what I like to call proprietary vendor clouds. I wrote about the evils of IoT cloud dependence well over a year ago with products like Revolv specifically in mind. It's one of the big reasons I created Hobson.

Consumers can't be blamed for not realizing what they were buying into. A company is never going to willingly advertise that their shiny new product becomes utterly useless if they go out of business (or, in this case, get acquired by one of the biggest companies in the world). But it's a lie of omission - it's like buying a new car at a dealership and the salesperson neglecting to tell you that it can only be serviced by their specific dealership or it stops working. Unfortunately, Revolv and Google's own Nest products were in direct conflict with each other and there should never have been any doubt who would come out on top.

Why are these proprietary vendor clouds so evil for IoT? Much of the real innovation in IoT is coming from smaller companies, and according to forecasts, that trend will continue. Well-architected cloud infrastructure is incredibly easy to create using cloud vendors like AWS but it's definitely not cheap to run and maintain. Any company that sells you a hardware product with a "lifetime subscription" tethered to their cloud is betting on one of two things: either their hardware sales will continue to support the cost of maintaining that cloud or that they will eventually charge future customers a subscription fee should their user base grow significantly. Either outcome is heavily dependent on product growth and will leave early adopters in a lurch if that growth doesn't happen.

So what can a consumer do? It boils down to asking the right questions before buying a product. And the easiest question to ask is:

"Is this device functional when I'm at home and my Internet connection is down?"

If the answer is no, then you're gambling that product won't be the next Revolv. There's nothing necessarily wrong with that - you just need to accept the risk.

There is nothing stopping companies from creating products that offer a hybrid model allowing their devices to work locally and through a cloud-based service. Unfortunately, most companies seem to view the IoT as a way to trap customers inside their closed ecosystems. And that is the real problem with the IoT today.

Hopefully the Revolv situation will make consumers much more aware of the hybrid model's importance and the current crop of cloud-only devices will simply whither and make way for hybrid ones that give consumers much more flexibility and future-proofing.

I'm happy to announce that the latest public beta of Hobson (0.8) is now available.

This release brings a lot of new capabilities that were mentioned in my previous blog post and I'll re-iterate here. Suffice to say there is a lot of good stuff here with a lot more coming!

Presence

Hobson now has the ability to define both people and locations for use in presence detection. Locations can be defined as either map (a certain radius around a latitude/longitude) or beacon (a certain distance from a BLE beacon). Hobson also has the ability to create tasks based on a person moving in or out of a location. This all provides the foundation necessary for presence detection via the in-progress Hobson mobile app.

Device Passports

Hobson now has a way to create what are known as device passports. Device passports are exchanged with user-created devices so they can connect to Hobson directly over supported protocols.

MQTT

The first device passport protocol to be implemented is MQTT and is enabled by installing the MQTT plugin. More information about Hobson's IoT capabilities can be found on Hobson's IoT page and specifics about the MQTT plugin can be found at the MQTT Plugin Wiki Page.

Alarm Systems

Hobson now allows plugins to create alarm system devices that can be armed & disarmed. This works great for alarm panels and the current Hobson sensor device works great for alarm sensors.

Data (formerly known as Statistics)

The Hobson API has been refactored to better support the concept of device data. It is now possible to create arbitrary data sets that comprise variables from multiple devices. For example, you could create a data set that tracks the outside temperature from a weather station and the inside temperature from a thermostat. The web console has also been refactored to allow graphing of these data sets.

The Hobson data plugin (still in development) will allow you to store this data locally. This also lays the groundwork for the optional Hobson cloud service that will allow you to both store and analyze the data.

Wow, it's been a really long time since my last post! Suffice it to say that the focus of the past several months has been on various aspects of Hobson culminating in a 0.6 release which also marks the first public beta. I thought it worth highlighting some of the features and improvements in this release as well as some things that are in the works.

New Web Console

The most visible change is Hobson's new configuration wizard and web console. They have been completely re-written (using Backbone.js and Zurb Foundation) to further Hobson's goals of usability and intuitiveness. Task creation in particular has received a complete overhaul and now follows an IF-THIS-THEN-THAT metaphor. Another useful addition is the activity sidebar that provides an audit log of recent smart device and task activity.

New Plugins

A few new plugins have been created for both devices and services. The Davis Vantage plugin can communicate with Davis Vantage weather stations. The Weather Underground plugin can transmit data from a Hobson weather station device to a Weather Underground PWS. The Twilio plugin provides a task action for sending SMS messages via the Twilio service.

MQTT

Hobson's model for connecting with consumer smart devices has been one of proactive discovery. The Hub looks for devices (or the user explicitly tells Hobson about them) and they are added to the list of devices Hobson can monitor and control. The new MQTT plugin inverts that model to make Hobson much more useful in IoT projects. It effectively turns the Hobson hub into an MQTT broker for external devices and sensors to connect to. A simple user-initiated bootstrapping process insures that only authorized devices can connect. Devices connecting to Hobson in this manner are first-class citizens and benefit from all the functions that Hobson provides. This will hopefully make Hobson an attractive option to those that have created smart device or sensor hardware that require a communication hub.

SDK and REST API Changes

Behind the scenes, a lot has changed since the 0.4 release. Configuration for the hub, devices and plugins now all use the same underlying mechanism. Tasks have received a complete API overhaul to make them much more powerful and easy to extend. A myriad of other changes should make it much easier for developers to both work with and extend the Hobson platform.

Moving Forward

There are a lot of items in the Hobson backlog in various stages of completion. I thought it worth mentioning a few of them.

Hobson Firmware

The current maker movement has produced a ton of hardware that makes it extremely easy to create devices that interact with the physical world. As we all know, the effort needed to turn a prototype into a finished product consumes a significant amount of a project timeline. The idea behind Hobson Firmware is to provide out-of-the-box foundational capabilities for low-cost hardware platforms to let developers focus on the specifics of their application. These foundation capabilities include things like Wi-Fi network acquisition, hub discovery, secure bootstrapping, connection monitoring, etc. It's currently based on MQTT with CoAP being considered as a future addition.

The current prototype is running extremely well on the low-cost ESP8266 platform and the Arduino Yun is being considered as the second supported platform.

It's worth noting that even though it's called Hobson Firmware, it has no particular Hobson dependencies. The firmware obviously works seamlessly with Hobson's MQTT plugin, but you can use any MQTT broker and the bootstrap protocol is simple and easily implementable.

Look for more information on this over the next several weeks.

Statistics

The current Hobson device statistics mechanism was a first attempt at providing a way to graph device metrics. However, it is not as useful as it could be and progress is being made on a revamp of the statistics mechanism to allow the end-user to define and display collections of metrics that span multiple devices. For example, it would be trivial to create a graph that plots the outdoor temperature from a weather station or Internet source against the internal temperature in the house.

Presence

The ability to generate presence events (e.g. detecting when a user arrives or leaves home) is an important capability. Hobson already has some framework in place to support this and the next step is to make it real. Work is actively being done with mobile phones and Bluetooth beacons to enable presence-driven use cases in Hobson.

Conclusion

As you can see, a lot has been going on and I hope to do a much better job going forward with providing insight into things as they are happening. There are a lot of exciting things coming!

As always, Hobson is free and open-source and I strongly encourage anyone that is interested to get involved. There's plenty to do for people of any background or skill level. Contact me through the forum if you'd like to learn more.

Canonical recently announced its Snappy Ubuntu Core OS for smart devices and the Internet of Things (IoT). Their intent is to create an operating system that is small, secure and easy to upgrade. While it's still in alpha, it already looks extremely promising.

I'm happy to announce that an early-release version of Hobson is now available through the official Ubuntu Snappy store. This make it easy to install and run Hobson on Ubuntu Core Snappy's first supported hardware platform -- the BeagleBone Black.

Canonical's announcement is an exciting one and Hobson's support for the BeagleBone Black means that a very low-power, dedicated Hobson Hub can be had for around $50.

As we progress further into a connected world, our actions and behaviors become increasingly quantifiable. As the Internet of Things (IoT) continues to gain momentum, so too the proliferation of data about our lives.

While connected technologies will undoubtedly make our lives more convenient, we should remain aware of the privacy cost these conveniences demand. Such vigilance is especially important now that big companies such as Google, Apple and Samsung are moving into the IoT and home automation space. I say this not because they are "big, evil corporations" but because they have lines of business that have nothing to do with the connected home.

Nest is a good example. A small company that makes connected thermostats is now owned by a big company (Google) that clearly wants to turn that thermostat into a hub for an increasing number of devices in the home. The "Works with Nest" program will invariably produce a host of third-party hardware that interoperate to make people's lives more convenient. The subtle cost is that the data enabling this convenience is funneling through a company whose bread and butter is targeted advertising. Now, Nest has stated that its customers won't see ads on their thermostats anytime soon -- but the data generated by homes can be utilized in ways that aren't so blatantly obvious.

Now, I'm not suggesting we retreat into caves and put on tin foil hats. What I would suggest is that we support products that are transparent about the security and use of the data they generate and eschew the ones that don't. After all, it's OUR data -- these companies are merely the stewards of it.

In creating the Hobson open-source automation platform, I tried to accomodate both sides. Users can send their data to the private Hobson cloud where it can provide insight through analytics. But, for those that value privacy over insight, Hobson can keep its data local and remain a fully functional product -- the cloud is not mandatory. I feel this is something we should expect from all the connected products we invest in.

CES 2015 is now in full swing and expectedly replete with connected product announcements. Below is a quick recap of what's been announced thus far. It's left as an exercise for the reader to determine what's useful vs. gimmicky but there is no doubt that many big companies are taking the Internet of Things (IoT) and connected products seriously.

IoT Platform

The D-Link automation hub for Z-Wave and WiFi devices and a new line of Z-Wave accessories including motion sensors, security cameras and water leak sensors.

BeeWi's home automation platform and line of smart devices and modular sensors/trackers.

The trend in the home automation space these days is to create hardware devices that are tightly coupled to the Cloud. While this can provide a great user experience when setting up the system, not everyone is aware of the longer term implications of this coupling.

Vendor X Example

Let's say you've just picked up Vendor X's shiny new home automation hub and have it all working. You're enjoying the convenience of controlling your home on your mobile device both in and out of your home. In most cases, here's what that setup looks like:

As you can see, Vendor X's hub communicates with Vendor X's Cloud through your Internet router. On the flip side, your mobile device communicates with the hub through Vendor X's Cloud. It's important to note that this is the ONLY way your mobile device can access the Vendor X hub.

So imagine you're sitting at home and your Internet provider has an outage (yes, I'm looking at you Comcast). This breaks point A in the diagram. Even though you're sitting within 10 feet of your home automation hub, it's pretty much a paperweight until your Internet connectivity is restored.

This may seem unlikely if your Internet connectivity is relatively stable. Ironically, I received an e-mail from a friend while writing this blog post expressing frustration about how he lost control of his automation system when his vendor's Cloud service had an outage. So it's not just your Internet that can be the failure point.

I'm sure some of you are thinking, "So what? I'll just have to manually turn on my lights for a little bit like in the old days." And it's true that this scenario poses some frustration at best. However, as people become used to the convenience these systems offer, it won't be long before they consider adding more sensitive devices such as door locks and security systems. This makes the penalty of a system failure quite a bit higher. Why buy into a product with such a limitation when other options are available?

How Hobson Is Different

Since this is the Hobson blog, I'd be remiss if I didn't show you how Hobson eliminates this problem.

Just like Vendor X, Hobson also has an automation hub and will offer a cloud service that lets you control it from anywhere. However, the picture looks slightly different:

The blue arrow in the above diagram highlights the important differentiator. Your mobile device has the ability to talk to the Hobson hub directly over local Wi-Fi. In fact, the design of the mobile app is such that it prefers communicating with the hub directly over Wi-Fi whenever possible to minimize your cellular data cost. So, should the Internet go down (point A in the diagram again), you still retain full control of your system.

The other benefit of this approach is that the Cloud service in this picture is completely optional. Savvy technical folks could set up their Internet router/firewall to allow inbound access to the Hobson hub and thus control it remotely without using the Cloud service at all.

Summary

No matter what automation system you use, it's important to understand its limitations. I've seen quite a few people both in-person and on automation forums express surprise when their system becomes unavailable due to a service outage of some sort. Hopefully this blog post will help to eliminate that surprise for at least a few people in the future.

To learn more about the open-source Hobson automation system, please visit the website.

One of the Hobson automation system's goals is to keep a small footprint and thus it's an excellent candidate for running on single board computers (SBCs). Below are two SBCs that Hobson is currently being tested on:

The device on the left you might recognize as a Raspberry Pi. The device on the right is a CuBox-i. Both of these are running the Hobson Hub on Arch Linux.

Why does this matter?

These devices are small and unobtrusive.

When you're talking about running in an average home, that's an important consideration.

These devices consume very little power.

Both the CuBox-i and the Pi consume about 3 watts of power (according to their manufacturers). To put that in perspective, the average PC will consume somewhere between 80 to 250 watts. Typical incandescent light bulbs consume 60 to 100 watts of power.

If Hobson is going to become a vehicle for helping reduce energy consumption, it needs to be of minimal impact itself.

In my area, I pay $0.11 per kWh. That makes the cost of running one of these devices 24/7 about $3 per year.

These devices are low cost compared to traditional PCs.

The raw Raspberry Pi board's current price on Amazon is $39 (with a case it should be just under $50) . The CuBox-i starts at $80. You'll also need a power supply and SD card to get them fully working. Even if you didn't have those already lying around, it shouldn't be unreasonable to put a Hub together for less than $100. And I fully expect things to get less expensive over time.

In keeping with Hobson's ease-of-use goal, we'll be making Hobson Hub SD card images available for both the CuBox and Pi platforms. This will make installing Hobson as easy as downloading a file, writing it to an SD card and plugging it into your SBC of choice.

Of course, the SBC landscape is constantly changing and we'll be keeping an eye on the latest developments in this area.

The central component of the Hobson automation system is called the Hobson Hub. The Hobson Hub runs inside your home or business and is responsible for controlling and monitoring all hardware devices you tell it to manage.

Since the Hobson system supports many disparate types of hardware and protocols, it acts as a mediator to provide a consistent way to manage and control any hardware it knows how to interface with. This allows client devices, such as your phone, to communicate with devices in your home that it wouldn't otherwise know how to talk to.

Note the above diagram is only an example of a few of the protocols that the Hobson Hub works with. Furthermore, the Hub includes a robust and well-documented API that allows developers to add new protocols seamlessly.

The Hub software was designed from the ground up to be cross-platform and lightweight making it possible to run on many different types of hardware. It can run on devices ranging from small and inexpensive "mini computers" all the way up to high-end servers.

Here's some of the more interesting hardware that the Hobson Hub has been successfully run on:

As you can see, there are some low cost (and low power) options that make running the Hub very affordable. A sub-$100 automation hub that consumes negligible power is no longer out of the question!

This is all great but what about setting up a Hobson Hub? When most people hear open source they assume hours of work requiring detailed technical know-how. Hobson Hub will feature software installers for Windows, Mac and Linux as well as SD card images for select platforms which will make setting up the Hub hardware a quick and simple undertaking even for the technically challenged. An intuitive wizard will guide you through the initial software setup and you'll be off and running!

Stay tuned for more information as Hobson continues through its private beta. And feel free to request early access to Hobson Hub (through the forum) if you want to start playing with it sooner and help guide its development.

The term home automation suffers from an unfortunate stigma. Long considered to be a plaything of the wealthy, it is dismissed as something extravagant or unnecessary by many. If you consider the historical barrier to entry, such an assessment makes sense. One had to hire an expensive installer to install even more expensive equipment and then pay by the hour to set it up and maintain it. When all was said and done, you had a proprietary system that was primarily focused on control — using some sort of in-home interface to switch lights, adjust thermostats, etc. No one could really argue against it being a luxury.

The technical landscape in support of home automation has changed drastically over the past several years. Let’s break it down by layer.

The Controller

The past: The heart of the automation systems was a proprietary hardware device running closed-source software. Programming the system (either initially or to tweak things after the fact) required hiring a highly-trained installer or effectively becoming one yourself.

The present: Devices such as Raspberry Pi, BeagleBone, CuBox, etc. have shown that hardware platforms capable of running automation systems can be had for less than $100. The open-source software community has produced mountains of free software that run on these devices and can be used as the basis for automation systems.

The Interface

The past: Use of expensive, proprietary remote controls or mounted screens useful only for the automation system and tethered to within a few hundred feet of the home’s perimeter.

The present: Millions of people carry around a multi-purpose, high-resolution touchscreen device in the form of a smartphone or tablet. Always-on Internet connectivity means these devices can potentially connect to the home from anywhere.

The Devices

The past: Devices such as lights, thermostats and sensors are proprietary to the automation system and couldn't easily be installed or configured by the homeowner.

The present: The market is bristling with big name hardware vendors such as GE, Honeywell, Lutron and Leviton that produce affordable, controllable devices. Most adhere to a communication standard such as Wi-Fi, Z-Wave, Zigbee, Ethernet, etc. making it much easier to integrate with and control them.

So having said all that, where’s the mass-market home automation revolution? I’m convinced it’s coming or I wouldn’t have gotten involved in it. But I believe there are a few things that are hindering its velocity.

• Remember those communication standards I mentioned a couple of paragraphs ago? While it’s great to have standards, it can be harmful to have too many. It’s unsettling for a consumer to put all of their eggs in one basket (by committing to a single standard) and no standard seems to have the perfect combination — widely-available, reliable and affordable devices that cover all major automation use cases.

• Apple has proven that people are willing to pay more for devices that “just work” and are easy to use. There have been a variety of companies that have released automation devices that tout ease of use and, although not expensive by historical standards, still cost enough for consumers to hesitate. Freely available solutions seem to swing completely the other way — it’s free so it doesn’t need to be easy to use or well documented. “Read the code” is often your primary support option.

• Many of the solutions out there still focus primarily on control. While it’s extremely convenient and fun to control your home from a smartphone, it can still be considered a frivolity. I believe automation systems will go from luxury to necessity when they can unequivocally show they pay for themselves many times over by reducing your home operational costs.

Hobson tries to overcome many of the current challenges associated with home automation.

• Hobson is automation hub software that allows you to build a “best-of-breed” automation system. You can pick and choose home control hardware based on the best fit for your needs rather than the communication protocols they speak.

• Hobson is freely available under an open-source license. This means anyone can download and use it for free.

• Hobson is very lightweight which enables it to run on inexpensive, non-proprietary hardware. You can run it on an old PC you have lying around, a new low-power mini computer or a fault-tolerant server running in a data center. The choice is yours.

• Hobson is being designed to provide insight into your home’s energy usage and recommendations to reduce your bills. This makes it much more than a mere control system and will allow it to offset its minimal cost quickly.

• Hobson will have a cloud-based service that simplifies the setup and usage of the system. This makes it accessible to less technical users. Although that service will be fee-based its use is not required. It is merely a convenience for those who don’t want to “get their hands dirty” learning how Hobson works.

• Hobson is built on an extremely modular architecture that makes is easy for developers to extends is capabilities. Great lengths have been taken to insure Hobson’s API is well documented so developers can add support for new devices and features themselves. “Read the code”, while still valuable, is considered a last resort.

Hobson is currently in private beta but will be generally available soon. Keep an eye on this site for more information.