for ZigBee Home Automation Solutions

(1)

In Supremae Dignitatis · Universit` a di Pisa

FACOLT `A DI INGEGNERIA

Corso di Laurea Specialistica in Ingegneria Informatica

Design and Development of a Software Infrastructure

for ZigBee Home Automation Solutions

Curriculum Networking e Multimedia

Supervisors:

Prof.

GIANLUCA DINI Eng.

ALESSIO VECCHIO

Author:

PERICLE PERAZZO

Session II

Academic Year 2009-2010

(2)

Dedicated to

Beatrice, who supported me in everything I did

(3)

List of Figures

3.1 ZigBee protocol stack . . . . 15

4.1 A gateway connects a WSN to an IP-based network . . . . 19

4.2 Remote access through GAL . . . . 20

5.1 Virtual Refrigerator screenshot . . . . 23

5.2 Virtual Heating Device screenshot . . . . 24

5.3 Virtual Smart Plug screenshot . . . . 24

5.4 Virtual Lamp screenshot . . . . 25

5.5 Testing configuration . . . . 26

6.1 General deployment diagram . . . . 28

6.2 Home Manager screenshot . . . . 30

6.3 Device control panel . . . . 31

6.4 Power consumption graph . . . . 35

6.5 Automatic turn off algorithm’s state diagram . . . . 37

6.6 Automatic turn off power graph example . . . . 37

6.7 Automatic overload protection examples . . . . 40

7.1 ZigApi deployment diagram . . . . 42

7.2 ZigApi general architecture . . . . 44

7.3 Device class architecture . . . . 45

7.4 Cluster interfaces and devices . . . . 46

8.1 Allowed operations against locks . . . . 66

8.2 Allowed nested locks . . . . 66

8.3 Plug’s attributes graph . . . . 89

6

(8)

LIST OF FIGURES 7

9.1 Implementors class diagram . . . . 93

9.2 Attribute database implementation . . . . 95

9.3 Two contemporaneous transactions on different devices . . . 103

9.4 Two contemporaneous transactions on the same device . . . 103

(9)

Abstract

Application fields involving domotic or industrial automation have been seeing an increasing interest from both the industry and the academia, with digital wi- reless protocols as preferred communication technologies. ZigBee is a standard communication technology which provides wireless connectivity and functional interoperability between low-cost and low-power devices of different vendors, focusing on battery life improvement. Some noteworthy employments of ZigBee technology are home, building and industrial automation as well as e-health.

This thesis work aims to the development of a software framework which provides abstraction mechanisms for communication and control operations; an example of application, called Home Manager ; and, finally, some testing tools, called virtual devices, which emulate real household appliances. The ZigBee network is accessed by means of a gateway server (GAL) provided by Telecom Italia Spa, which implements remotization and abstraction features.

In particular, the Home Manager application provides centralized home control features, power saving and power overload protection procedures, and consumption reports, turning out to be both effective and user-friendly. Finally, the framework and the application have been tested in network scenarios with up to six devices, both real and emulated.

8

(10)

Chapter 1

Introduction

In the last ten years, industry world and academia intensified their attention on applications that automatize several aspects of people’s life. Introducing informatic solutions to solve everyday problems has become an issue for a large portion of industry. These technologies make hard use of Wireless Sensor Networks (WSN), embedded systems and pervasive computing.

Pervasive computing, in particular, is defined as a human-machine interac- tion model in which information processes take place through ordinary life’s objects and activities. The key concept behind pervasive computing is that the user should not notice at all that pervasive computing is working around him. This is the reason why the term “pervasive” instead of “invasive” has been used. Pervasive computing concepts are suitable to be applied in a large veriety of application fields, from domotics to industry automation, from consu- mer electronics to e-health.

In this thesis work, an abstraction and testing software framework for per- vasive computing has been developed. It includes an application abstraction middleware, called ZigApi and a set of testing tools, called virtual devices. The framework uses ZigBee[15] as communication protocol, an innovative wireless communication technology aimed at cost and power saving. Basing on this framework, a home automation application, called Home Manager, has been developed and tested. Home Manager offers a simple and user-friendly graphi- cal interface to display devices information and power consumption graphs, and to remotely control some aspects of devices. It even performs some automatic

9

(11)

1. Introduction 10

checks and procedures, mainly focused on power saving and power overload protection.

The rest of the document is organized as follows. Chapter 2 introduces the home automation application field. Chapter 3 introduces ZigBee technology.

Chapter 4 describes the gateway abstraction layer, a middleware layer that

virtualizes the ZigBee network as a collection of web resources. Chapter 5

provides an overview of the testing framework and devices that have been

used for testing purposes. Chapter 6 describes the Home Manager. Chapters

7, 8, 9 explains the software architecture, the programming interface and some

implementation details of the applicative abstraction middleware, respectively.

(12)

Chapter 2

Home Automation

Home automation (or domotics) is a practice of enhancing the household ap- pliances automation in residential dwellings, in order to allow features that were impossible or highly expansive in the past. Home automation, together with building automation, is born during the third industrial revolution, as an application of informatic technologies in house or building environments. Home automation aims to:

• enhance the life quality,

• enhance the house security,

• reduce the power consumption,

• reduce the maintainance costs.

A household appliance having computing and communicating capabilities is called a smart device (or smart appliance). Normally, smart devices are li- kely not to have big computational resources. Home automation has to deal with this problem with ad-hoc solutions and, very often, ad-hoc communica- tion protocols. Home automation functionalities include and extend those of building automation, such as the control of closures devices, lighting devices, HVAC devices and security and surveillance systems. In addition, home auto- mation provides for more house-specific services, such as the control of home entertainment systems, pet feeding or domestic robots.

11

(13)

2. Home Automation 12

From the point of view of intelligence distribution, three possible architec- tures are possible in a home automation application.

1. Centralized architecture. Smart devices are not more than sensors and/or actuators. A centralized node coordinates the smart appliances and gene- rates the opportune orders.

2. Distributed architecture. There is no central intelligence point. The intelli- gence of the system is distributed among the devices that cooperate with each other in order to fulfill the service.

3. Mixed architecture. There is a central control point, but smart devices are also capable of cooperating independently with each other for some tasks.

This thesis work focuses on centralized architecture. The central control point may be a personal computer or a dedicated hardware with some computational resources.

