Chapter 3

3 Key Concepts

In the following chapters we will discuss the components and the communication infrastructure which builds the home automation network (HAN). You will understand how the various technologies, protocols and devices work together and how they provide a secure, performant base for home and building automation. Chapter four provides as detailed discussion of the underlying mechanisms when smart devices communicate with each other, with a smart hub, with a cloud service or a remote smartphone. This will allow you to make informed technology decisions and in turn according product choices for your own projects. In chapter five we will look into security risks and breaches as they occur in smart home environments and how to avoid them. A description of common exploits and attacks on smart home networks will complement this section of the book.

From a topology perspective home automation consists of the following building blocks:

  • devices under control (DUC)
  • sensors and actuators
  • the home automation network (HAN)
  • the building controller (smart hub)
  • remote control devices (tablets, smartphones, panels) and
  • cloud services

Figure 3.1 shows an outline of the smart home topology.

3.1 Devices under Control 

Devices under control are all components, such as home appliances, consumer electronics, lighting, or window blinds, which are connected to and controlled by the home automation system. An increasing number of things come with such functionality built-in through integrated web-servers, WiFi-, Bluetooth- or Z-Wave-interfaces. Components without built-in control capabilities can often be equipped with adapters in order to integrate them with the smart home infrastructure.

3.2 Sensors and Actuators

Sensors are the eyes and ears of the home network. There are sensors for a wide range of applications such as measuring temperature, humidity, light, liquid, gas, detecting movement or noise.

Actuators are the hands of the home network. They are the means of how the smart home can actually do things in the real world. Depending on the type of interaction required, there are mechanical actuators such as pumps and electrical motors, door locks or electronic actuators such as electric switches and dimmers.

3.3 Home Automation Network (HAN)

The home automation network (HAN) provides the connectivity between devices under control, sensors and actuators on the one hand and the controller (smart hub) along with remote control devices and cloud services on the other hand. From a communication network perspective there are three technology options for home and building automation control networks:

  • powerline communication
  • wireless communication
  • wireline communication

3.3.1 Power Line Communication 

The power line communication principle uses existing electric power lines in buildings to transmit carrier wave signals in the frequency range of 20 kHz to 100 MHz. The long dominant, decades old, low speed power line standard X.10, has been finally replaced by HomePlug, which became the IEEE 1901 standard in 2010. AV2.1, the latest version of HomePlug, published in 2014, is able to achieve transmission speeds of up to 500 MBit/s while performing data encryption with a 128-bit AES cipher. The main advantage of power line communication is the low price for its components and that fact, that no additional wiring is required. The downside is, that power line distribution units can significantly impact transmission speeds. In some cases the design of the electric wiring can even prohibit the coverage of parts of the electric power line infrastructure in a building. Major vendors of HomePlug products are TP-Link, D-Link, Devolo, Netgear, GigaFast and Zyxel.

3.3.2 Wireless Communication 

Today a large number of wireless communication technologies for building and home automation systems are available. Transmission speeds and reach of the various technologies depend on transmission frequency and modulation, and range from 20 kBit/s to 250 kBit/s and 60 ft (20 m) to 3000 ft (1000 m) respectively. Other important considerations are power consumption and location accuracy. Technological advances have significantly improved all performance aspects of wireless transmission technologies in recent years. The main drivers for wireless technologies gaining popularity in home automation have been:

  • smart devices with wireless connectivity built in becoming widely available at low prices
  • new or updated home automation standards increasing safety, throughput and reducing power consumption
  • wireless plug and play home automation solutions offered by large vendors and telecommunication companies

