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.
See the Hobson & BeagleBone Black wiki page for more information.
About this blog
A blog about all things IoT and automation.
Entries in this blog
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 example of the "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!
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.
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.
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.
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.
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.
So, where is your connected data going?
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:
Hopefully this helps to make things a bit more clear. Feel free to post to the Hobson forums with any further questions.
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:
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.
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.
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.
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.
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.
There are a lot of items in the Hobson backlog in various stages of completion. I thought it worth mentioning a few of them.
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.
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.
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.
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.
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 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 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 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.
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.
- 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.
- Samsung's next generation SmartThings automation hub and paid home monitoring service.
- The Nest thermostat becomes more of a hub as it integrates with products from LG, Philips and Withings.
- New Belkin WeMo devices including a door-and-window sensor, keychain tracker, motion detector, water efficiency monitor and alarm sensor.
- The Misfit Bolt - a $50 color LED WiFi smart bulb that and can last 20 years.
- The Brio smart power outlet.
- The Honeywell Lyric security system - their second Lyric product after their Nest competitor thermostat.
- The Schlage Sense voice-controlled smart lock with mobile device control.
- The Netatmo Welcome connected camera with facial recognition.
- The Kwiket Kevo Plus service for remotely controlling its connected door locks.
- The Parrot H2O and Pot connected plant watering system.
Appliances & Media
- Samsung's announcement that by 2017 they will make 90% of their products IoT connected; 100% within 5 years.
- GE's new Profile line of connected appliances including a dishwasher, fridge, laundry combo, oven and water heater that can be controlled from a mobile device.
- Android TV sets from Philips, Sharp and Sony.
- The new Google Cast audio standard for streaming music to connected speakers.
- Dacor's Android-based ovens that can be controlled via voice through a mobile device.
- Reponsive Surface Technology's ReST bed that automatically tracks sleep and adjusts its surface as you toss and turn.
- The Lynx SmartGrill that can automatically adjust temperature and send alerts your mobile device.
- Anova's WiFi-enabled sous vide cooker that lets you set temperatures remotely through a mobile device.
- There were more fitness-related wearables announcements than you could shake a stick at.
- The Intel Curie connected wearable hardware platform.
- The Connected Cycle bicycle pedal that can transmit your bike's location and track fitness.
Infant & Elderly
- The Pacifi smart pacifier that tracks a baby's temperature over Bluetooth.
- The TempTraq Bluetooth-enabled thermometer patch that can be monitored from a mobile device.
- The mamaRoo Bluetooth-enabled electric baby rocker
- The Siemens smart hearing aid that can automatically kill background noise and control microphone direction through a mobile device.
Hobson 0.9.1 is now available for download from the website.
This is a minor update that includes some requested features:
- Ability to manually execute tasks by clicking/tapping their tile in the web console.
- Support for client HTTP requests with cookies from plugins.
- Support for client WebSockets from plugins.
I am pleased to announce that next version of Hobson, 0.9, has been released. Here is a list of new features and changes:
- Added initial support for Liftmaster MyQ garage door openers (beta of Liftmaster MyQ Plugin).
- Added initial support for LIFX bulbs (beta of LIFX Plugin).
- Added support for collecting and graphing device variables (Data Plugin).
- Revamped color model to support hue, saturation and brightness for better bulb color fidelity.
- Introduced serial port property type so use can select from a list of available serial ports when configuring plugins.
- Added support for connectionless IP devices (e.g. LIFX bulbs).
- Added ability to assign custom names to fields in a data stream.
- All authentication now uses OpenID Connect.
- Created Debian package file for easy installation on Debain-based Linux distributions.
- Added API hooks for websocket support.
- Added API hooks to tag devices.
- Added API hooks to tag data streams.
- Fixed bug in web console where task conditions and actions would show devices that were not applicable.
- Moved all local configuration to the "data" directory so "cache" directory can be safely removed without losing data.
- Improved plugin shutdown mechanisms with detection of plugins that don't stop in a reasonable amount of time.
- Miscellaneous other bug fixes and improvements.
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.
While the current focus is on the next major release of Hobson (0.10.0), users have reported a couple of bugs that were worth addressing in the short term. As such, Hobson 0.9.2 is now available.
Release Notes - Hobson - Version 0.9.2
* [HOBSON-12] - Daylight savings time can cause scheduling problems
* [HOBSON-30] - Adding a device passport in the web console gives an error
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.