The most used communication mediums in home automation are electrical wiring and radio frequency. Electrical wiring offers higher bit-rates but requires higher installation costs. The idea is using already installed cable networks, for example energy supply or telephony networks, in old houses, whereas installing new ad-hoc networks for new houses. On the contrary, radio frequency offers very cheap installations and low bit-rates. The radio frequency solution is the most followed in last years, for old houses as well as for new ones.

Another key requirement, especially for wireless-based home automation, is battery saving. Battery-powered smart appliances must have a very low power consumption, both for computing and communicating functionalities, in order to increase batteries’ lifes. Good battery consumption levels are considered those which permit years-long batteries lifes.

This thesis work uses IEEE 802.15.4[7] standard protocol in order to provide

wireless, low-cost, ultra-low-battery consuming home automation solutions.

(14)

Chapter 3

ZigBee

In order to permit communication between the smart devices and between the coordinator and the smart devices, a communication protocol is needed. The protocol must have the following properties.

1. Be standard. Not only on data-link and routing functionalities, but also on application-related functionalities. This is needed because different devices from different vendors and equipped with different applications should work together in the same network.

2. Be wireless. The cost of installing and maintaining new cable networks appears more and more unreasonable as wireless technologies are being developed. Wireless communication systems are now mandatory for new employments where high transamission rates are not a strict requirement, like for home automation.

3. Be low-battery consuming. Wireless nodes are often battery-powered, but the life-time of such batteries has to be as long as possible, in order to lower maintenance costs.

4. Be extensible. It is infeasible to provide a standard for each smart appliance that will be employed in a house, and for its behaviour. Thus, the standard must be extensible and customizable (within some constraints).

ZigBee[15], proposed by ZigBee Alliance, is a protocol that addresses these objectives. ZigBee is defined by ZigBee Alliance as a “very low-cost, very low-

13

(15)

3.2. Physical, medium access control and network layers 14

power consumption, two-way, wireless communications standard”. Its applica- tion fields are “consumer electronics, home and building automation, industrial controls, PC peripherals, medical sensor applications, toys, and games.”

3.1 ZigBee stack overview

ZigBee protocol stack is divided in four main layers.

1. Physical layer, (PHY ). Using the antennas, it solves the problem of trans- forming data bits in radio waves, transmitting and receiving them.

2. Medium access control layer, (MAC ). Basing on physical layer’s services, it offers frame-based communication between neighbour nodes. Neigbour nodes are those which are able to directly communicate with each other, without the intervention of third nodes. Since the radio frequency is a shared medium, collision issues have to be addressed.

3. Network layer, (NWK ). Basing on medium access control layer’s services, it offers frame-based communication between non-neighbour nodes.

4. Application layer, (APL). Basing on network layer’s services, it offers a large and extensible set of high-level functionalities that depend on the kind of device and the application.

Figure 3.1 shows the complete ZigBee protocol stack.

3.2 Physical, medium access control and network layers

ZigBee relies on the physical and medium access control layers provided by IEEE 802.15.4 [7] standard protocol. It is a wireless protocol focused on sim- plicity and very low battery consumption. It permits hub-and-spoke as well as mesh topologies. A 64-bit address is assigned to each communicationg node.

These addresses are globally unique and permanently stored inside the com-

munication modules. An IEEE 802.15.4 network can be beacon-enabled or not-

beacon-enabled, whether the communications are synchronized with a beacon

tecnhique or not. The communications inside a not-beacon-enabled networks

(16)

3.2. Physical, medium access control and network layers 15

Figure 3.1: ZigBee protocol stack

follow a CSMA/CA[8] contention paradigm, similar to that used by WiFi[9].

ZigBee does not use the beacon mode of IEEE 802.15.4, as a matter of fact, ZigBee networks are always contention-based.

The network layer of ZigBee assures the connectivity between distant nodes, that may not directly communicate at physical layer. From the network layer’s point of view, nodes are cathegorized in three types.

1. Coordinator node. It is unique inside a network. It creates the ZigBee network, elects the eventual router nodes, coordinates the overall commu- nication of the network, and partecipates to routing. It must have higher computational and memory resources than the other nodes. It should be line-powered.

2. Router nodes. They partecipate to routing and coordinate the communi- cations inside their network areas. They should have higher computational and memory resources then device nodes. They should be line-powered.

3. Device nodes. They do not partecipate in routing. They can have reduced

computational and memory resources. They can be battery-powered.

(17)

3.3. Applicative layer 16

The coordinator node assigns a 16-bit network address to each node. These addresses are unique within a ZigBee network. Routing procedure uses an AODV-like algorithm[11]. In this way, the routing information that a ZigBee coordinator or router has to maintain is minimized.

3.3 Applicative layer

ZigBee layer is divided in two sublayers.

• Application Support Sublayer (APS). It performs the communication mul- tiplexing to the different applications running on the same device. Each multiplex entry is identified by an 8-bit identifier called end point. Besides, this sublayer performs some security-related management operations and provides a header with standard fields that will be used by the higher sublayer. These fields include cluster ID and profile ID, discussed later.

• Application Layer properly said, sometimes called ZCL layer (from ZigBee Cluster Library[14]). It realizes the actual applicative communication.

Given the extreme heterogeneity of devices, ZigBee Alliance did not define dedicated applicative protocol for each of them. On the contrary, it defined general and reusable sets of command and attributes, called clusters, to interact with single aspects of devices. Examples of ZigBee clusters are On/off cluster to interact with devices that can be turned on or off, Thermostat cluster to interact with devices owning a thermostat, Fan control cluster to interact with devices that have a fan as a part of a heating/cooling system, etc. Each ZigBee cluster is identified by a 16-bit number called cluster identifier. The commands and the attributes of a standard cluster are defined in the ZigBee Cluster Library document[14]. Other custom clusters can be defined by manufacturers.

A device can obviously implement more than one cluster.

Profiles define which device type has to implement which cluster and how.

Examples of profiles are Home Automation profile[13] for domotic applications,

or Smart Energy profile[16] for power-monitoring and billing applications. Each

ZigBee profile is identified by a 16-bit number called profile identifier. Standard

profiles are described in profile documents. Other custom profiles can be defined

by manufacturers.

(18)

3.4. ZigBee attributes 17

3.4 ZigBee attributes

A ZigBee attribute, owned by a particular device, is defined by ZigBee Cluster