While wireless building control for years has been plan B for lower end, post-construction projects, the evolution of wireless technologies along with a steep decline in cost has changed the industry. Today, Z-Wave, ZigBee, BLE (Bluetooth low energy), WiFi and RFID interfaces are available fully integrated in a wide range of controllable power-outlets, light switches, and household appliances. Many audio and video consumer electronic devices come with Bluetooth or WiFi interfaces, ready to stream content from the Internet, and ready to be fully controlled via smartphones. And the technological evolution continues. In 2016 the Wi-Fi Alliance announced 802.11ah (HaLow), a new standard optimized for Home Automation and Internet of Things (IoT) applications. It features a number of benefits compared to current Wi-Fi technologies. Using the 900 MHz band, other than conventional Wi-Fi networks operating in the 2.4 GHz and 5 GHz bands. This allows wireless signals to reach almost twice as far as current Wi-Fi radios, while using less power to broadcast. With this WiFi routers will become far more efficient at killing dead spots. Also mobile phones and WiFi based IoT devices will be able to communicate over greater distances while conserving battery life.

Another new technology player in home automation is the IEEE standard 6LoWPAN, which has been adopted for home automation applications by the industry alliance Thread, which was founded back in 2014. While the IEEE standard 6LoWPAN is based on IEEE 802.15.4 as Z-Wave, it supports IP-addressable smart devices, allowing them to be directly accessed from the Internet. While 802.11ah and 6LoWPAN products are just starting to reach the market, these new standards will change the home automation landscape. But also the established wireless technologies are upgrading their specifications to improve battery life, transmission speeds and safety. Examples are Bluetooth Smart (5.0), Z-Wave Plus and ZigBee 3.0. Devices using energy harvesting technologies such as products based on the EnOcean standard, which operate wireless control links using energy retrieved from the environment through temperature changes, light changes or push button mechanical energy, are also becoming widely available. To sum it up, the technology and standards clutter in wireless home automation networks is here to stay for the foreseeable future. Table 3.1 lists all major open standards used for wireless building automation today. It also includes the proprietary Insteon standard, which combines wireless transmission with powerline based communication. The powerline communication in Insteon networks serves as a backup in case wireless transmission is distorted or unavailable.

Standard
(Release)
Range(indoor/outdoor) Speed / Frequency / Modulation Standard Location Accuracy
Z-Wave
(1999)
100 m 250 kBit/s
908.42 MHz
GFSK
IEEE 802.15.4* 10 m **
Z-Wave Plus
(2013)
167 m 250 kBit/s
908.42 MHz
GFSK
IEEE 802.15.4* 10 m **
ZigBee
(2003)
30m – 500m 250 kBit/s
2.4 GHz, 915 MHz (US), 868 MHz (EU)
QPSK
IEEE 802.15.4* 10 m**
ZigBee 3.0
(2014)
30m – 500m 250 kBit/s
2.4 GHz, 915 MHz (US), 868 MHz (EU
QPSK)
IEEE 802.15.4* 10 m**
Wireless Hart
(2004)
50m / 250m 250 kBit/s
2.4 GHz
DSSS, Q-PSK
IEEE 802.15.4*, IEC 62591 10 m**
MiWi
(2003)
20m / 50m 20 kBit/s, 40 kBit/s,  250 kBit/s
868 MHz, 915 MHz, 2.4 GHz
O-QPSK
IEEE 802.15.4* 10 m**
EnOcean
(2001)
30m – 300m 125 kBit/s
902 MHz (US), 868 MHz (EU), 315 MHz (Int.)
ASK
ISO/IEC 14543-3-10 N/A
DASH7 (active RFID)
(2004)
1000m 200 kBi/s
433 MHz
GFSK
ISO/IEC 18000-7 1 m
THREAD /
6LoWPAN
(2015)
30m-500m 250 kBit/s
2.4 GHz
QPSK
IEEE 802.15.4 * 10 m **
Bluetooth LE (4.0)
(2014)
30m-100m 250 kBit/s
2.4 GHz
QPSK
IEEE 802.15.1 1 m
Homekit AccessoryProtocol (HAP)
(2014)
10m 1 MBit/s
2.4 GHz
GFSK
BLE (4.0) / IEEE 802.15.1 1 m
HaLow
(2016)
up to 1000m 100 kBit/s – 8 MBit/s
900 MHz
BPSK, QPSK, QAM
IEEE 802.11ah N/A
Bluetooth Smart (5.0)
(2016)
> 100m 125 kBit/s
1 MBit/s
2 MBit/s
2.4 GHz
FDMA / TDMA
IEEE 802.15.1 1 m
Insteon
(2005)
45 m 13 kBit/s
915MHz
FSK
Insteon N/A

