It all started last year when I replaced my old NAS drive with a new, more powerful device. I chose the single board computer Cubietruck, which is the third generation of the Cubieboard, a slightly more powerful device than the Raspberry Pi. With its SATA plug, the Cubietruck can nicely serve as a central home media server, which was so far the responsibility of my old NAS. With the new device, I also wanted to use it implementing a home automation solution. One of the most important use cases for me is (remote mobile) control of thermostats, but the final solution should also be extendable to control other smart "things", such as blinds, an outdoor video camera, my internet router etc.
The smart things dilemma
The market for "smart" things such as WIFI-enabled lamps, radio-controlled thermostats or security cameras is huge, and you get easily lost when starting to compare the many solutions with each other. Most of them work with proprietary communication protocols such as z-wave or EnOcean, and bring their own mobile app to control them. This makes it hard to let the smart things talk to each other, and the user becomes the integration point between them. This certainly contradicts the idea of a truly automated home with little or no manual interaction of the user. Shades and blinds should be opened and closed automatically as a function of the wind and light intensity, and a smoke alarm detecting smoke should cause all lights in the house to blink, send an alarm message via a push notification and automatically alert the fire department. All of these scenarios require integrated, not isolated, devices.
Enough on the challenges - let's talk about solutions! Each home automation solution follows a common architecture: Your smart devices communicate with a central control unit to which they are connected to, either by wire, WIFI or radio frequency. This unit is a combined hardware and software solution to receive the events sent by your sensor devices (such as the temperature measured by your thermostats) which can trigger actions on your actors. Usually you define those actions as a set of rules in a domain-specific programming language of your central control unit. Almost all those units on the market come with their own, proprietary programming model and do not allow to integrate devices from other vendors. This can drive you into a costly dependency upon the manufacturer of the unit.
openHAB to the rescue!
This is where I came across a wonderful piece of technology: The Open Home Automation Bus, or openHAB. OpenHAB is an open source project under the Eclipse Public License (EPL) and has a very active community. It lets you implement a vendor-independent central control unit on a low-cost single board computer with a broad support for many smart devices out-of-the box. At the same time, it is open for your own extensions. As the underlying framework, openHAB uses the Equinox OSGi runtime, which allows you to easily add or remove features as OSGi bundles from the openHAB runtime. The openHAB "Add-On" download package contains already a large number of bundles, called OpenHAB bindings, from which you can choose the ones you need for your home devices. For example, there is a KNX binding for widely used KNX bus, as well as bindings for the radio-controlled FS20 and HomeMatic systems, the Philips Hue LED lighting, and the FritzBox router.
Bindings in openHAB transform the device-specific protocols and messages into a common semantic model and connects them to openHAB's software bus. However, bindings are not limited to (hardware) sensors and actors. There are also bindings to integrate cloud services, e.g. to collect current and forecast weather data from different provides. Each object managed by openHAB is assigned to a specific binding and registered on the bus as an item. Items can be of different types such as a simple string or number, a dimmer, or an on/off switch. Items can receive and send events on the bus. To make the items accessible to frontends such as a Web Browser or the free native mobile app of the open source project, openHAB supports the concept of a sitemap which collects and create the elements of a user interface.
Based on this vendor-independent object model, events received or sent by the items can trigger actions which are executed by openHAB's rule engine. An action in openHAB does the opposite of a binding: It is used by a rule to translate a command sent on the bus into the device- or service-specific messages. The following diagram shows how bindings, items, sitemaps, actions and rules relate to each other in openHAB's domain model.
Back to the scenario
Installing openHAB on my Cubietruck running Debian Linux was a matter of a few minutes. All you need is a Java VM and off you go! Next I compared different products for radio-controlled thermostats which allowed me to replace my old ones without any hassle. I selected a product from HomeMatic, which is offered at a reasonable price. The thermostats are powered with a battery and equipped with an RF module for the 868Mhz band to send and receive commands using the Bidirectional Communication System (BidCos) protocol.
To turn my NAS into a fully functional central control unit for home automation, I also needed micro controller to communicate with my radio-controlled thermostats. This task is taken over by a CC1101 USB Lite module, or short CUL. The CUL is a USB dongle which can be flashed with the CUL firmware from culfw.de, another open source project in the home automation space. After doing so, the CUL supports a number of protocols for several home automation system, such as BidCos. Here is a photo of my CUL plugged into the Cubietruck's USB port:
Connecting the sensors to openHAB
Connecting the openHAB instance running on the Cubietruck to the radio-controlled thermostats in my living room, the kitchen and the bath is really simple. In my openHAB site's item configuration file, I set the items as number values which display the actual temperature and set the target temperature on the three thermostats as follows:
Number Thermostat_Livingroom_Target "Living Room [%.1f °C]" { homematic="address=<hardware id>,channel=4,parameter=SET_TEMPERATURE,forceUpdate=tr
Number Thermostat_Livingroom_Actual "Living Room [%.1f °C]" { homematic="address=<hardware id>, channel=4, parameter=ACTUAL_TEMPERATURE" }
Number Thermostat_Kitchen_Target "Kitchen [%.1f °C]" { homematic="address=<hardware id>,channel=4,parameter=SET_TEMPERATURE,forceUpdate=true" }
Number Thermostat_Kitchen_Actual "Kitchen [%.1f °C]" { homematic="address=<hardware id>, channel=4, parameter=ACTUAL_TEMPERATURE" }
Number Thermostat_Bath_Target "Bath [%.1f °C]" { homematic="address=<hardware id>,channel=4,parameter=SET_TEMPERATURE,forceUpdate=true" }
Number Thermostat_Bath_Actual "Bath [%.1f °C]" { homematic="address=<hardware id>, channel=4, parameter=ACTUAL_TEMPERATURE" }
The items are bound to the HomeMatic binding provided by openHAB. Each of them is configured with the corresponding thermostat's unique hardware id (e.g. KEQ0048285) and a datapoint (parameter) which is basically the command sent to the device. All of those configuration settings are product-specific and translated by the binding into the proprietary messages of the BidCos protocol.
Adding the items to a sitemap configuration file in openHAB makes them accessible via the openHAB mobile app or a web browser. The following is an excerpt from my sitemap file for exposing the thermostat in the living room in the UI:
sitemap homezone label="Homezone"
{
Frame {
Text item=Thermostat_Livingroom_Actual {
Frame {
Setpoint item=Thermostat_Livingroom_Target step=0.5 maxValue=30
}
}
}
...
A Text element is used to display the actual temperature measured by the item with command (parameter) ACTUAL_TEMPERATURE. The element Setpoint renders to a modifiable control which has an up- and down-arrow button to set the target temperature of the thermostat (with a maximum value of 30 degree celsius).
Basically with the few steps from above, you can get an open and extensible platform for you home automation scenarios up and running with a budget of less than 160 € for the central control unit. The following video shows the free openHAB mobile application in action with the current solution:
Bringing SAP HANA Cloud Platform into the picture
Now with being able to measure and control the temperature in the rooms of my house, the next step for me was to have a sensor logging application which offers an API to store and retrieve the temperature data from the thermostats and keeps a history of it. Although single board computers like the Cubietruck or the new Raspberry Pi 2 Model B continuously increase their storage and processing power, they still remain a bad place to store and analyze (big) data. For this task in an home automation or Internet-of-Things scenario, a Cloud-based service would be a far better option.
This is where SAP HANA Cloud Platform (HCP) comes into the picture: With a UI5-based application on HCP similar to rui.nogueira Fish Import and Export sample, I want to be able to provide a overview of all sensors connected to HCP with a diagram for each of my sensor's historical data.
This requires my openHAB-connected thermostats (or any other types of sensors in my house) to continuously send their measured temperature values to HCP. The cloud application should provide an easy to consume, HTTP-based REST API, which will be used by a new openHAB extension for SAP HCP.
Securing the API
A common requirement in Cloud-enabled IoT scenarios is that the sensors will send their data to the Cloud. Besides confidentiality of the data, care must be taken that only authorized devices are allowed to send the data. To fulfill this requirements for proper device authorization in an IoT scenario, the following boundary conditions have to be considered before selecting a particular security mechanism:
- Sensors are not users: Protecting the API on HCP with a username and password sounds like a quick win: Easy to implement on the consumer and provider side, and it works with RESTful services using the HTTP Basic Authentication Scheme. However, passwords need to set according to a policy defined by the service managing the user accounts (aka "Identity Provider", IdP), and they usually expire after some time. Real users know how to choose a compliant password and how to reset it, but sensors don't! Thus, a credential which better fits to the nature of a device should be chosen to protect the API on HCP side.
- Limited processing power of the sensors and central control unit: Security mechanisms which require strong cryptographic processing capabilities usually do not fit very well in the overall picture of a home automation / IoT scenario. Thus, a lightweight but still secure authentication and authorization mechanism should be chosen.
Considering those boundary conditions, let's take a look at the supported authentication mechanisms in HCP:
- Basic Authentication: As stated above, username and password-based authentication works well for real users, but not for devices. A common workaround taken in situations where there is no alternative to password-based authentication is to introduce a "technical" or "system" user. Those special user accounts are for example not allowed to authenticate via the logon UI, and are not forced to renew their password every 6 months or so. By default, validation of password credentials on HCP is taken care by SAP ID Service (SAP's public Identity Provider), which does not support such type of technical user accounts. You may want to use your own user store (LDAP directory) on HCP and manage the special accounts there, but this would certainly require more infrastructure on the client side, and still not solve the issue of the mismatch between the authenticated entity (a device, sensor) and the credential.
- Security Assertion Markup Language (SAML): SAML is actually not an authentication mechanism, but a Single Sign-On (SSO) protocol, designed for browser-based (web) scenarios. It requires an IdP which authenticates the user whatever mechanism the IdP's considers to be secure enough. It then sends back a response to the application (aka Service Provider, SP) the user desires to log in with an XML-token, the SAML Assertion. The SAML protocol flow relies on a web browser which acts as the relay in the protocol between the IdP and SP to support interactive log-on at the IdP, render HTML in the response from the IdP and execute JavaScript to auto-submit the response back to the SP. From this perspective, SAML does not fit at all into the picture of a sensor authenticating an API call. We may expect from the central control unit or even the sensor itself a basic support for acting as a web client, supporting HTTP and (possibly) TLS/SSL protocols, but certainly no HTML rendering or JavaScript capabilities.
- Client Certificates: Although an X.509 certificate is a much more generic credential than a password and thus may not only authenticate users, but also systems, devices etc., it still remains a relatively heavyweight credential. First, the lifecycle of X.509 certificates is usually managed by a complex infrastructure called a "Public Key Infrastructure", or short PKI. Main components of the PKI are the Registration Authority (RA) for verifying the identity of the certificate's owner, and the Certificate Authority (CA), responsible for issuing the certificates, maintaining revocation lists etc. Second, using X.509 certificates for client-side authentication involves asymmetric data encryption, which can be a costly operation based on key length and other parameters. Again, a sensor or central control unit may not be the ideal place for such type of operations.
- Open Authorization Framework (OAuth): OAuth has emerged as a de-facto standard for protecting RESTful APIs. It uses a lightweight approach to authenticate the API consumer. The credential used by the consumer to authenticate the API call is called the access token, which, in its simplest format, is just a opaque string representing an authorization issued to the consumer. For obtaining the access token, OAuth support a number of mechanisms, depending on the consumers (or OAuth client's) capabilities. Although there may still be even more simpler approaches to get a lightweight but still secure credential to the devices in an IoT scenario, OAuth seems to be very good fit here. So let's investigate this option in more depth on how OAuth on HCP can be used in my home automation scenario.
Authorizing the thermostats with OAuth
... is done in part 2 of this blog! Part 1 so far covered most of the theoretical background we need :
- openHAB has been introduced as a flexible, extendable and open platform for your home automation needs
- We looked at the steps to connect "Things" or sensors such as smart thermostats to an openHAB instance
- We spend some thoughts on how to use HCP to store, visualize and analyze the data generated by those sensors
- And finally, we looked at the various options available on HCP to protect our service
Continue reading with part II here.
- SAP Managed Tags:
2 Comments