Library document as “a data entity which represents a physical quantity or

state”. Each attribute has a type and a value. An attrbiute owned by a devices

can be written or read by the coordinator or by other devices, with specific

standard commands. Periodically and/or after a significative change of its va-

lue, a device can report an attribute to the coordinator (or another statically

determined device), by means of an unsolicited message. This mechanism is

called attribute reporting. Attribute reporting can be configured by a specific

command. For example, it is possible to set the frequency of periodic reports.

(19)

Chapter 4

Gateway infrastructure solution

A gateway is a (mobile or fixed) node that is able to interconnect a wireless sensor network to IP-based backend systems, as shown in figure 4.1. A gateway is needed for several reasons.

• Remote applications may want to access and operate on the WSN.

• Applications are often IP-capable (because IP is a widely used techno- logy). More seldom they implement WSN communication capabilities.

• The WSN may need to be accessed by more than one application. Local and remote applications may want to access the WSN at the same time.

On the gateway machine a process is executed that translates IP-based requests into WSN operations and viceversa. This process is called gateway abstraction layer.

4.1 Telecom Italia gateway abstraction layer

The gateway abstraction layer used for this thesis work is called GAL[2] (Ga- teway Abstraction Layer ), provided by Telecom Italia Spa. The main functio- nalities of GAL are the following.

1. Virtualizing the low-level services offered by the communication modules.

In this way, it permits fast development of applications.

2. Offering a unifed interface for heterogeneous communication modules.

18

(20)

4.2. GAL XML interface 19

Figure 4.1: A gateway connects a WSN to an IP-based network

3. Offering the possibility of accessing the ZigBee network both locally or remotely, in a secure way.

Figure 4.2 shows an example of a local application and a remote application that access to a ZigBee network through GAL.

GAL offers an XML-over-HTTP Web-like interface to the applications, and accesses the ZigBee network through a wireless-capable hardware, called com- munication module. In this thesis, ETRX2 USB sticks[12] provided by Telege- sis, have been used as communication modules.

GAL can run in coordinator, router or device mode in order to play the correspondant roles in the ZigBee network. From now on, an instance of GAL in coordinator mode, will be called GAL, whereas an instance of GAL in device mode will be called device GAL. Router mode has not been used in this work.

4.2 GAL XML interface

The XML protocol of GAL follows a REST[5] paradigm. Operations (like sen-

ding a ZigBee message) are performed by HTTP requests from the application

to the GAL, whereas events (like receiving a ZigBee message) are notified

through HTTP requests from GAL to the application.

(21)

Figure 4.2: Remote access through GAL

The following XML document is an example of request to send a ZigBee message.

<?xml version="1.0" encoding="UTF-8"?>

<Message>

<RXMessage>

<SourceURL>zigbee://000DEB0000001001:01</SourceURL>

<DestinationURL>zigbee://0000:01</DestinationURL>

<ProfileId>C044</ProfileId>

<ClusterId>06</ClusterId>

<MsgId>1</MsgId>

<Payload>000B0000</Payload>

</RXMessage>

</Message>

The following is an incoming device announcement example (a notification

(22)

about a new device that joined the network).

<?xml version="1.0" encoding="UTF-8"?>

<WSNNodes>

<WSNNode FullAddr="0021ED0000045101" ShortAddr="0000">

<NodeID>/wsnnodes/node0000</NodeID>

</WSNNode>

</WSNNodes>

The following is an incoming message notification example.

<?xml version="1.0" encoding="UTF-8"?>

<Message>

<RXMessage>

<SourceURL>zigbee://0021ED0000045101:01</SourceURL>

<DestinationURL>zigbee://0000:01</DestinationURL>

<ProfileId>C044</ProfileId>

<ClusterId>06</ClusterId>

<MsgId>0</MsgId>

<Payload>0100</Payload>

</RXMessage>

</Message>

GAL interface can be accessed directly through HTTP, or alternatively by a

small wrapper middleware, called rest4Gal.dll. The wrapper translates function

calls into outcoming HTTP requests, and incoming HTTP requests into asyn-

chronous function callbacks. It is compiled in CIL[4] (Common Infrastructure

Language) and it is platform-independent.

(23)

Chapter 5

Physical and virtual devices

The smart devices are smart household appliances that will work and cooperate in a home automation scenario. This chapter illustrates the types of smart de- vices used in application abstraction middleware and Home Manager testings.

5.1 Telecom Italia smart plugs

A smart plug is an electric outlet with metering and communicating capabili- ties. It is able to perform the following tasks.

1. Measuring the instantaneous electric power consumption and the cumu- lative electric energy consumption over a time interval.

2. Communicate these measures to the coordinator, with ZigBee attribute reporting technique.

3. Receive turn off/turn on commands from the coordinator.

For this thesis work, smart plugs provided by Telecom Italia Spa have been used. These smart plugs implements the On/off cluster and the Analog input (basic) cluster in a non-standard way, under a custom ZigBee profile.

5.2 Virtual devices

In order to simulate the large disponibility of ZigBee home appliances that can be employed in a house, and to offer more exhaustive testing possibilities, a set

22

(24)

5.2. Virtual devices 23

Figure 5.1: Virtual Refrigerator screenshot

of virtual devices has been developed. A virtual device is an application that emulates the functionalities of a ZigBee home appliance. It can be run on a general purpose computer that can be or be not the same in which the Home Manager is running. It can access the ZigBee network through a device GAL.

Four smart devices has been developed.

• Virtual Refrigerator, emulating a refrigerator.

• Virtual Heating Device, emulating a appliance with heating capabilities, like a centralized heating system or a single electric radiator.

• Virtual Smart Plug, emulating a Telecom Italia smart plug.

• Virtual Lamp, emulating a lighting device.

The figures 5.1, 5.2, 5.3, 5.4 show screenshots respectively of Virtual Refrige- rator, Virtual Heating Device, Virtual Smart Plug and Virtual Lamp.

Virtual devices emulate physical devices in the following features.

(25)

Figure 5.2: Virtual Heating Device screenshot

Figure 5.3: Virtual Smart Plug screenshot

(26)

Figure 5.4: Virtual Lamp screenshot

• Physical quantities and conditions. Like the internal temperature of a refrigerator. For testing reasons, these quantities are directly under user’s control.