Table 3.1 Wireless Building Automation Standards (click for larger view)

* LR-WPAN (Low Rate Wireless Personal Area Networks)
** Strongly depends on topology, frequency and distortion of the sensor

3.3.3 Wireline Building Automation 

The main open standards for wireline based building automation are KNX, G.hn, LON and HomePNA. KNX is a European (EN50090, 2003) and international (ISO/IEC 14543-3, 2006) standard for home and building automation. The abbreviation KNX stands for Konnex, and replaces the older European standards EIB (European Installation Bus), Batibus (primarily used in France), and EHS (European Home Systems). Today in Europe more than 75% of industrial building automation solutions as well as most upscale residential smart homes are realized using KNX. Over the past years, KNX has started to be adopted in many regions of the world outside of Europe as well.

LON (Local Operating Network), originally introduced in 1990 by Echolon Corporation and an ISO/IEC 14908 standard since 2008, is the building automation solution of choice for large scale automation projects such as airports, stadiums, or street lightning. Contrary to the hierarchical KNX architecture, it uses a decentralized approach. In large installations, local information can be processed locally, without being sent to a central control node. This allows for the scalability and redundancy needed in public installations with high availability requirements.

Another wireline transmission standard for the networked home, which has been primarily deployed in North America, is HomePNA. Specified by the Home Phoneline Networking Alliance it’s first release was published in 1990. For almost twenty years it was mainly used to transmit IPTV services over telephone wires, since 2006 also over coaxial cables. In an effort to put an end to the multitude of non-interoperable home networking technologies, the ITU-T working group G developed a single transmission standard for home networks, which can be used over any type of wire (telephone, coax, power line and fiber): G.hn (hn – home network). The initial release of G.hn was published in 2010. The industry alliance behind the standard is the HomeGrid Forum (HGF). In 2013 the Home Phoneline Networking Alliance merged with the Home Grid Forum. G.hn provides data transmission rates of between 250 MBit/s and 2 Gbit/s, depending on the physical medium.

3.3.4 Topologies of Home Automation Networks

All three home automation network technology categories– power line, wireless, and wireline – have significantly improved in transmission speed, reliability and interoperability through standardization efforts over the past years. In general, HANs based on power line communication and wireless transmission are dominant in residential home automation due to lower component prices and installation cost. Wireline based control networks are found in the premium residential segment and in control applications for public, commercial and industrial buildings. Since devices with wireless communication capabilities built in have became widely available, the number of wireless HANs has been growing fast, particularly in the residential segment. The single biggest challenge in HANs today however is the mix of different technologies, implementation variants and closed, proprietary solutions, which one has to deal with. Practically all HANs today consist of a multitude of technologies out of historic reasons or because of product constraints. Figure 3.1 provides a topology overview of how the different technologies in a HAN interconnect with each other. Looking at figure 3.1 you can see, that HAN communication takes place in three building blocks:

  • the communication within the HAN
  • communication between the HAN and external cloud services
  • communication between the external remote control devices and the HAN or external cloud services

Communication within the HAN

