Smarter Things | Technology choices for developing an IoT solution
Updated: Aug 11, 2020
Planning a Smart Solution
Introduction
This is the story of a journey that turned my ancient A/C window unit into a smart device that can integrate with Alexa, a dashboard, and a native app. However, this story isn’t only about a single outdated device entering the era of the cloud, it’s about the power and flexibility provided by AWS and its suite of IoT related services. In our first expedition into the “smart” world, let’s take a step back and look at how to architect a smarter solution.
Setting Goals
At Cedrus, we have recently been working on an end-to-end solution to monitor and control IoT devices using (mostly) AWS. Before we began, we used design thinking to clarify our main goals:
Allow users to control devices through multiple user interfaces (Alexa, web app, native app)
Report energy consumption for devices when possible
Display historical energy usage in a meaningful way
Ensure that security is robust and impenetrable throughout our entire stack
As much as possible, create a technology agnostic solution
Train machine learning algorithms to detect anomalous device behavior; for example, send a push notification when a freezer door has been left open on a refrigerator connected to a smart plug
With these goals in mind, research and testing led us to our ideal solution built around Greengrass and openHAB. Let’s dive into some of the reasons we chose these technologies.
Why Greengrass?
Greengrass, a relatively new service provided by AWS, is an incredibly powerful tool for several reasons. First and foremost, Greengrass takes the power of IoT Core and moves the business logic to the edge. Greengrass allows a device to run a long-lived lambda function locally on a gateway device. For our purposes, this meant we could develop a Node.js application to control devices and manage/report state. Greengrass also grants the ability to perform OTA (over-the-air) updates, making our code scalable as an enterprise solution. Patches and new features can be rolled out without having to physically access the gateway device. Furthermore, integration with every AWS service is seamless. Data can be captured and piped for IoT analytics, SNS push notifications can be triggered directly from the gateway device, and CloudWatch logs make debugging a breeze. Additionally, the robust security provided by Cognito and IAM prevents bad actors from accessing any valuable information in the cloud or turning a smart home into a fleet of malicious bots. As an added note—and a bit of personal commentary—Greengrass is simply fun to use. If you’ve ever wanted to get a closer look at the life cycle of a lambda function, or you’re excited by the prospect of easily running a Node.js app on a Raspberry Pi, Greengrass is sure to fill your nerdy heart with joy.
Why openHAB?
First, it’s important to understand the popular protocols used in new smart home products: Z-Wave and Zigbee. Both of these low-energy radio wave protocols were developed to compete with WiFi (which consumes too much power for many IoT devices) and Bluetooth (which has a very limited range). We chose to develop our solution around Z-Wave because, when compared to Zigbee, it has more universal compatibility, better security, a longer range, and won’t interfere with WiFi. In order to run Z-Wave devices, you need a hub to control the system. This is where openHAB enters the picture. OpenHAB is described as “vendor and technology agnostic open source automation software for your home.” OpenHAB was our clear solution for several reasons:
While we had chosen Z-Wave for development purposes, openHAB also supports a Zigbee binding allowing for greater future extensibility.
openHAB has a very active community and is well maintained. In fact, when the smart thermostat we purchased wasn’t integrating properly with the openHAB Z-Wave database, Chris Jackson, a maintainer, was incredibly prompt in responding and fixing the issue.
The fact that openHAB is popular and open source means that as future smart products are released, openHAB support will almost certainly and quickly follow.
Finally, the most important factor in our decision to use openHAB was the ability to access exposed API endpoints that report and control the state of all connected devices. This allowed us to easily integrate the Z-Wave protocol into the long-lived lambda function running our Node.js app on the gateway device.
Conclusion
Hopefully the first part of this blog series provided some insight about the main technology choices we made while developing our IoT solution at Cedrus. Greengrass and openHAB may comprise the backbone, but there are many more AWS services and technologies in the mix. In Part 2 of our blog series, we’ll discuss in technical detail how a user action moves through the cloud to control the state of our device. After all, we’ve only just started on our journey to turn a dumb A/C unit into a “Smarter Thing” …