• Mechanisms offered by the physical device, like a cooling system of a refrigerators.

• Real controls, like the cooling intensity of a refrigerator.

• Some particular conditions and events, like hardware failures.

Figure 5.5 shows a classic testing configuration, where a virtual device and the Home Manager are executed on the same machine.

5.2.1 Virtual device utility middleware

Some functionalities are common between all the virtual devices. For example,

the graphical look-and-feel, some standard GUI controls, or the implementation

of some common ZigBee clusters. In order to provide a unique implementation

(27)

Figure 5.5: Testing configuration

of these common functionalities, a virtual device utility middleware has been developed, called VirtualDeviceUtils.dll. The virtual device utility middleware is used by Virtual Refrigerator, Virtual Heating Device, Virtual Smart Plug and Virtual Lamp, and can be used for future fast developing of new virtual devices. It offers the following features.

• A basic main window class. Individual virtual devices can derive it and ob- tain a specialized main window class, that inherits some standard controls and a standard graphical layout. The standard controls are those aimed to operate on the connection with the device GAL.

• The implementation of attributes-related commands. Specifically the at- tribute reading, the attribute writing, the attribute reporting and the reporting configuration commands.

• The implementation of some standard ZigBee clusters. Specifically the Basic cluster and the Identify cluster.

• Some basic functionalities that can be used by virtual device’s developer in

order to implement other clusters, like methods for parsing or formatting

ZigBee messages.

(28)

Chapter 6

Home Manager

In order to provide home automation services, a hub-and-spoke structure can be used, with a centralized manager entity and the smart household appliances as the spokes. The network that includes the manager and the devices inside the house is called home network. In particular, the manager makes it possible to control the devices inside the home network. Control on devices is possible by means of operations, configurations or queries performed by the manager, either after a user’s order or automatically, according to a particular managing policy. The manager entity can be either a software application, installed on a computer, or a processing hardware. An example of such application, called Home Manager, has been developed.

The Home Manager and the smart devices communicate over a ZigBee net- work, allowing to address devices installation and mantenance in a more flexible and cost-effective way. The Home Manager refers to ZigBee Home Automation profile[13], which specifies the ZigBee clusters that are likely to be used in a do- motic application. Fig. 6.1 provides an overall view of the system architecture.

In particular, we suppose to have a special node named network coordinator, which is able to act as coordinator in a ZigBee network. Within the coordi- nator, both the Home Manager application and the gateway abstraction layer middleware (see chapter 4) have been installed. As depicted in the picture, users do not directly interact with the smart devices, but they are supposed to establish an application level session with the Home Manager application.

Moreover, the Home Manager provides the users with control and monitoring

27

(29)

6.1. Information’s persistance 28

Figure 6.1: General deployment diagram

functionalities as described in section 6.3, and makes use of the ZigBee stack by means of the GAL middleware discussed in chapter 4. Finally, communi- cations can be established between the network coordinator and the ZigBee smart appliances, thanks to the ZigBee protocol stack. Figure 6.1 shows the deployment diagram of the entire system.

6.1 Information’s persistance

The hardware where the Home Manager is executed can sometimes turn off.

This happens because:

• it is a personal computer, or a machine that is not supposed to be always on;

• it is a dedicated hardware that is supposed to be always on, but some- times can turn off, due to several reasons like failures or power supply interruptions.

Anyway, Home Manager needs a mechanism to make some information per-

sistent, so that the user will not lose them between consecutive executions of

(30)

6.3. Program features 29

the program. An XML document, stored on a file, has been used. Among other information, the background image of the home map and the physical posi- tions of the devices are stored. This is why the file will be called “map file”.

However, other information not strictly related to the map, like device’s names or textual notes, is stored on the map file.

6.2 Graphical interface

Home Manager is likely to be used by home users, eventually unskilled. For this reason, the program must provide a simple and intuitive graphical interface, that permits even an inexperienced customer to use and configure the program features. Home Manager has a user-friendly graphical interface that provides some logically complex operations by means of simple clicks and drag-and-drop actions.

The graphical interface is splitted in two parts. In the upper part the user sees the information about the whole network, such as the map, the global power consumption indication and the list of detected devices. In the lower part there is a box containing the information about the specific selected device, called device control panel. Figure 6.2 shows a screenshot of Home Manager.

The screenshot in figure 6.3 shows a device control panel, which becomes visible whenever the user selects a device.

6.3 Program features

Home Manager is an application that permits a domestic user to manage a Zig- Bee network of smart household appliances. Its main objectives are centralized control, power saving and power overload protection. Home Manager offers the following features:

• Gateway connection and disconnection.

• New devices detection, both in automatic or manual mode, and their initialization.

• Devices first identification.

(31)

6.3. Program features 30

Figure 6.2: Home Manager screenshot

• Persistent name assignment to devices.

• Placing of devices on a bidimensional map (map placing).

• Association between a device and its relative supply smart plug (power binding), in order to display power consumption statistics and perform power-saving policies.

• Saving and loading from persistent memory of the map and some infor- mation.

• Attribute reports collecting and graph building of the trend over time of a certain quantity (temperature, power consumption, etc.).

• Centralized control for monitoring devices’ information and executing some operations. For example, changing the thermostat setpoint level of a heating device.

• Automatic execution of some procedures oriented to power-saving and

power overload protection.

(32)

6.4. Power bindings 31

Figure 6.3: Device control panel

Home Manager can manage the following devices:

• Telecom Italia smart plugs,

• refrigerators,

• heating-capable devices,

• lighting devices.

6.4 Power bindings

The user can notify the Home Manager about the association between a device

and the relative supply smart plug. Such associations are stored on the map file,

so they are persistent from an execution to the next of the program. A device

can receive power supply by no more than one smart plug; on the the contrary,

a smart plug can give power supply to several devices. In order to avoid very

complex configurations (trees of bindings, cycles, etc.) Home Manager does not

(33)

6.6. Device initialization 32

permit a smart plug to receive power supply by another smart plug. However, smart plugs are supposed to be installed behind wall sockets, in a way that the previous scenario can never happen. Power bindings setting is essential for the Home Manager to perform automatic power saving and power overload protection policies. See sections 6.13 and 6.14 for further details.

6.5 Gateway connection and disconnection