The two main communication hubs inside the HAN are the DSL router and the home controller (smart hub). The DSL router on the one hand connects all WiFi and Ethernet based components within the HAN with each other. At the same time it provides connectivity to the Internet. The wireline technologies such as KNX, HomePlug (powerline) or HomePNA (phone wires, coaxial cable) are connected to the router through IP/Ethernet converter units. The wireless technologies other than WiFi (the only wireless standard routers support), connect to the home controller or smart hub. Most smart hub vendors also support wireless communication standards other than WiFi such as Bluetooth, Zigbee and Z-Wave. If the home controller (smart hub) consists of a PC with home automation software installed, connectivity to Bluetooth, Zigbee, Z-Wave or THREAD is provided by appropriate USB interface units. In addition to supporting multiple HAN network technologies, the responsibility of the home controller is to manage smart devices (adding and removing devices) and to execute rules and scenarios. Further (through the DSL router) the home controller provides connectivity to external cloud services and remote control units (smartphones), which are away from home. It is important to understand that WiFi based smart devices (e.g. WiFi controlled wall plugs, lights bulbs, etc.) are directly connected to the router, as if the smart hub was not there. This is the case because smart hubs (at least in residential environments) do not create their own local area network, but use the one maintained and managed by the router. To connect and manage WiFi based smart devices the home controller sends out device discovery messages on to the local area network. Once a device responds, it can be added to it’s set of managed smart devices and become part of the controller rule and scenario definitions (Figure 3.1).

Communication between the HAN and external cloud services or external remote control devices

To connect to external cloud services and to allow for remote control from outside of the house, most controllers use the secure HTTP REST protocol. HTTP REST also allows cloud services to communicate to the controller from their end using the HTTP Server Push protocol. An alternative for remote access to the controller from outside is to set up a VPN connection. Through the VPN tunnel a client from outside can be added to the local network, allowing it to act as a local client (Figure 3.1). Both options, HTTP/HTTP REST and VPN are safe and secure, if set up and operated properly. Most major vendors of smart hubs (Samsung SmartThings, Wink Labs, etc.) or cloud centric products (e.g. Google NEST) are using HTTPS REST.

When smart devices are operated stand alone without a home controller, in order to make their set up less complex for the user, some vendors use the UPnP protocol. UPnP (Universal Plug and Play Protocol) allows networked devices to automatically discover each other by exchanging commands. UPnPl also allows devices in conjunction with the IGD-PC (Internet Gateway Device Protocol) protocol to automatically open ports on the DSL router, in order to communicate with external devices and services. So, by using UPnP, smart devices can directly communicate with a cloud service to become activated, to install software updates or to allow a remote user to access them (Figure 3.1). While device setup using UPnP is relatively easy, it is also insecure. Multiple major UPnP related security incidents have occurred in the past, with the consequence that leading IT security organizations (e.g. CERT) are recommending not to use UPnP. Beyond it’s security issues UPnP deployments do not scale well due to their extensive use of multicasts, which leads to the consumption of significant network resources in networks with large number of nodes. A widely used UPnP based solution is the WeMo product line from Belkin. Chapter 5 provides more details on the security issues related to UPnP.

 3.1-HAN-768x1024Figure 3.1 Communication infrastructure of the Home Area Network (HAN)

3.4 Controller (Smart Hubs)

The home or building controller, often also referred to as smart hub, is the entity, which acts as the brain of the building automation system. It collects information through sensors and receives commands through remote control devices. It acts based on user commands or a set of predefined rules using actuators or means of communication such as loud speakers, emails, pumps, motors, door locks or telephones. Controllers can be either

  • local computer systems with home automation software and interface adapters for HAN communication technologies (Z-Wave, Bluetooth, Zigbee)
  • integrated devices with specialized hard- and software (smart hubs) or
  • cloud based services

While most smart home solutions are built around a local controller, there are also decentralized approaches, which attempt to avoid a controller in order to reduce complexity. An example is Apple’s Homekit solution, which can be operated with or without a controller unit. Chapter seven provides details about the smart home solution from Apple as well as from other major vendors.

3.4.1 The Home Controller

For residential home automation, the controller typically is an always-on standalone Linux / Windows / macOS computer, running the control application for the house. Typically it comes embedded in form of a vendor branded, easy to set up smart hub, or it is an always on computer, equipped with the necessary HAN communication interfaces and running home automation software (Table 3.3). Higher end residential and industrial buildings use dedicated high availability, redundant controller systems with uninterruptible power supplies (UPS).