As its execution starts, the Home Manager enters initialization phase, in which it estabilishes the communication session with the gateway and automatically detects and initializes the reachable smart devices. If one of these devices, for some reason, enters the network after the initialization phase has been com- pleted, Home Manager offers two procedures to detect its presence: automatic or manual detection. Automatic detection is performed without user’s parti- cipation; the new device announces itself to the coordinator and the device initialization procedure is automatically started. Alternatively, the user can orders Home Manager to perform a manual detection, clicking on Actions → Detect new devices.

Manual detection is mandatory for virtual devices. This happens because, when the device GAL announces itself to the coordinator, the virtual device application is likely to be off or not connected to it. Thus, Home Manager cannot retrieve the value of Model Identifier attribute (see section 9.2) and the automatic detection fails. Once the virtual device application is running and connected to its device GAL, a manual detection can be successfully performed.

Disconnection from the gateway is automatically performed when the Home Manager execution terminates.

6.6 Device initialization

Every time a new device is detected, Home Manager initializes it. The device initialization procedure consists of two operations:

• Attributes retrieval: the values of all the relevant attributes for the Home

Manager working are retrieved. For example the internal temperature of

(34)

6.8. Naming 33

thermostat owner devices, or power consumption information of smart plugs.

• Reports configuration: the initial options for attribute reports are set. For example the reports’ frequency.

If, following a manual detection or in the program initialization procedure, more than one device is detected, their initialization is performed in parallel.

As a matter of fact, Home Manager takes advantage of the multi-threading properties of application abstraction middleware (see sections:synchronization) to reduce the time complexity of devices initialization from O(N) to O(1), where N is the number of new detected devices.

6.7 First identification

Once a new device in the network has been detected and correctly initialized, its symbol appears on the detected devices list. Although it is possible for the Home Manager to detect new devices and their type, their physical position cannot be determined. The Home Manager is able to show only a list of detected devices specifying their type, with no information about their placement. However, the user can identify a single device among different detected devices of the same type, by means of an out-of-band identification procedure, such as a physical signal perceptible by humans, like a sound or a blinking light, produced by the device. By interacting with the Home Manager, ther user can manually ask a single device to reveal its identity, and then associate a unique information, such as a name or a label. In order to perform identification, Home Manager tells the device to reveal itself by means of a command included in the standard ZigBee Identify cluster.

6.8 Naming

After having correctly identified a device, the user can give a name to it, pos-

sibly an unique and easily-recognizable name, so that no further identification

operations must be performed. This name is saved in the map file, so it’s per-

sistent between subsequent executions of Home Manager.

(35)

6.11. Attribute reports gathering and graph building 34

6.9 Devices map placing

In order to make easier the devices identification, besides names, the user can place the devices’ symbols on a bidimensional map, depicting the house plant, previously loaded from a bitmap file. The map and the placed symbols are shown in the graphical interface. The map placing of a device is performed by means of a simple drag-and-drop operation from the detected devices list to a point on the map. The symbol of the device will now appear at the specified position. The placing point can be moved by a further drag-and-drop from a point to another of the map. The symbol of a smart plug is simplified by a green empty circle, while the symbol of a lamp is simplified with a dot, light yellow if turned on, grey if off.

6.10 Power bindings set up

In order to create a power binding, the user can click on (Menu device) → Powered by. . . → (Name of the supply smart plug). Once a power binding is set up, it is shown on the map as a green line that joins the device to the smart plug.

6.11 Attribute reports gathering and graph building

The attribute reports coming from devices are stored as couples (value, know- time) called samples. The know-time is the temporal indication of the report’s arrival instant (see subsection 8.3.5). These couples are collected in a log. A log is used to build a graph of a physical quantity’s temporal trend. These graphs are shown on the graphical interface, on the device’s control panel.

Home Manager shows the graph of the internal temperature measured by the thermostat of refrigerators and heating devices. For smart plugs, two graphs show the electric power and energy consumption. If a power binding is set for a particular device, its control panel shows the electric power consumption too, obtained from the associated smart plug.

The scale of the graphs’ time axis can be changed from program options,

accessible through Tools → Options. The scale of the measures axis is automa-

(36)

6.12. Centralized control 35

Figure 6.4: Power consumption graph

tically set basing on the biggest shown sample. Besides, the freshest sample’s value in digits, with the measurement unit indication, is shown on the graphs.

Figure 6.4 shows a graph of a smart plug’s power consumption.

6.12 Centralized control

In addition to graphs, on the device control panel the user can view some real-time information and perform some operations on the device itself.

For heating devices it is possible to view thermostat setpoint level and change it, as well as for refrigerators. For refrigerators it is possible to view the door state (open/closed) and the content with the relative expiration dates.

The content items that turn out to go off are shown in red.

A smart refrigerator is supposed to know its content by means of RFID labels attached to the products. Since the retrieval of the content informa- tion is generally a high-bandwidth-consuming operation, it is not performed periodically, but only when Home Manager detects the closing of the refrige- rator’s door. At this moment, the domestic user has surely finished changing the content. In this way, the traffic quantity on the ZigBee network can be drastically reduced.

Finally, for the lamps and smart plugs it is possible to view and change

their on/off state. For the smart plugs it is possible to set the automatic turn

off functionality (see chapter 6.13).

(37)

6.14. Power overload protection 36

6.13 Smart plug’s automatic turn off

Some devices consume electric power even when off, due to, for instance, leds or always-working microprocessors. If the user thinks this consumption being useless, he/she can set the automatic turn off feature on the supplying smart plug.

If this functionality is enabled, Home Manager detects the beginning and ending instants of the device’s work, by comparing the power consumption with specific thresholds. Whenever Home Manager detects that a device has stopped working, it automatically turns off the associated smart plug. The user must perform manually the successive turn on order, either through a smart plug control (if such control is provided) or through the smart plug’s control panel on the Home Manager’s interface. Figure 6.5 shows the state diagram realizing this functionality. Both the working and the end-working power thresholds are configurable from program options. The distance between them can be made larger, in such a way to ignore eventual spurious power consumption fluctuations. In figure 6.6, a possible power graph of a device controlled by automatic turn off algorithm is shown.

6.14 Power overload protection

The traditional power overload protection is performed by domestic electri-

city meter. Whenever it detects a global power consumption that exceedes a

safety threshold (determinated often by the contract’s type), it turns off the

electric power of the entire house. These behaviour can be annoying for the

user, especially if the house contains devices for which a sudden black-out can

cause drawbacks. These devices are called non-interruptible devices. Examples

of these devices are personal computer or some medical equipment. Besides,

non-interruptible devices are rarely responsible for overloads, thus their power

off is still more undesirable. There are other types of devices for which sudden

supply interruptions do not cause immediate damages, but can be likewise an-

noying to the user. For instance, lighting devices are almost never responsible

for overloads, but can cause inconveniences if suddenly turned off at night. In

Home Manager environment, they are considered non-interruptible too.

(38)

Figure 6.5: Automatic turn off algorithm’s state diagram

Figure 6.6: Automatic turn off power graph example

(39)

Home Manager offers a smarter mechanism of overload protection. Since it knows the individual power consumption of each device and the kind (interrup- tible/ non-interruptible) of such devices, it can turn off only those interruptible devices that are responsible for the overload. In paricular, devices are divided in three categories.

1. Non-interruptible devices, for example lighting devices.

2. Intensity-lowerable devices, for example refrigerators, whose cooling level can be lowered in order to reduce power consumption, but never turned off.

3. Interruptible devices, for example heating devices.

An overload protection power threshold, preferibly lower than the one pro- vided by the home meter, is configured in the Home Manager. The overload protection mechanism takes place every time the global power consumption exceedes the threshold. In such a case, Home Manager takes the following countermeasures (in the following order).

1. Intervention on interruptible devices. It searches for the most consuming smart plug among those which:

• power at least one device; and

• power interruptible devices only.

If such smart plug is found, it is automatically turned off and an alert message is displayed.

2. Intervention on lowerable devices. Otherwise, Home Manager searches for the most consuming intensity-lowerable device. If such device exists, it is automatically lowered in intensity. For example, the thermostat tem- perature of a refrigerator is raised to the minimum level. Then, an alert message for the user is displayed.

In order to apply this algorithm, the individual power consumption of

each lowerable device needs to be known. If a single smart plug powers

more than one device, this is not possible. In such a case, all the lowe-

rable devices powered by the smart plug are considered a single lowerable

(40)

device (cumulative lowerable device), and its power consumption is the cumulative power consumption measured by the smart plug. Lowering a cumulative device means lowering each lowerable device it includes.

3. User alert. Otherwise, if Home Manager can’t make interventions on in- terruptible or lowerable devices, an alert for the user is displayed. The user will take the necessary countermeasures.

In figure 6.7, two different examples of overload protection are shown. On

the left of each smart plug, a vertical red bar is shown, representing its current

power consumption. The taken countermeasures are shown in red. The red ×s

represent the turning off of a smart plug. The red ↓s represent the lowering of

a lowerable device. In the first scenario, the upper smart plug is powering two

interruptible devices. The intervention on interruptible devices can be perfor-

med and the smart plug is turned off. On the contrary, in the second scenario

the upper smart plug powers an interruptible device and a refrigerator, that is

not interruptible. Since Home Manager can’t act on interruptible devices, an

intervention on lowerable devices is performed on the lower refrigerator, which

is the more consuming one. In each cases, an user alert is displayed after the

automatic countermeasure.

(41)

Figure 6.7: Automatic overload protection examples

(42)

Chapter 7

ZigApi architecture

ZigApi is an extensible middleware offering high-level abstractions for the ma- naging of ZigBee networks at coordinator side. It hides the applicative protocol of ZigBee and offers a per-device and per-cluster view, so that the programmer has not to know ZigBee applicative communication standards. The architec- tural and procedural solutions adopted for ZigApi can be used for any com- munication technology (other than ZigBee) dealing with smart devices. ZigApi is a software dynamic-link library, written in C#[3] and having the following characteristics.

1. Extensibility. ZigApi functionalities are extensible without changing Zi- gApi itself. An application using ZigApi can define new clusters and de- vices (see section 9.6).

2. Multitasking. ZigApi is multi-thread-oriented and its interface methods are thread-safe.

3. Portability. ZigApi is compiled in Common Infrastructure Language[4]

(CIL), a cross-platform pseudo-assembly language, standardized by ECMA International.

In figure 7.1, the deployment diagram of ZigApi is shown, supposing the Home Manager and the gateway running on the same machine.

41

(43)

7.1. Offered services 42

Figure 7.1: ZigApi deployment diagram

7.1 Offered services

From now on, with the term programmer we refer to the ZigApi employer, who uses it in order to develop coordinator-side ZigBee applications.

ZigApi offers the following services.

1. Architectural abstraction. ZigApi defines a Network object and Device objects. In this way, every physical object in a ZigBee scenario (network, devices, etc.) is represented by a sofware object.

2. Protocol abstraction. ZigApi hides the implementation details of the gate- way communication protocol and of the ZigBee applicative protocol.

3. Synchronization abstraction. ZigApi controls the synchronization of Zig- Bee transactions (see section 9.3) and mutual exclusion between incom- patible operations (see section 9.3).

4. Attribute managing. ZigApi implements a database service for ZigBee at-

tributes. Thus, the programmer is not required to implement a similar

(44)

7.2. Architectural overview 43

functionality in his/her applications.

7.2 Architectural overview

A Network object represents a ZigBee network. The programmer can operate on it with methods which affect the whole network, like connection or discon- nection from the gateway (Connect and Disconnect ), detection of connected devices (Inquiry), broadcast operations, etc. If the application operates on more than one ZigBee network, the programmer can create more than one Network object. A GAL instance can connect to at most one Network instance and vice- versa. Thus, the programmer has to execute a GAL instance for every Network object.

A Network object maintains a collection of Device objects, each represen- ting a (physical or virtual) device connected to the network. Such collection is updated everytime the set of connected devices changes, that is everytime devices enter or leave the network. Each device is identified by a unique IEEE 802.15.4 64-bit address. The programmer can obtain a device object by means of its address, and then perform operations on it. Figure 7.2 shows the general class diagram of ZigApi.

Network maintains a MessageCoordinator object, responsible for transac- tions’ synchronization, and a ReaderWriterLockSlim, responsible for mutual exclusion on Network accesses. RxMessage and TxMessage respectively repre- sents and incoming and outcoming ZigBee applicative messages. ZclException represents an error in the ZigBee applicative protocol, while GatewayCom- municationException represents an error in the gateway communication. Zi- gApiTimeoutException represents an exceeded time-out exception in a ZigBee applicative communication. The classes MessageCoordinator, RxMessage and TxMessage are not used directly by the programmer, unless he wants to extend the middleware (see section 9.6).