The home controller ideally provides connectivity to all smart devices in the building and thus typically needs to support multiple home automation infrastructure protocols (WiFi, Z-Wave, Bluetooth, KNX, etc.). It’s tasks are to

  • securely register (and deregister) devices
  • to interface to remote control devices such as smartphones, tablets or panels
  • to interface to cloud services and
  • to execute predefined rules.

Some functions such as rule definition and execution or remote control via smart phone from outside of the house are often implemented through a cloud service. The degree of integration with an external cloud service varies from vendor to vendor. Some solutions are implemented very cloud centric with key operational functions executed in the cloud, others use the cloud merely as a remote control and monitoring hub to be accessed while away from home. Solutions without any cloud component have become rare, however they still can be accessed and controlled from away using VPN. A VPN connection is a secure communication tunnel from a PC, a smart phone or a tablet, which can be set up via the public Internet to connect to any private local network, such as the home automation network of a building. As said however, today most home controller vendors offer products which combine local operation with some form of cloud service. As long as the smart phone or tablet is local and connected to the home WiFi network, the control of smart home devices takes place directly via the smart hub. If the control device is away from the building, the communication takes place via the cloud service, which in turn communicates with the smart hub.

Vendor Smart Hub Home Infrastructure Connectivity
Samsung
smartthings.com
SmartThings Hub Z-Wave, ZigBee, Bluetooth LE and Wi-Fi; IFTTT support
Wink Labs
wink.com
Wink Hub Z-Wave, ZigBee, Bluetooth LE, Wi-Fi, Kidde, Lutron ClearConnect
Logitech
logitech.com
Harmony Home Companion Wi-Fi and Bluetooth
Insteon
insteon.com
Insteon Hub Bluetooth and Wi-Fi
Honeywell
security.honeywell.com
Vista Automation Module Z-Wave, Wi-Fi, and Bluetooth

Table 3.2 Smart Hub Vendors and Products

The alternative to the ready to use plug and play smart hub solutions, as listed in table 3.2, are open source building automation platforms. While requiring some technical expertise and time for configuration and customization, these solutions are more flexible and provide more comprehensive functionality than their commercial pendants. Being non commercial and vendor neutral, a core philosophy of their architecture is to ensure, that none of the data, which is generated through remote control and automation procedures, leaves the controller to be exploited by third parties. The three largest and most popular open source platforms are OpenRemote, openHAB and Home Assistant (Table 3.3).

Platform Operating Systems Cloud Service Application Protocol Home Infrastructure Connectivity
OpenRemote
openremote.com
Windows 10, Linux, macOS, Raspbian designer.
openremote.com (Configuration only)
HTTPS
REST
WiFi, Z-Wave, ZigBee, Bluetooth, KNX, Enocean, Insteon, HTTP, IFTTT, …
openHAB
openhab.org
Windows 10, Linux, macOS, Raspbian myopenhab.org HTTPS REST WiFi, Z-Wave, ZigBee, Bluetooth, KNX, Enocean, Insteon, HTTP, IFTTT, …
Home Assistant
home-assistant.io
Windows 10, macOS, Ubuntu, Raspbian HTTPS REST, MQTT WiFi, Z-Wave, ZigBee, Bluetooth, KNX, Enocean, Insteon, HTTP, IFTTT, …

Table 3.3 Open Source Smart Hub Platforms

3.4.2 OpenRemote

OpenRemote was started in 2008 by JBoss founder Marc Fleury and Juha Lindfors. It is an open source building control and automation framework with a large and active user and developer community. The controller software runs on top of Java Virtual Machine (JVM), which provides a wide range of options for selecting the underlaying hardware system such as Linux, macOS, Windows or Raspberry PI. The configuration interface is provided through a cloud service (designer.openremote.com). All configuration changes have to be downloaded from the cloud to the local controller installation, before they take effect. The user interface is provided in form of an iOS / Android app. Given it’s long history, OpenRemote supports a large number of building automation platforms, devices and protocols. Besides in residential homes OpenRemote is also used in commercial, industrial and municipality projects.