The Device class follows the Composite design pattern[6]. It is an abstract

class, concretized by its derived classes, each representing a different type of

ZigBee device. Device class exports a set of standard methods, generally sup-

ported by all devices, like attribute reading or attribute reports configuration.

(45)

7.3. Devices and clusters implemented by ZigApi 44

Figure 7.2: ZigApi general architecture

Derived classes of Device can export more specific methods.

Each ZigBee standard cluster has a related class-interface (cluster interface), in such a way that a device implementing a particular cluster is represented by a Device object implementing the related interface. Figure 7.3 shows an example of this architecture. In the example, HeatingDevice extends the Device class and exports one cluster interface for each ZigBee cluster it implements.

7.3 Devices and clusters implemented by ZigApi

ZigApi implements four kinds of devices:

1. Plug. Represents a Telecom Italia’s smart plug, with metering and on/off capabilities.

2. Refrigerator. Represents a smart refrigerator, with content knowing and thermostat capabilities.

3. HeatingDevice. Represents a smart heating device, with thermostat capa-

(46)

7.3. Devices and clusters implemented by ZigApi 45

Figure 7.3: Device class architecture

bilities.

4. Lamp. Represents an lighting device, with on/off capabilities.

Other devices can be added inside or outside the middleware (see section 9.6).

ZigApi implements five cluster interfaces for standard ZigBee clusters:

• IBasicCluster, implemented by devices exporting Basic cluster. Includes generic functionalities, supported by every smart device.

• IIdentifyCluster, implemented by devices exporting Identify cluster. In- cludes identification functionalities.

• IAlarmsCluster, implemented by devices exporting Alarms cluster. In- cludes devices’ alarms and notifications functionalities.

• IOnOffCluster, implemented by devices exporting On/off cluster. Includes on/off functionalities.

• IThermostatCluster, implemented by devices exporting Thermostat clus- ter. Includes thermostat-related functionalities.

ZigApi implements one cluster interface for non-standard ZigBee clusters:

(47)

7.4. Programming examples 46

Figure 7.4: Cluster interfaces and devices

• IBoxCluster, implemented by devices exporting Box cluster. Includes func- tionalities related to a container that knows its content (by RFID techno- logy, for example).

Other clusters can be added inside or outside the middleware (see section 9.6).

Table in figure 7.4 shows all the clusters implemented by every device.

7.4 Programming examples

In this section, some ZigApi usage examples will be introduced. The examples are written in simplified pseudocode. Refer to chapter 8 for the actual ZigApi interface.

Pseudocode 7.1 shows how the programmer can create a network, search for reachable devices, and print to screen their addresses and types. The Net- work.Connect operation estabilishes a connection with the gateway and contex- tually searches for reachable devices. The parameter is a time-out in millise- conds for the searching operation. The search is performed by broadcasting an inquiry command, and then waiting for replies from the devices.

The Network.Disconnect operation closes the connection with the gateway.

The pseudocode 7.2 shows how the programmer can turn off all the de-

vices that implement the On/off cluster (for example: smart plugs, lighting

devices). IOnOffCluster.Off is a ZigBee standard command included in the

On/off cluster. The parameter represents a time-out for the command’s reply,

in milliseconds. If such time-out is 0, a reply-less command is sent, meaning

(48)

Algorithm 7.1 Connection example void main() {

Network theNetwork = new Network("127.0.0.1:9000");

theNetwork.Connect(6000);

foreach(Device dev in theNetwork.Devices) { Console.Write(dev.LongAddress);

switch(dev.Type) { case Plug:

Console.WriteLine(" is a smart plug.");

break;

case Refrigerator:

Console.WriteLine(" is a refrigerator.");

break;

case Lamp:

Console.WriteLine(" is a lamp.");

break;

case HeatingDevice:

Console.WriteLine(" is a heating device.");

break;

} }

theNetwork.Disconnect();

}

Algorithm 7.2 Turn off example ...

foreach(Device dev in theNetwork.Devices) { if(dev is IOnOffCluster) {

((IOnOffCluster)dev).Off(0);

} }

(49)

that the device is not forced to send a reply.

7.4.1 Attributes

In ZigApi, a ZigBee attribute is identified by means of a string, called Attribute name. The pseudocode 7.3 shows how the programmer can read and write attri- butes. ReadAttr, ReadAllAttr, GetAttrVal, IsKnownAttrVal and WriteAttr are standard methods provided by all Device objects. ReadAttr retrieves the value of a particular attribute from the device, while ReadAllAttr retrieves the value of all attributes. They both are methods that always generate ZigBee network traffic. They can’t be reply-less, so the time-out parameter can’t be 0. If these methods succeed, the value of the attribute is returned and stored in a ZigBee internal database. GetAttrVal returns a value of an attribute previously stored in the database. It does not generate ZigBee traffic. IsKnownAttrVal returns true whether the value of the specified attribute is present in the database.

7.4.2 Attribute reports

The pseudocode 7.4 shows how the programmer can receive attribute reports from the devices. SetAllAttrReportCallback sets a handler function that ZigApi will call every time a report of any attribute arrives from the specified device.

The handler function is called asynchronously from the programmer’s code, by a dedicated thread, so the programmer has to pay attention to threading issues.

7.4.3 Network locking

In a real network, the list of connected devices can dinamically change when

a device enters or leaves the ZigBee network. These changes are asynchro-

nous from the programmer’s code. Even the values of a device’s attributes can

asynchronously change, due to attribute reports. If the programmer wants the

network or the attributes of a particular device not to change within a section

of the program, lock operations have to be performed. Pseudocode 7.5 shows

how the programmer can protect a program section from asynchronous net-

work changes. The try-finally block ensures the Network.Unfreeze operation is

(50)

Algorithm 7.3 Attribute’s read and write example.

...

Device dev = theNetwork.DeviceAt(address);

switch(dev.Type) { case Plug:

uint powerCons = (uint)dev.ReadAttr("PowerConsumption", 5000);

Console.WriteLine("Plug: PowerConsumption={0}", powerCons);

break;

case Lamp:

dev.ReadAllAttr(5000);

Console.WriteLine("Lamp: On/off={0}, ModelIdentifier={1}", (bool)dev.GetAttrVal("OnOff"),

(string)dev.GetAttrVal("ModelIdentifier"));

break;

case Refrigerator:

dev.WriteAttr("OccupiedCoolingSetpoint", (short)600,

5000); // Setting the thermostat temperature to 6C

Console.WriteLine("Refrigerator: OccupiedCoolingSetpoint={0}", (short)dev.GetAttrVal("OccupiedCoolingSetpoint"));

break;

case HeatingDevice:

if (dev.IsKnownAttrVal("LocalTemperature"))

Console.WriteLine("HeatingDevice: LocalTemperature={0}", (short)dev.GetAttrVal("LocalTemperature"));

else

Console.WriteLine("HeatingDevice: LocalTemperature=<unknown>");

break;

}

(51)

Algorithm 7.4 Reports receiving example void main() {

Network theNetwork = new Network(

"127.0.0.1:9000",

acceptAsyncReports=true);

foreach(Device dev in theNetwork.Devices)

dev.SetAllAttrReportCallback(reportCallback);

Console.WriteLine(

"Receiving attribute reports... (type ’quit’ to exit)");

do {

string inp = Console.ReadLine();

}

while(inp != "quit");

theNetwork.Disconnect();

}

void reportCallback(

Device dev, string attrName, object value, int valueKnowTime) {

Console.WriteLine("Attribute report received from {0}: {1}={2}", dev.LongAddress,

attrName,

value.ToString());

}

(52)

Algorithm 7.5 Network freeze example

Network theNetwork = new Network(acceptAsyncAnnouncements=true);

...

theNetwork.Freeze();

try {

foreach(Device dev in theNetwork.Devices) { ...

} }

finally { theNetwork.Unfreeze(); }

performed even if an exception is thrown within the try block.

Pseudocode 7.6 shows how the programmer can protect a program section from asynchronous attribute’s changes.

Algorithm 7.6 Attributes’ lock example

Device dev = theNetwork.DeviceAt(address);

dev.LockAttr();

try {

int a = (int)dev.ReadAttr(...);

int b = (int)dev.GetAttrVal(...);

int c = (int)dev.GetAttrVal(...);

dev.WriteAttr(...);

}

finally { dev.UnlockAttr(); }

(53)

Chapter 8

ZigApi application programming interface

This chapter explains in details of the application programming interface of ZigApi. In order to avoid name conflicts, all the names are included in the global namespace ZigApi.

8.1 Network

A Network object represents a ZigBee network, manages the connection with the gateway and the list of connected devices. It realizes the CIL[4] standard IDisposable interface.

for ZigBee Home Automation Solutions

In Supremae Dignitatis · Universit` a di Pisa

Design and Development of a Software Infrastructure

for ZigBee Home Automation Solutions

Curriculum Networking e Multimedia

Supervisors:

Prof.

GIANLUCA DINI Eng.

ALESSIO VECCHIO

Author:

PERICLE PERAZZO

Session II

Academic Year 2009-2010

Dedicated to

Beatrice, who supported me in everything I did

Contents

1 Introduction 9

2 Home Automation 11

3 ZigBee 13

3.1 ZigBee stack overview . . . . 14

3.2 Physical, medium access control and network layers . . . . 14

3.3 Applicative layer . . . . 16

3.4 ZigBee attributes . . . . 17

4 Gateway infrastructure solution 18 4.1 Telecom Italia gateway abstraction layer . . . . 18

4.2 GAL XML interface . . . . 19

5 Physical and virtual devices 22 5.1 Telecom Italia smart plugs . . . . 22

5.2 Virtual devices . . . . 22

5.2.1 Virtual device utility middleware . . . . 25

6 Home Manager 27 6.1 Information’s persistance . . . . 28

6.2 Graphical interface . . . . 29

6.3 Program features . . . . 29

6.4 Power bindings . . . . 31

6.5 Gateway connection and disconnection . . . . 32

6.6 Device initialization . . . . 32

6.7 First identification . . . . 33

6.8 Naming . . . . 33

6.9 Devices map placing . . . . 34

6.10 Power bindings set up . . . . 34

6.11 Attribute reports gathering and graph building . . . . 34

6.12 Centralized control . . . . 35

6.13 Smart plug’s automatic turn off . . . . 36

6.14 Power overload protection . . . . 36

7 ZigApi architecture 41 7.1 Offered services . . . . 42

7.2 Architectural overview . . . . 43

7.3 Devices and clusters implemented by ZigApi . . . . 44

7.4 Programming examples . . . . 46

7.4.1 Attributes . . . . 48

7.4.2 Attribute reports . . . . 48

7.4.3 Network locking . . . . 48

8 ZigApi application programming interface 52 8.1 Network . . . . 52

8.1.1 Constructor . . . . 52

8.1.2 Default constructor . . . . 54

8.1.3 Dispose method and destructor . . . . 54

8.1.4 Miscellaneous properties . . . . 55

8.1.5 Registering custom devices . . . . 56

8.1.6 Connect, inquiry and disconnect operations . . . . 57

8.1.7 Leave device . . . . 60

8.1.8 Retrieving a Device object . . . . 60

8.1.9 Broadcast device group . . . . 61

8.1.10 Locking methods . . . . 61

8.2 DeviceGroup . . . . 65

8.3 Device . . . . 67

8.3.1 Constructor . . . . 67

8.3.2 Dispose method and destructor . . . . 68

8.3.3 Miscellaneous properties . . . . 69

8.3.4 Methods generating ZigBee traffic . . . . 70

8.3.5 Attribute database . . . . 71

8.3.6 Getting attributes’ characteristics . . . . 73

8.3.7 Attribute reading . . . . 74

8.3.8 Retrieving values from attribute database . . . . 75

8.3.9 Attribute writing . . . . 76

8.3.10 Attribute reporting configuration . . . . 76

8.3.11 Attribute reports callback . . . . 77

8.3.12 Attribute locking methods . . . . 78

8.4 IBasicCluster interface . . . . 80

8.4.1 Attributes . . . . 80

8.5 IOnOffCluster interface . . . . 80

8.5.1 Attributes . . . . 80

8.5.2 Operations . . . . 81

8.6 IIdentifyCluster interface . . . . 82