3.4.3 Home Assistant

Home Assistant is a vendor neutral, open source home control software platform started by Paulus Schoutsen in 2014. It is written in Python 3 and controlled through a web interface optimized for use on mobile devices. Home Assistant integrates with several hundred different software platforms, services and devices. As application protocols it uses HTTP REST and MQTT. Home Assistant is running on a local server, with all data stored in a local SQLight database. It does not provide a cloud component, but does interface with cloud services such as IFTTT.

3.4.4 openHAB

openHAB, as Home Assistant and OpenRemote, a vendor neutral, open source home control platform, was founded by Kai Kreutzer in 2011. It runs on top of Java Virtual Machine (JVM), which provides a wide range of controller system options such as Linux, macOS, Windows or Raspberry PI. It provides a web based user interface and iOS / Android apps for control and configuration. A cloud service under myopenHAB.org provides additional options for remote control as well as for integration with other cloud services such as IFTTT. By supporting Google Cloud Messaging (GCM) and Apple Push Notifications (APN) it can send push notifications to mobile phone apps.

3.4.5 Cloud (only) Controller Platforms

Along with device automation and control evolving into a large sector stretching across multiple industries under the notion of Internet of Things, IoT cloud based platforms have become available, which also target the home and building automation market. Examples are Particle (https://www.particle.io) or IFTTT (https://ifttt.com/discover). In particular IFTTT has become popular by providing a simple, intuitive cloud based solution for connecting smart devices and services, which could not interoperate otherwise. The market for cloud only based controller solutions is still in it’s infancy, however, with new mobile access technologies optimized for IoT (e.g. 5G mobile communication) it has the potential for significant growth in the years to come.

3.5 Remote Control Devices 

One of the main reasons for the increased acceptance of home automation systems in the residential segment is, that with the omnipresence of smart phones and tablets the need for dedicated automation control devices has vanished. Within a few years, literally all home automation systems on the market have introduced smartphone and tablet based control applications. In addition, advances in voice recognition have finally brought voice based control to smart homes. The remote control devices can either directly connect to the home area network (HAN) while they are inside the house, or from outside of the house via a VPN connection, via a cloud service or (not recommended) via open ports and dynamic DNS services.

3.6 Cloud Services

As outlined above, over the past years vendors have started to offer home automation functions such as rule execution or smartphone based remote control through cloud services. The degree of their integration with local home automation solutions varies from vendor to vendor. Some approaches are very cloud centric with key operational functions executed in the cloud, others use the cloud merely as a remote control and monitoring hub to be accessed while away from home. With cloud services along with mobile access technologies (3G, LTE, 5G) becoming performant, reliable and inexpensive, they have been established as a standard component of home automation solutions.

Having understood the topology of home and building automation infrastructures, in the following chapter we can now take a deeper dive into the underlaying communication processes.

3.7 Bibliography

Weiping Sun, Munhwan Choi and Sunghyun Choi (2013): 802.ah – A long range 802.11 WLAN. IEEE 802.ah: A long range 802.11 WLAN

WiFi Alliance (2016): Wi-Fi HaLow. http://www.wi-fi.org/discover-wi-fi/wi-fi-halow

Home Grid Forum (2013): Converging Technologies. Converging Technologies – Moving from HomePNA to G.hn.

IEEE Computer Society (2011): IEEE Standard for Local and metropolitan area networks Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs). http://standards.ieee.org/getieee802/download/802.15.4-2011.pdf

International Telecommunication Union (2012): Recommendation ITU-T G.9959 Short range narrow-band digital radio communication transceivers – PHY and MAC layer specifications. https://www.itu.int/rec/T-REC-G.9959

Enocean Alliance (2013): EnOcean Wireless Standard ISO/IEC 14543-3-10. https://www.enocean-alliance.org/en/enocean_standard/

The Thread Group (2017): What is Thread?  http://threadgroup.org/What-is-Thread/Connected-Home