Novembro de 2011

Tese de MestradoCiclo de Estudos Integrados Conducentes ao Grau deMestre em Engenharia Electrónica Industrial e de Computadores

Trabalho efetuado sob a orientação doProfessor Doutor Sérgio Adriano Fernandes Lopes

Luís Daniel Carvalho da Silva

iHotel – An Hotel Room ControllerUsing the Z-Wave Protocol

Universidade do MinhoEscola de Engenharia

Acknowledgements

First and foremost I would like to express how thankful I am to my su-pervisor Prof. Sergio Lopes, who followed my work closely, and advised me wiselythroughout the whole time. His continuous support, with his ideas and carefulthought were very important to my work. He was always there to listen and hishelp was invaluable in developing my ability to ask myself what was wrong orneeded to be perfected. It showed me that there was still much to be done, spe-cially in the way I approached the problems I faced.I would also like to show my deepest and sincere appreciation to other two Profes-sors of mine. Professor Adriano Tavares, for all of his hard work and counsellingduring my Masters degree in Computer Technology. He taught me that there isnothing that cannot be done without effort and perseverance. His insightful visionlead me throughout my whole work and will for sure lead in my future life as anEngineer.I will also be forever thankful to him for his support since the moment Idecided to embrace this project, he has truly been an inspiration to me.To Professor Jorge Cabral I would like to thank him for the help and inspiringcounselling he gave me whenever I needed. With his support I learned that thereare a number of ways to solve a problem and some of them, although not obviouswill for sure contribute for a better solution. A popular expression that for this is“thinking outside the box ”.

Finally, I would like to thank my family: my parents and sisters, for theirpatience and effort in supporting me during my Master Thesis. Without theirhelp, without their patience I could never achieve what I have achieved until thisday.

II

Abstract

This thesis report is a study on the proprietary Z-Wave protocol potentialitiesas a wireless communication protocol in a home automation context. Z-Wave is aproprietary home automation protocol. Throughout this report it will be possibleto get an insight on how the Z-Wave protocol works by analysing several typesof information freely available on the World Wide Web, open source projects andcommercial applications that use Z-Wave technology. The proposed approach tothis work will be the analysis of the previously collected information to use ageneral set of Z-Wave commands and design a small touch screen based embeddedsystem that features some support for the Z-Wave protocol. This console will bepart of a larger concept, the iHotel concept. This concept uses a single deviceto control all the functionalities related to the hotel room. It should be possibleto control every electronic device within a hotel room from this single interactiveconsole.

The results of this work are: (1) a working prototype of the console thatcontrols basic Z-Wave devices such as light switches, outlets, thermostats andmotion sensors; and, (2) the opening of a path, so that others can explore theZ-Wave protocol, understand it and further expand its support by adding newfeatures.

Resumo

Este relatorio de tese e um estudo das potencialidades do protocolo pro-prietario Z-Wave situado num contexto de automacao residencial sem fios. OZ-Wave e um protocolo sem fios de automacao residencial. Ao longo deste re-latorio sera possıvel ter uma ideia de como o protocolo Z-Wave funciona atravesde analises de informacao disponıvel livremente na World Wide Web, projectosopen-source e aplicacoes comerciais que usam a tecnologia Z-Wave. A abordagemproposta a este trabalho sera a analise de informacao previamente adquirida parausar um conjunto de comandos basicos e gerais Z-Wave e desenhar um pequenosistema embebido baseado num ecra tactil que suportara comandos Z-Wave. Estaconsola fara parte de um conceito mais abrangente, o conceito iHotel. Este conceitousa um unico dispositivo para controlar todas as funcionalidades relacionadas comum quarto de hotel. Devera ser possıvel controlar todos os dispositivos electronicospresentes num quarto de hotel a partir deste sistema embebido.

Os resultados deste trabalho sao: (1) um prototipo funcional da consolaque controla dispositivos Z-Wave basicos como interruptores de parede, tomadas,termostatos e sensores de movimento; e, (2) a abertura de um caminho, para queoutros possam explorar o protocolo Z-Wave, entende-lo e expandir ainda mais oseu suporte adicionando-lhe novas funcionalidades.

Contents

1 Introduction 31.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 The iHotel Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 State of the Art 72.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Wireless Residential Automation Protocols . . . . . . . . . . . . . . 7

2.2.1 X10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.2 Insteon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.3 Zigbee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.4 Z-Wave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Commercial of the Shelf (COTS) Systems . . . . . . . . . . . . . . 92.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.2 Lagotek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.3 Go Control Center . . . . . . . . . . . . . . . . . . . . . . . 112.3.4 Silverpac Silverstat . . . . . . . . . . . . . . . . . . . . . . . 112.3.5 Intel Home Dashboard Concept . . . . . . . . . . . . . . . . 132.3.6 Z-Wave Enabled Touch Screen . . . . . . . . . . . . . . . . . 142.3.7 Electronic House Keeper . . . . . . . . . . . . . . . . . . . . 15

3 Platform 173.1 Development Board . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 Z-Wave Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3 Software Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.4 Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4.2 Widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4.3 Qt Datatypes . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4.4 Signals and Slots . . . . . . . . . . . . . . . . . . . . . . . . 193.4.5 MOC (Meta Object Compiler) . . . . . . . . . . . . . . . . . 203.4.6 Qt Class Organization . . . . . . . . . . . . . . . . . . . . . 21

4 Z-Wave 234.1 Network Management . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.1 Self-Organizing . . . . . . . . . . . . . . . . . . . . . . . . . 244.1.2 Self-Healing . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

V

4.1.3 Routing Principles . . . . . . . . . . . . . . . . . . . . . . . 244.1.4 Association Process . . . . . . . . . . . . . . . . . . . . . . . 254.1.5 Inclusion Process . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Z-Wave Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.1 Z-Wave Application Layer . . . . . . . . . . . . . . . . . . . 274.2.2 Application Frame Format . . . . . . . . . . . . . . . . . . . 28

5 Exploring Z-Wave Messages 315.1 Checksum Calculation . . . . . . . . . . . . . . . . . . . . . . . . . 345.2 Node Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.3 Z-Wave Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.4 Device Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.4.1 Basic Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.4.1.1 Turn On . . . . . . . . . . . . . . . . . . . . . . . . 385.4.1.2 Turn Off . . . . . . . . . . . . . . . . . . . . . . . . 385.4.1.3 Get Status . . . . . . . . . . . . . . . . . . . . . . 39

5.4.2 Dimmer Switch . . . . . . . . . . . . . . . . . . . . . . . . . 395.4.2.1 Turn On . . . . . . . . . . . . . . . . . . . . . . . . 395.4.2.2 Turn Off . . . . . . . . . . . . . . . . . . . . . . . . 405.4.2.3 Get Status . . . . . . . . . . . . . . . . . . . . . . 405.4.2.4 Dimm the Load . . . . . . . . . . . . . . . . . . . . 41

5.4.3 Power Meter . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.4.3.1 Instant Energy Consumption . . . . . . . . . . . . 425.4.3.2 Accumulated Energy Consumption . . . . . . . . . 43

5.4.4 Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.4.4.1 Temperature . . . . . . . . . . . . . . . . . . . . . 465.4.4.2 Light Measurement . . . . . . . . . . . . . . . . . . 475.4.4.3 Multi Instance . . . . . . . . . . . . . . . . . . . . 485.4.4.4 Battery Level . . . . . . . . . . . . . . . . . . . . . 495.4.4.5 Motion Sensor . . . . . . . . . . . . . . . . . . . . 49

5.4.5 Device Association . . . . . . . . . . . . . . . . . . . . . . . 505.4.6 Configuration Parameters . . . . . . . . . . . . . . . . . . . 50

5.4.6.1 Dimmer Switch Configuration Parameters . . . . . 535.4.7 Dimmer Switch Supported Features . . . . . . . . . . . . . . 545.4.8 Manufacturer Information & Device Type . . . . . . . . . . 555.4.9 Node Version Information . . . . . . . . . . . . . . . . . . . 55

6 Graphical User Interface 596.1 Main Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606.2 Socket2Serial - Graphical User Interface . . . . . . . . . . . . . . . 616.3 Z-Wave Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.3.1 Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.3.2 Dimmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.3.3 Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.4 Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

VI

7 Socket2Serial Interface Software 717.1 Unix Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.2 Serial Port Input/Output . . . . . . . . . . . . . . . . . . . . . . . 73

7.2.1 Opening a Serial Device . . . . . . . . . . . . . . . . . . . . 747.2.2 Configuring the Serial Device . . . . . . . . . . . . . . . . . 747.2.3 Writing to and Reading from the Serial Interface . . . . . . 757.2.4 Close Serial Interface . . . . . . . . . . . . . . . . . . . . . . 76

7.3 Network Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767.3.1 Establishing a Socket Connection - Server Side . . . . . . . . 76

7.3.1.1 Creating a Server . . . . . . . . . . . . . . . . . . . 767.3.1.2 Configuring a Socket . . . . . . . . . . . . . . . . . 777.3.1.3 Bind Socket . . . . . . . . . . . . . . . . . . . . . . 787.3.1.4 Accept Connection . . . . . . . . . . . . . . . . . . 797.3.1.5 Sending and Receiving Data . . . . . . . . . . . . . 797.3.1.6 Closing a Socket Connection . . . . . . . . . . . . . 79

7.3.2 Establishing a Socket Connection - Client Side . . . . . . . . 797.4 Data Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807.5 Select() Application Programming Interface . . . . . . . . . . . . . 80

7.5.1 Communication Management . . . . . . . . . . . . . . . . . 817.5.2 Registering the Socket File Descriptor . . . . . . . . . . . . 81

7.6 Running the Application . . . . . . . . . . . . . . . . . . . . . . . . 82

8 Conclusion 838.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

8.1.1 Processing Power . . . . . . . . . . . . . . . . . . . . . . . . 838.1.2 Complete Z-Wave Application Programming Interface . . . . 838.1.3 Larger Display . . . . . . . . . . . . . . . . . . . . . . . . . 838.1.4 iHotel Web Control . . . . . . . . . . . . . . . . . . . . . . . 84

8.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

VII

VIII

List of Figures

1.1 Hotel Room Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Hotel Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Lagotel’s HIP100 system controller. . . . . . . . . . . . . . . . . . . 102.2 Go Control Center . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 SilverPac SilverSTAT 7 User Interface . . . . . . . . . . . . . . . . . 122.4 Intel Home Dashboard Concept User Interface . . . . . . . . . . . . 132.5 Intel Home Dashboard Energy Consumption Overview . . . . . . . 142.6 Electronic House Keeper . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1 Mini2440 with 7” LCD Development Kit . . . . . . . . . . . . . . . 173.2 Signals and Slots Example . . . . . . . . . . . . . . . . . . . . . . . 203.3 Qt Classes Used for Building the GUI . . . . . . . . . . . . . . . . . 213.4 Socket Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1 Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2 Routed Acknowledge Frame Type . . . . . . . . . . . . . . . . . . . 254.3 Application Layer Organizational Diagram . . . . . . . . . . . . . . 264.4 Application Layer Frame Format . . . . . . . . . . . . . . . . . . . 274.5 Interaction Between Devices During Network Inclusion . . . . . . . 274.6 Data Monitorization Diagram . . . . . . . . . . . . . . . . . . . . . 284.7 Z-Wave Application Commands General Frame Format . . . . . . . 29

5.1 Qees Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.2 ZDM230 Dimmer Switch . . . . . . . . . . . . . . . . . . . . . . . . 405.3 HSM100 3 in 1 Sensor . . . . . . . . . . . . . . . . . . . . . . . . . 455.4 Summary of Z-Wave Frame Structure for Luminance Responses . . 485.5 Multi Instance Command Class Structure . . . . . . . . . . . . . . 485.6 Multi Instance Command Class Structure Comparison . . . . . . . 485.7 Multi Instance Data Selection Possible Diagram . . . . . . . . . . . 49

6.1 System Connections Overview . . . . . . . . . . . . . . . . . . . . . 606.2 Graphical User Interface Main Screen . . . . . . . . . . . . . . . . . 616.3 Main Window Classes Relationship . . . . . . . . . . . . . . . . . . 626.4 Client Object Relationship . . . . . . . . . . . . . . . . . . . . . . . 626.5 Switch Graphical User Interface . . . . . . . . . . . . . . . . . . . . 646.6 Dimmer Graphical User Interface . . . . . . . . . . . . . . . . . . . 666.7 Sensor Graphical User Interface . . . . . . . . . . . . . . . . . . . . 67

IX

6.8 Configurations Graphical User Interface . . . . . . . . . . . . . . . . 69

7.1 Flow of data through Socket2Serial . . . . . . . . . . . . . . . . . . 717.2 Socket2Serial Diagram of Operation . . . . . . . . . . . . . . . . . . 737.3 Server and Client Socket Flow Diagram . . . . . . . . . . . . . . . . 77

X

List of Tables

4.1 Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.1 Frame Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2 Byte masking table . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.3 Response to the version request of the Z-Tool Initialization Process 375.4 Response to the version request of the Z-Tool Initialization Process 375.5 Meter Get Command Structure . . . . . . . . . . . . . . . . . . . . 425.6 Meter Report Command Structure . . . . . . . . . . . . . . . . . . 425.7 Codes of Configuration Parameter for the HSM100 device . . . . . . 515.8 Device Type List . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.9 Manufacturer ID List . . . . . . . . . . . . . . . . . . . . . . . . . . 56

1

2

Chapter 1

Introduction

1.1 Motivation

This thesis project is a study of the proprietary Z-Wave wireless home automationprotocol [1], describes a home automation based on Z-Wave, and the use of someof its features in the development of a touch screen based console aimed at a hotelroom automation scenario.

Recently, with the development of new technologies the market of home au-tomation has been developing at a faster pace. With this development, came theneed to install home automation systems in already built houses as well as in newhouses. Companies started to think in solutions that could satisfy all their currentmarket requisites and still maintain a market price.

To meet this requirement, it became obvious that only two solutions would beviable. The need for wires is, and will not be completely extinct in the near fu-ture, as such, retro-compatibility of current systems with older and wired systemsis necessary during a transitional period. The other one is to disseminate the useof wireless home automation technologies as the standard to be. The advantagesof not using wired installations are clear. Reduced cost, ease of installation, in-crease in range without having to install additional wiring, and specially networkflexibility making it an ideal general purpose solution.

To control any type of home automation system it is necessary to have atleast one controller or several. Lately, a high number of touch screen consolebased solutions have been emerging, much because of the success of new touchscreen cellphones and the easiness of use of that man-machine interface. The solu-tions currently available in the market have been widely accepted by the market,consequently it became popular to use this type of interface.

Nowadays there are several home automation protocols available, some betterthan others, or having a certain characteristic that makes them superior for a givensituation. One of the latest protocols to come to market is the Z-Wave protocol.This protocol is simple, its compatible products have low time-to-market andthe range of products already available is very high. The downside is the factthat this is a closed, proprietary protocol, yet the complexity of other protocolsin characteristics such as device association and interaction, make the Z-Wave

3

protocol very powerful by comparison.The fact that Z-Wave is a very powerful proprietary protocol makes it an

interesting case study for the academic community and for hobbyists that seek tocontrol a small Z-Wave device installation for a small price without being forcedto spend a huge amount of money in an official development kit. This led to a veryhigh demand for details about the protocol. A lot of people became interested init and now currently a few initiatives are taking place to uncover all details of theprotocol.

Z-Wave is becoming more and more interesting as a study subject since res-idential home automation systems are becoming a part of everyday life. Z-Wavespecifically is getting extremely popular. The main problem in studying and de-veloping a solution to use part of or all protocol features is the fact that there isnot official documentation available that shows how the protocol works in detailand completely. To implement a working solution, one has to investigate furtheron other people’s works and try to extrapolate information obtained by makingdiverse experiments that attempt to use more and more of the protocol function-alities.

This work is meant to give an insight on how this protocol works and demon-strates its potentialities. Showing a working example of an interface to Z-Wavedevices is a very good way to achieve these two goals. To better illustrate thesuccessful use of the protocol, a study around an use case was developed, namelya possible real life situation, that makes extensive use of the protocol features. Inthis case home automation in the context of its use in a hotel facility.

This thesis is structured in the following form. The first chapter introduces thestudy of the protocol. How to interpret the information that is sent and receivedis the critical part of this study. This information will be vital to implementwith a Z-Wave network. The second chapter describes how the interface with theZ-Wave network is done, how the messages are actually sent and received. Thethird chapter illustrates the graphical user interface that allows the end user tocontrol the Z-Wave network, followed by the fourth chapter that shows the resultsof this study and its respective analysis. This reports fifth chapter, demonstratesthe conclusions reached by this study and its validity as study subjects.

1.2 The iHotel Concept

The iHotel concept can be defined as an integrated management console forwireless hotel room automation.

The usual hotel room user often has to deal with many different interfaces tomanage his life inside the room. The telephone, a thermostat, a radio, the roomlights and blinds are examples of equipments which need a friendly and interactiveinterface in order for the user to feel comfortable using them. The iHotel conceptrelies only on Z-Wave, a technology with great potential to evolve as an industrystandard in home automation, since this is a wireless technology with a greatdiversity of devices already developed from several major automation brands suchas: Danfoss, Leviton, ACT, Everspring, Homeseer, Intermatic, Merten and several

4

other. The main idea of iHotel is unification and its main appeal is the fact thatone interface substitutes all other within the hotel room.

Figure 1.1: Hotel Room Interfaces

Figure 1.1 represents some of the interfaces that can be aggregated in the iHo-tel console. Each hotel room is a Z-Wave independent network, independent fromany other Z-Wave network that may operate nearby. However, each iHotel inter-face is connected by means of a cable or even wirelessly to a central hotel TCP/IPnetwork, as represented in figure 1.2. A central server would be responsible formanaging all the consoles from each room and its respective Z-Wave networks.

Figure 1.2: Hotel Network

5

The advantages of using a single interface in each hotel room are clear. Oneinterface means that the control system will be cheaper, the user will only haveto deal with one equipment and the hotel will be equipped with the means tohave every room under monitorization and control. Besides that, the system willprovide added security for the hotel by making available detailed informationabout the room occupancy and usage (e.g., room services, energy costs).

As a main disadvantage there is the cost of the whole system. Since the Z-Wave standard is only a few years old, cost is still an issue. A normal load switchcan cost up to 5 times the cost of a normal switch. A whole room equipped withZ-Wave devices is much more expensive than with normal devices.

In recent years the home automation market has been suffering major changes.Levels of automation that were impracticable a few years ago, are now possible

using modern home control systems. At this time is possible to automate roomtemperatures, lighting, doors and windows, security, HVAC systems, surveillancesystems, and other types of automation systems.

Taking into account the success, acceptance and high attention the Z-Waveprotocol has been having since its development, it became a desirable subject ofstudy for the common hobbyist and the academic community.

6

Chapter 2

State of the Art

2.1 Introduction

Several different protocols developed for home control systems have been emergingin the last two decades. Most of those protocols are not considered standards sincethey are not adopted by the majority of the home automation users and respectiveindustry. Some of the most relevant ones, which actually became popular standardprotocols are KNX, X10, LonWorks, INSTEON, Zigbee and more recently Z-Wave.

2.2 Wireless Residential Automation Protocols

2.2.1 X10

X10 is a home automation standard already deeply established in the market. Itwas developed in 1975, so the number of devices already present on the market isvery high.

Back when the standard was developed, there were no plans to use a wirelesstransmission medium of transmission. The main medium of transmission at thattime was the power line. The data is encoded and is transmitted, bit by bit ateach zero crossing of the AC current waveform.

As more solutions came to market, it became necessary to bring the X10up to the standards that were being introduced, such as a wireless method ofcommunication.

The wireless frequency used by the system is 310 MHz in the United States and433 MHz in European systems. The system’s wireless devices transmits packetsidentical to the wired version of the protocol. The most common devices availablewith the wireless version of the protocol are switches, fire and burglar alarms, lightcontrollers and general device controllers.

This protocol suffers from some well known issues, like being extremely slow,by comparison to other protocols, lacking encryption and suffering from sometypes of interferences. The protocol also has the limitation of addressing only 256devices.

7

The only entity responsible for regulating the introduction of new devices andmodifications to the protocol is the company that developed it - Pico Electronics.

2.2.2 Insteon

Isteon is a protocol similar to the X10 standard, it was designed to be compatiblewith the X10 as well as to improve its limitations. Much as the X10, it uses thepower line or a radio frequency (RF) to communicate between devices.

Insteon is a wired and wireless mesh network topology. This means that anynode can repeat, transmit and receive data in the network. There is no need for anetwork controller because the network is peer-to-peer. The devices meant to beused by the Insteon protocol are simple devices, such as light switches, sensors,fire and burglar alarms, etc.

The company beyond the Insteon protocol is SmartLabs.

2.2.3 Zigbee

Zigbee is not a protocol but a specification for low power, low bandwidth protocolsbased on the IEEE 802.15.4 standard. This specification is meant for small WPAN(Wireless Personal Area Networks), such as the case of Home Automation proto-cols. The main objective of this standard is to define a low power, low bandwidth,self-organizing mesh network that can be used not only for general purpose butalso for industrial control, embedded sensing, medical data harvesting, fire andburglar alarms, building and home automation and other application fields whereWPAN networks are necessary.

ZigBee is a wireless mesh networking standard and provides high reliability indata transmission and extensive transmission ranges.

The bands of operation are 868 Mhz in Europe, 915 Mhz in USA and 2.4 GHzin most other countries.

A ZigBee chip usually comes in the form of a microcontroller with a RF radioand the Zigbee stack already programmed in it. The ZigBee stack was designedto be easy to develop applications on the microcontrollers.

Much as other protocols, its regulation and interoperability are assured by aconsortium of companies that form the so called ZigBee Alliance. Any new devicehas to be validated by passing the ZigBee Qualification Process.

2.2.4 Z-Wave

The Z-Wave protocol is a low-power wireless communications protocol speciallydesigned to be used in home automation. Zensys is the company responsible forthe development of this protocol. This technology is proprietary, which means itis not possible to take full profit of it without full access to its documentation.

Z-Wave uses a RF radio that operates in the sub Gigahertz frequency range.This enables Z-Wave communications not to be interfered by any device basedon the IEEE 802.11 wireless standard. This sub Gigahertz frequency also enables

8

the transmission of small amounts of data at lower speeds with an extremely lowpower consumption.

Due to the low cost of embedding a Z-Wave module in consumer electronicsproducts, there are a lot of manufacturers trying to develop new Z-Wave con-trolled products such as remote controls, smoke alarms, sensors, thermostats, wallswitches and presence sensors.

Z-Wave is a mesh networking technology where each node communicates withany other on the network by sending a message through one or several nodes.This allows the possibility of communicating with nodes that are out of range dueto the distance or the existence of obstacles. These devices can work alone or ingroups, this enables an association of devices to be made according to certain rulesdefined by the user.

The Z-Wave protocol and device interoperability is regulated by an interna-tional consortium of manufacturers called Z-Wave Alliance.

2.3 Commercial of the Shelf (COTS) Systems

2.3.1 Introduction

At this point, some commercial home control systems with Z-Wave capabilities aregoing to be presented. These systems resemble themselves with the iHotel projectin the sense that they feature Z-Wave device control but also other functions suchas sound control or VoIP phone. Each of them consists of a touch screen embeddeddevice from where a user can control a series of Z-Wave devices. Besides Z-Waveconnectivity, most of the systems here depicted have a set of very interestingand useful features such as: sound control, VoIP phone, radio, digital frame,alarm clock among others. Since Z-Wave is a rather new technology it cannot beexpected that a large market of solutions is available.

2.3.2 Lagotek

Lagotek’s HIP100 is a mixture of wireless hardware and software based on theWindows CE 5.0 operating system and its .NET Compact Framework. Lagotekuses other companies Z-Wave products. It features a small LCD touch screen, amicrophone, a speaker, sensors measuring temperature, light and the proximity ofpeople nearby as well as Wi-Fi and Z-Wave controller to interface with Z-Wavecompatible products. The HIP100 can regulate lighting, heating and cooling roomby room, digital music, irrigation, burglar and fire-alarm systems and securitycameras, as well as motorized skylights and fans.

The HIP100 units can operate standalone or in a redundant wireless network,with each unit being capable of controlling the entire house if necessary, up until aZ-Wave limit of 232 devices per network. The Wi-Fi connection enables the systemto communicate with a central computer for additional control, such as the caseof a hotel. Where the hotel can have a sense of certain events that are happeningin a room, like leaving the door room open for more than a pre-determined time,

9

or the music being too loud for a certain time, as well as simple functions likecontrol its music library.

Figure 2.1: Lagotel’s HIP100 system controller.

A controller with a normal set of nodes, enough for 3/4 rooms, a living room,a kitchen, 3 bathrooms, a hall, a garage and a basement is meant to be installedin homes selling for 400,000$ or more, so that its price represents approximately2% of the total price. The price of a system as previously described can go forabout 8,500$.

The Lagotek’s HIP100 system features:

- Lighting Control;

- Scene Modes;

- Distributed Audio;

- Climate Control;

- Video Monitoring;

- Blinds;

- Security;

- Rules;

- IR Control;

- Intercommunication;

- Irrigation Control.

10

2.3.3 Go Control Center

The Go Control Center, show in Figure 2.2, is an all-in-one security and homemanagement system. This system features an intuitive and user-friendly colortouch-screen interface, a GSM (Groupe Special Mobile) radio and built-in Z-WaveRF Protocol support. The Z-Wave support enables the system to control lighting,HVAC and other home Z-Wave appliances right from the system, smart phone orcomputer using a Z-Wave controller connected to a USB port of a Wi-Fi connectionto a Z-Wave enabled router. Besides the Go Control Center, Z-Wave nodes forthe house where the system is meant to be installed are all that is necessary tobuy.

The Go Control Center is connected to a monitoring center via a cellularconnection which allows an operator to hear what is happening in the house,through one or several Go Control Center devices and quickly dispatch emergencyservices.

Figure 2.2: Go Control Center

These characteristics provide important money and time-saving applications.The features of the Go Control Center are:

- Color Touch Screen Display;

- Fully Self Contained;

- Snap-in GSM Radio;

- 2-Way Voice Over Cell.

The Go Control Center is priced at 700$.

2.3.4 Silverpac Silverstat

The SilverPAC SilverSTAT 7, depicted in Figure 2.3 is an advanced smart energythermostat that seeks to replace the common household thermostat with an ad-vanced home climate control system. The SilverSTAT 7 features a Smart Energy

11

In-Home Display (IHD) to help monitoring and management of energy consump-tion and is built on Windows CE 6.0 R3 and Intel Atom platform. The device hasbeen designed with a seven-inch touch screen display that is able to display thedistribution of household energy consumption down to each individual appliance.

Figure 2.3: SilverPac SilverSTAT 7 User Interface

The SilverSTAT 7 has a touch sensitive LCD screen and thanks to its wireless801.11 connection the device is capable of communicating with smart meters, thatway the users can see instantly how much gas or electricity is being consumedat a given point in time. It also has an 802.11 Wi-Fi interface that allows itto communicate with a local area network and Internet services. It is Z-Waveenabled so it will be able to talk to and interact with Z-Wave enabled lights andappliances, programming and shutting them off as needed. Energy and budgetsavings can be achieved by turning off or rescheduling the use of appliances for amore cost efficient time. The SilverSTAT 7 can also be used to access informationeasily from a central location. One can plan for power usage and cost optimizationby using weather and fuel price information obtained through the system.

SilverSTAT 7 can act like a normal computer by being able to stream photos,music and content direct from the internet or the PC. In summary the SilverSTAT7 features:

- 7” Touch Screen LCD;

- Windows Embedded CE 6.0 R3;

- 64 MB DDR RAM (upgradable to 128 MB);

- 128 MB Flash Memory (upgradable to 4 GB);

- 1 x USB (Standard A);

- Intelligent 7 day programmable thermostat for HVAC control;

- IEEE 802.15.4 ZigBee Wireless Interface to Monitor Smart Meters;

12

- 802.11g Wi-Fi Interface for Home and Internet Networking Connection;

- Z-Wave Home Automation Interface to Manage Lighting and Appliances;

- DLNA Compliant;

- FM Radio for Convenience and Local News Broadcasts and Emergency In-formation;

- Built-In Speakers;

- Digital Picture Frame and Media Player can play content from network orinternet;

- Digital Clock, Calendar, Scheduler, Task Manager for Home Control andmore.

The suggested retail price is 1,300$.

2.3.5 Intel Home Dashboard Concept

The Intel Home Automation System is built using an Atom processor platformand a large 11” touch-sensitive OLED display, this can be seen in Figure 2.4. As acontrol dashboard it features a Zigbee and a Z-Wave interface in order to connectwith all the electronic appliances at home.

The Intel Home Automation System shows the user the most diverse informa-tions, whether they are weather, utility cost or temperature, personal messages,home security, time, internet access. The Wi-Fi connection allows the user tohave access to the Internet. The Zigbee and the Z-Wave interfaces allow the userto monitor and to manage the energy consumption down to each appliance, Fig-ure 2.5 depicts this. The software controls the utilities to lower electricity use ofappliances during peak cost times.

Figure 2.4: Intel Home Dashboard Concept User Interface

13

The device is meant to act as a hub for controlling the electrical appliances andthe thermostats as well as gather information from smart meters. Each applianceneeds to be connected to a low-cost Z-Wave and/or Zigbee transmitted socket inorder for this to work.

Since this is still a concept product, it still does not have a retail price available.

Figure 2.5: Intel Home Dashboard Energy Consumption Overview

With capabilities similar to those of netbooks, the system can do a numberof other tasks, including being used as home communications center, access theInternet and display video from security cameras.

2.3.6 Z-Wave Enabled Touch Screen

The Interactive Electronic Systems Control Touch Screen allows the controland monitoring of Z-Wave enabled devices such as lighting, thermostats, windowsand a unique automated wake-up scene. Events can be scheduled and defaultscenes or 1 button scenes can be configured for easier operation. The systemis self contained, has a backup battery. A software package is used to createpre-programmed schedules and scenes that can be used to display light and tem-perature scenarios. The Interactive Electronic systems Control Touch Screen caneasily be installed in a standard 2 gang electrical box. The suggested retail priceis 499.97$. This system features are:

- Full featured, high resolution color display;

- Easy-to-use Lighting configuration software package for customizing of Scenes,Schedules, Rooms and Lights Manual Device and Scene Control;

- Multiple individually selectable Scheduled Events;

14

- Status indication for intensity and module response;

- Battery backup for Real Time Clock;

- Can be mounted into standard two-gang electrical box;

- IR remote control port for future applications EasyTouch-S Touch ScreenSpecifications.

Its specifications are:

- High Brightness, High Contrast LCD display;

- 3.6 inch diagonal;

- LED backlight (Software controlled);

- 1028 Volts DC Input Voltage;

- Power Consumption approx 170 mA @ 12 Volts V DC.

2.3.7 Electronic House Keeper

The Housekeeper 2.6 is a wall-mountable console with wireless communicationcapabilities that interfaces with electronics, appliances, heating, air conditioning,as well as water and electricity meters. The Housekeeper features Wi-Fi and Z-Wave connections. Using the latest Z-Wave technology it is possible to monitor,control and time the electricity consumption on the electrical appliances connectedto the Housekeeper. The touch screen console enables the users to review theenergy usage of each of the devices connected to it. Using the Wi-Fi connectionis possible to control and monitor the appliances through a computer.

Communication via VoIP, text messaging, access to the e-mail and web is alsomade possible using the Housekeeper.

Figure 2.6: Electronic House Keeper

15

The technical specifications are as follows:

- 180 x 202 x 45 cm dimensions;

- 7” Touch Screen 480x234 LCD;

- Intel 520 Mhz PXA270 processor;

- 256 MB Internal Memory;

- 5 Watt Stereo Speakers;

- FM Radio with RDS;

- Z-Wave RF Interface;

- IR controllable via B&O, Phillips, Sony, NEC, Panasonic, Daewoo, JVC,Nokia and Sharp;

- 1 x Ethernet, 4 x USB 1.1, FM Antenna and Line Out connectors;

- Movement, Temperature and Light Sensors;

- Windows CE .NET.

16

Chapter 3

Platform

3.1 Development Board

The platform used to develop this project is an embedded system based on the 400MHz Samsung S3C2440 ARM9 processor with an ARM920T core with a 16/32-bit RISC architecture. Among these processor features are: a MMU unit, a LCDcontroller, UART ports, DMA channel, timers, input/output ports and severalother interfaces.

Designated as Mini2440, shown in Figure 3.1, it was developed by a Chinesecompany called Hiteg. The Mini2440 is able to run an embedded Linux distri-bution, including Android, as well as Windows CE. Picture 3.1 below depicts aMini2440 board with a 7” LCD display.

Figure 3.1: Mini2440 with 7” LCD Development Kit

This development platform besides the powerful processor has the followingfeatures:

- 64 MB SDRAM;

- 128 MB NAND Flash;

- Serial Ports;

- USB Host and USB device ports;

- Audio Output and Input;

- RJ-45 Ethernet connection;

17

- LCD and Camera Interface;

- JTAG Interface.

3.2 Z-Wave Devices

In this project, the following Z-Wave devices will be used:

- Aeon Labs USB Z-Stick;

- Qees Power Switch;

- ZDM230 Dimmer Switch;

- HSM100 3 in 1 Sensor.

The first item is the Z-Wave network controller. It is interfaced by the Home-Seer Home Automation Software to control the other three end devices. As theirown names suggest the first is an outlet switch which enables a user to control apower outlet either remotely or locally, the second is a switch with an includeddimmer which also features local and remote operation as well as association withdifferent devices in order to control them, and the third is a device with threesensors embedded on it, motion, temperature, and luminance with support for de-vice association to operate autonomously in cooperation with other devices. Eachof these Z-Wave devices has different characteristics which will be explored laterin this project, such as specific support for commands according to the type ofdevice, if its a switch, a dimmer or, a sensor.

3.3 Software Tools

The two software components in this project were developed in C and C++. Thisseemed an obvious choice both for the extensive experience with these languagesas for the fact that they are ideal for embedded development. The software com-ponent that communicates directly with the Z-Wave controller was developed inC using a simple text editor and the GNU GCC compiler, in Linux. The graphicaluser interface, GUI, that enables the user to interact with the Z-Wave networkwas develop in C++ using Qt. A brief introduction to Qt programming is givenin subsection 3.4.

Besides the developed software mentioned earlier, a commercial Z-Wave toolwas also used, the HomeSeer Home Automation Software. This tool enables a userto configure and control its own Z-Wave network. The main advantage of using itis the possibility of establishing a relationship between Z-Wave messages sent bythe software and the ones that need to be generated and sent by the software tobe developed in this project.

18

3.4 Qt

3.4.1 Introduction

Qt is a cross-platform application and UI (User Interface) framework to writeapplications once and deploy across a multitude of operating systems. It is mostlypopular in the development of GUIs, but it is also used for non-GUI applications.C++ is the standard programming language to use Qt although several languagebindings exist to other programming languages.

In terms of licensing, Qt is free and open-source to personal use, however alicense has to be obtained if any system is to be sold using Qt technology.

3.4.2 Widgets

A Widget is the basic unit of a GUI application. It can be a window, menu,button, icon, roll bar and many other items. Widgets usually follow a hierarchy,there are parent Widgets and child Widgets but independent Widgets may alsobe created. A widget without a parent is called a window. Widgets communicatebetween themselves in an indirect way. Each time an event occurs, a Widget willannounce that event, for instance: mouse, keyboard, or other events from the useror window system that may trigger other widgets behaviour.

3.4.3 Qt Datatypes

When designing a GUI application using Qt, several other data types may be usedbesides the normal C++ data types such as: int, bool, double, char, etc. Some ofthese new data types can be regarded as variants of popular types of containers inC++ like QList<T > or QVector<T > and some of them actually simplify certaintasks such as: QDate, QDateTime, QChar, QString, QByteArray, etc, because oftheir specificity.

3.4.4 Signals and Slots

As said in the previous subsection, with a GUI application designed with Qt,objects communicate between themselves by using the Signals/Slots mechanism.This mechanism is what differentiates more Qt from other frameworks. Thismechanism allows objects to emit events when certain actions occur and otherobjects to execute certain functions upon event notification. The emitted eventsare Signals and the executed functions are the Slots, which are almost identicalto C++ member functions with public, protected or private scope. For example,if a dial button is rotated, a roll bar is moved automatically. Figure 3.2 showsconnections between objects in terms of Signals and Slots.

19

Figure 3.2: Signals and Slots Example

In this example, the behaviour that is desired is that every time the dial orthe slider are actuated, the other one follows and the progress bar reacts accord-ingly also showing the percentage of light intensity. In order for this to happen,four connections were made between these three GUI objects. Connection numberone is used to instruct the dial to rotate when the horizontal slider moves; con-nection number two is used to make the progress bar move when the horizontalslider moves, connections number three and four are used to change the value ofthe dial object each time the ZDM230 horizontalSlider and ZDM230 progressBarrespectively, have their values changed. Most of the GUI controls already have aset of predefined Signals, but adding more Signals is always possible. The samehappens with Slots. No object cares about the Signals that are emitted and noobject knows that one of its Slots is being used by any other object. Objects arecompletely independent. Any number of Signals can be connected to any numberof Slots and even to other Signals.

3.4.5 MOC (Meta Object Compiler)

The Meta Object Compiler (MOC) is what makes Qt so powerful and flexible.The name suggests that the MOC is a compiler, but in fact it is a pre-processor ofQt special reserved words. Once any of these words is found, the MOC will replace

20

it with special C++ code that can be more complicated than the original reservedword. It can be said that it extends the source code with additional functions.The MOC’s reserved words are:

- Q OBJECT;

- public slots;

- protect slots;

- private slots;

- signals.

The MOC pre-processor is invoked when and if necessary, to pre-compile allthe necessary files with reserved words. After that, all the object files are createdand afterwards they can be linked.

3.4.6 Qt Class Organization

The application’s main window is based on Qt’s QMainWindow class; besidesthat one, other related classes are used for layout management, such as QButton,QWidget, QDialog, QToolBars, QDockWidgets and many more. Qt’s class QS-tackedFrame is used to avoid creating several different windows within the mainwindow. Each page of the StackedWidget features a different system function. Fig-ure 3.3, shows the classes used for building the GUI and the relationship betweenthem. All of those classes are part of QtGui module.

Figure 3.3: Qt Classes Used for Building the GUI

Qt already features a specific class for TCP socket communication calledQTcpSocket. Figure 3.4 shows the class organization that Qt features for in-terfacing with TCP sockets. These classes are part of the Qt Core module.

21

The GUI is based on Qt’s class QMainWindow from which a class MainWin-dow derives and an object of class Client, an application class, is instantiated aspart of the MainWindow class.

Figure 3.4: Socket Classes

22

Chapter 4

Z-Wave

Several amateur projects have been developed by individuals or groups of peoplethat aim at designing Z-Wave compatible software and hardware. These projectshave not had the support of the company responsible for the Z-Wave protocol,Zensys. As a consequence, most, if not all of the protocol details had to beunveiled in a trial and error basis. Z-Wave product manufacturers have providedpowerful hints on how a Z-Wave device communicates.

Z-Wave is a proprietary wireless protocol intended to be used in a residentialcontext to control appliances within a household. It is a low data rate (40 kbps),low power (<25 mW) that is meant to provide reliable transmission of data aswell as flexibility and simplicity. A Z-Wave network consists of up to 232 nodesand there are two types of nodes, controllers and slaves. In a Z-Wave network,although communication between two nodes may not be possible directly, othernodes can retransmit the message. This process takes place only up to a limit of4 retransmissions per message, that is, 4 network retransmission hops.

Each Z-Wave network has an unique 32 bit identifier named Home ID asstated in [2]. Each slave device obtains the Home ID from the controller uponjoining a network. Each individual node is addressed in the network by a unique8 bit identifier designated Node ID, which is unique only within the network andassigned by the network controller, also refered in [2]. A controller is able to initiatetransmission and calculate network routes for messages, while a slave is just an enddevice that executes the controllers requests. Within the controllers category thereare two distinct types: static and portable controllers. As their name says, staticcontrollers are the ones with a fixed position within the network, the portable arethe ones used to install the Z-Wave network and therefore they cannot be fixed.This happens because the controller has to be near device’s physical position atthe moment of installation, to finalize it.

4.1 Network Management

The network management goal of Z-Wave is that the user should not be respon-sible for any type of actual management. The owner needs a network free ofmaintenance and that can be easily configured. In fact, the network must be

23

autonomous. This is certainly the greatest challenge to overcome. The followingsubsections describe management properties of Z-Wave networks.

4.1.1 Self-Organizing

What defines a self-organizing network is the capability of the network to recon-figure itself to discover new nodes and transmit information to those nodes in anefficient way. It should not be mandatory for every node to be in direct contactwith each other. But it is important that the path to any node to be known assoon as the message initiator knows to which node it should transmit the message.

4.1.2 Self-Healing

A self-healing network will, due to obstacles or changes, adapt itself to rerouteany message that cannot be sent using a pre-determined path. This re-routingprocess is important if a node suddenly is down, changed position in the networkor obstacles have come in the way of the transmission path.

4.1.3 Routing Principles

To ensure that each device knows its position on the network and the surroundingenvironment (in terms of Z-Wave network topology), during the inclusion process,the controller enquiries the slave device about which nodes can be reached fromthe slave’s position, despite this any node can be used for its routing capabilitiessince all of them are always able to retransmit messages as said in [3]. A routingtable is created or updated and this table represents the instant topology of thenetwork, as it can be seen in table 4.1. The routing table represents how each nodeis connected within the network. Each device is represented in both a column anda row, building a matrix wherein each cell numbered one represents a connectionbetween the devices of the corresponding column and row. For example, in table4.1 there is a connection between device 1 and 2, as shown in Figure 4.1.

Table 4.1: Routing Table

1 2 3 4 5

1 0 1 0 0 0

2 1 0 1 1 1

3 0 1 0 1 1

4 0 1 1 0 1

5 0 1 1 1 0

24

Figure 4.1: Network Topology

The controller always tries to reach the node directly, but if it cannot, thenit will try to determine its position on the network. To do this, it will use twoparameters: the most used nodes list and the preferred repeaters list. The mostused nodes list is a list of nodes that the controller already contacted directlyand prioritized by how often they are available, after that the controller tries toreach the most used repeater nodes which represent the shortest number of hopsto reach a given destination. This is detailed in reference [4].

Figure 4.2 shows how the process of retransmission of messages works.

Figure 4.2: Routed Acknowledge Frame Type

4.1.4 Association Process

Besides the inclusion/exclusion process, during the initial stage of network instal-lation and configuration, nodes can be configured to be controlled or control othernodes. This is designated as association. It consists of devices being configuredto act directly with other nodes, without network interference. The controller orcontrollers of the network can set up associations between devices. An associationis a logical connection between two devices that allow one device to control an-other device function directly. Typically, a device that consists of wall switches,say four, can have one of its switches control another switch in another room.

4.1.5 Inclusion Process

Nodes can be included/excluded or associated with other nodes. Inclusion/exclu-sion can only be performed by a primary controller on the network, the controller

25

that controls all other controllers and/or devices. The inclusion process is initiatedby activating an initiator (typically a button or a set of buttons) on the deviceand the controller. When the controller receives information from a new devicethat had its initiator activated, it will automatically assign the Home ID and aNode ID to the device. During the inclusion process, if the device is a controllerthe routing tables in the primary controller are automatically transferred to thenew controller.

4.2 Z-Wave Frame Format

According to [4], the Z-Wave application layer comprises two types of commands:Application Specific Commands and Z-Wave Commands. A diagram depictingthis difference can be seen in [3]. Figure 4.3 shows it. This is confirmed in [5].

Figure 4.3: Application Layer Organizational Diagram

In fact [5] specifies that the Z-Wave application layer frame format consistsof:

- Single/Multi/Broadcast Frame Header;

- Application Command Class;

- Application Command;

- Sequence of command-specific Parameters.

Each of these items is 8 bits long as shown in figure 4.4 of [5].There are two set of command classes, one for each type of command:

- 0x00 - 0x1F Reserved for the Z-Wave Protocol

- 0x20 - 0xFF Reserved for the Z-Wave Application

26

Within this project’s scope, only Z-Wave Application commands will be used.Z-Wave Protocol Commands are only used by controllers to obtain either HomeID’s or Node ID’s, except in more complicated devices, not studied here, wereadditional network management functions might be necessary. This is referencedin [4]. To interact with different types of devices, specific classes of commands arenecessary, for example: a switch makes use of a different command class than asensor. As necessary, further along this document, the codes for command classeswill be revealed, as well as specific commands within those classes. Up to thismoment in the development process, the known commands include SET, GETand REPORT.

Figure 4.4: Application Layer Frame Format

4.2.1 Z-Wave Application Layer

The first step to build a Z-Wave network is to include a device in the network usingthe controller. In this case, the Aeon Labs Z-Stick controller is used to includethe Qees Switch. The controller is put on discovery mode and placed close to thedevice, the inclusion button on the device is pushed and both devices interact.After that the controller signals, through a blue led, that the device has beensuccessfully added to the network. Figure 4.5 depicts this interaction betweencontroller and device.

Figure 4.5: Interaction Between Devices During Network Inclusion

The Aeon Labs Z-Stick Z-Wave controller is connected to the computer through

27

an USB port.When the device drivers are being installed it can be seen that aCP2102 USB to UART converter from Silicon Labs is used to communicate withthe microcontroller that implements the Z-Wave API in the controller. This wasconfirmed in [6, p. 6] this can also be confirmed in [3]. Using a serial port termi-nal/monitor to connect to the COM port of the CP2102 drive with the settings115200 bps, 8 data bits, no parity, 1 stop bit, it is possible to see what is beingsent and received between the computer and the Z-Wave controller. Figure 4.6depicts how the monitorization of traffic takes place.

Figure 4.6: Data Monitorization Diagram

4.2.2 Application Frame Format

After the inclusion process takes place, the next step is to test the device. To testthe device the first thing to do is press the button on the Qees Switch. This buttonis used both for inclusion as well as reporting data. When this button is pressed (ineither ON or OFF position) a message is sent to the controller containing certaindetails such as: switch state and Node ID, at least. Furthermore, by looking at[1, p. 23, Table 1] it is possible to see some of the parameters that are present ina frame. In this context, not all the details are important, but it can be assumedthat a parameter length of frame, command value, command, data byte and achecksum are present and these are the most relevant right now. In the samedocument a few more important informations are present: the sizes of some ofthese commands and how the checksum is calculated.

- Source ID - 8 bit;

- Length - 8 bit;

- Command - 8 bit;

- Command Value - 8 bit;

- Data byte - 8 bit;

- Checksum - 8 bit.

This is the frame format for Z-Wave Application commands. Below is a figureto better illustrate this, Figure 4.7.

28

Figure 4.7: Z-Wave Application Commands General Frame Format

29

30

Chapter 5

Exploring Z-Wave Messages

The Qees Power Switch was included in the Z-Wave network and the setup de-scribed in 4.2.1 was used to listen to the messages exchanged between the applica-tion software. When the switch is pressed on the Qees device, the result obtainedin the serial communication channel was the following byte sequence in hexadeci-mal notation, repeated 4 times with a one second interval:<01 16 00 49 84 02 10 04 10 01 85 25 70 72 31 32 77 73 75 27 86 EF

20 9D

The first character of the sequence represents the direction of the messagefrom the application perspective: ’<’ for received and ’>’ for sent messages.

According to the Qees Switch datasheet [7], one push on the button performs aSend Node Info command, so it can be assumed that this is a frame that containsall the relevant information about the device. As detailed earlier in Figure 4.4, theframe starts with a header. This is tested by pushing the button on the Qees deviceand then using a terminal to send the hexadecimal character 0x06, which resultedin receiving only one of the frames instead of the original four repeated frames insequence being sent by the device. The Z-Wave frame format is presented in anhexadecimal notation. Note that the first character in the frame is named Startof Header (SOH) in the ASCII table. Assuming this is in fact true, it can alsobe expected that the character ACK or 0x06 is the acknowledge for the Z-Waveprotocol.

Knowing how to calculate the checksum for a certain message is only useful ifthe rest of the message is correct. Using the Qees device as a test device and theZ-Tool a few messages were observed during the network initialization and devicediscovery process. In this process, Z-Tool asks the controller for details about theZ-Wave network, such as: home ID, number of nodes, each node ID, node type,node location regarding its neighbours and node name as well as ON and OFFbuttons and a dimmer level control. The first excerpt of communication duringthe Z-Tool initialization process is:>01 03 00 02 FE

<06<01 25 01 02 05 00 1D 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 03 01 C0

>06

31

So far, the known parts of the protocol are the SOH (start of header), ACK(acknowledgement) and CHK (checksum) bytes. Also, from experience with Z-Wave devices it was found that NACK with value 0x15 and CAN with value0x18 are also valid Z-Wave network responses when messages are not correct anda device cannot be found respectively. Naturally, there is a length byte in all frameswith variable length fields as mentioned in Table 1 of [1]. By looking at the firstmessage, byte 2 with value 0x03 can be interpreted as the length byte if the lengthis counted as the number of bytes between the SOF and checksum excluding both.Message 01 03 00 02 FE, has all three Z-Wave information bytes underlined.To confirm this, the network controller response is also evaluated. Byte 0x25

converted to decimal is 37. By counting the number of bytes, excluding the onesalready refereed, it can be verified that the second byte in a Z-Wave message is thesize of that same message in bytes. This can easily be confirmed for any Z-Wavemessage.

After the byte that indicates the size of the payload in each frame, it wasobserved that the next byte was always either 0 or 1 and alternating betweenconsecutive messages between the two devices. This pattern resembles like a ques-tion/answer pattern back and forth between the two devices. Following this lineof thought, the requests are the ones identified by 0x00 and the responses the onesidentified by 0x01.

To completely decode the Z-Wave frame presented previously, there are stillsome parts missing. The original request was:>01 03 00 02 FE.

Within the response frame, bytes 4 to 7 and 37 and 38 are unknown, andunderlined just below:<01 25 01 02 05 00 1D 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 03 01 80

From the original request, the known parts are the following bytes: start offrame, size of payload, request/response and checksum as depicted in Table 5.1.

Table 5.1: Frame Fields

Start of Frame Size of Payload Request\Response ... Checksum

Byte 4 with value 0x02 in the request, is the command to request every nodeID in the network, and as expected, a request has a correspondent response.Therefore, in the response byte, the original command is also present in position4, 0x02. To reach this conclusion, the whole initialization process was taken intoconsideration and it was noticed that the fourth byte of each request, correspondedto the fourth byte of each response, therefore byte 4 with value 0x02 appears tobe the code to request every node ID in the network. From this behaviour it canbe assumed that this is the ”code” for the operation to perform on the networkand/or device.

Bytes 0x05 and 0x00 appear to have no immediate meaning, but byte 0x1D,which in decimal notation is 29, is the number of bytes by counting position 8(0x43) and the next 28 zeroed bytes. Can these 29 bytes be used to mask the

32

whole 232 possible devices? In digital logic 1 bit is capable of identifying one unit.In [9, p. 17] states that ”... system protocol preferably comprises a procedure formasking device identifiers in a table in order to generate a string of bits makingup the bitmask so that each bit corresponds to a device identifier, the value of eachbit determining whether the one or more commands applies to the correspondingdevice.”. What this means, essentially is that 1 bit masks 1 device, so 1 bit x 8bits per byte x 29 bytes = 232. This is the number of devices that are possibleto mask. If these 29 bytes are indeed used to mask the whole Z-Wave network ofdevices, the bytes left, 0x03 and 0x01 should be some kind of information bytes,since network commands come before parameters in the Z-Wave frame structureas shown in 4.4. These bytes were not changed with the addition of new devicesto the network.

From now on the acknowledgements are omitted to focus on the messages data.The next messages in the Z-Tool initialization process (the acknowledgements wereomitted, and the byte that seems to indicate the node ID’s is underlined), are:>01 04 00 41 01 BB

<01 09 01 41 92 16 00 02 02 01 33

>01 04 00 41 02 B8

<01 09 01 41 D2 9C 00 04 10 01 ED

>01 04 00 41 07 BD

<01 09 01 41 C9 0C 00 04 11 01 67

These messages were recorded after adding the second device, with ID=7, tothe network. Before that, only the first 4 messages were exchanged between theZ-Tool and the controller. Since all other bytes in the request are known, thismeans that the controller inquires each device, with a command 0x41 probablyused for enquiring the device about its type or some other kind of initial importantinformation regarding the device. This is repeated for each device. Up until bytewith value 0x41 of the response, inclusively, the meaning is known, from thatbyte on until the checksum byte the meaning is still unknown. This group ofunknown bytes, has some type of repetitive pattern: for every device the latestbyte is 0x01, the first two bytes are different for each device. An interesting factis that the fourth byte is the same in two devices, one is a binary switch andthe other is a dimmer. Between these two devices the difference is the fifth byte0x010 for the switch and 0x11 for the dimmer, which in some documentation isalso referred as a multilevel switch. This fact leads to the conclusion that bytefour, 0x04, is probably indicating that the device is a switch. This is supportedby the fact that between the dimmer and the binary switch, the only thing incommon is the fact that both turn a load (e.g. lamp, kitchen appliance) on andoff, also the dimmer might be understood as a specialization of a switch. The factthat the device with ID=2, the network controller, has the fourth byte with value0x02, leaves a bit of suspicion about the line of thought followed. Should not thecontroller be designated as the first type of device? Or is there more than one typeof controller? Based on [8], there are two types of Z-Wave network controllers,Static and Portable controllers. This seems to indicate that the previous line of

33

thought was correct, but there are not enough facts to support this claim.The following messages in the Z-Tool initialization process are:

>01 03 00 20 DC

<01 08 01 20 00 00 62 6A 01 DF

The response to the request, byte 0x20 is pretty straightforward to interpret.The Z-Tool GUI guide indicates that the network Home ID is 00 00 62 6A, pre-cisely the number in the response to our request. Therefore, it is concluded that0x20 is the code to request the Home ID. The second underlined byte in the re-sponse with value 0x01 also occurs in previous interpreted message responses allwith the form:<01 09 01 41 XX XX XX XX XX 01 67

The meaning of this byte is still unknown, but since it repeats itself in severalmessages with the same value, it should not be ignored.

The following request and response were:>01 03 00 07 FB

<01 2B 01 07 03 07 00 00 00 01 00 01 FE 80 FE 88 0F 00 00 00 FB 97

7F 82 07 00 00 80 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 47

Request 0x07 above in red, provides a response with a lot of information, 40bytes. However, the meaning behind all of this data remains unknown, since thereis no comparison term with similar messages.

5.1 Checksum Calculation

As stated in [1] the checksum is ”calculated between Home ID and the last byte ofthe frame. The Checksum field itself is not calculated.”.

The last byte in a frame is the checksum, as it happens in other protocolspecifications. The SOH does not take part in the checksum calculation since itis only a control character, it marks the beginning of a new frame. As statedbefore, the checksum field itself is also not subject to calculation, so the calcu-lation should use only the remaining bytes from SOH to CHK excluding both.The operation or operations to perform are not known, nor the order in whichthey are performed and neither is their complexity, but for what has been extrap-olated from the observations so far, the protocol is fairly simple and intuitive andso should be the checksum calculation. Using Z-Tool it was possible to interceptthe communication taken place between that software and the Z-Wave controller.Although Z-Tool only performs some simple Z-Wave commands, they should beenough to provide relevant information regarding the checksum.Three examples of Z-Wave messages can be seen next:>01 03 00 02 FE

<01 03 00 20 DC

<01 03 00 15 E9

34

Since we have several excerpts of Z-Wave communication available, it is possi-ble to apply different checksum algorithms to try to find the one used by Z-Waveusing a trial and error approach. Researching for possible checksum algorithms asmall list of a few simple algorithms was found in [10], resulted in a list with threepopular algorithms used to calculate 8 bit checksums:

- sum8;

- fletcher-8;

- xor8.

In a short description, the sum8 algorithm is the sum of all the bytes in theframe, the fletcher-8 is a simple sum of bytes in a slightly different way and thexor8 is the XOR operation of all the bytes in the frame. The fletcher-8 algorithmwas easily discarded since its result is two 8 bit values that are appended to themessage frame, not complying with the Z-Wave standard of only one checksumbyte. The application of sum8 and xor8 algorithms, although size compliant withthe Z-Wave checksum, resulted in values different from those expected. Duringthe comparison process, by looking at the checksum written in binary form it wasfound that the Z-Wave checksum was the bitwise negation of the xor8. After sometesting, this checksum calculation was found to be successful as it can be seen inthe example below.

Example:0x03⊗ 0x00⊗ 0x02 = 0x01NOT (0x01) = 0xFE

Full Message:01 03 00 02 FE

5.2 Node Identification

A Z-Wave network is capable of addressing up to 232 devices. During the ini-tialization process, the Z-Tool identifies how many nodes are part of the networkand its ID numbers. Adding one device to the network at a time and registeringthe differences between frames sent back and forth allowed to draw some veryinteresting conclusions. To begin with, mapping 232 device IDs requires, or itcan be assumed to require, a fair amount of information. As stated earlier, [9,p. 17] and now [1, p. 20] ”In order to reduce the amount of data transferred ineach frame, the system protocol preferably comprises operational procedures formasking the identifiers of devices addressed by a frame.”. These statements, fromofficial Zensys documents shed important light on how the ID information can befound: it is masked. However, this masking procedure is not obvious. One thingthat stands out in the first few messages the Z-Tool software exchanges with anew Z-Wave network configuration (using a device with ID=2 and before addinga second device) to obtain all the necessary information to interact with it are two

35

frames with an exceptionally large size (and with a lot of bytes with value 0x00).The frames are the following:<01 25 01 02 05 00 1D 03 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 01 C0

<01 2B 01 07 03 07 00 00 00 01 00 01 FE 80 FE 88 0F 00 00 00 FB 97

7F 82 07 00 00 80 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 47

After adding a second device (with ID=7):<01 25 01 02 05 00 1D 43 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03

01 80

<01 2B 01 07 03 07 00 00 00 01 00 01 FE 80 FE 88 0F 00 00 00 FB 97

7F 82 07 00 00 80 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 47

The difference between these two situations are the above underlined bytes.Now the question is how can the byte 0x03 represent both the controller ID andthe first device with ID=2 and byte 0x43 represents all the previous mentioneddevices plus the second added device with ID=7? At first glance, it does not seemsimple to decipher this mask, but representing these numbers in binary notationleads to a clearer view of the masking process.

Taking a careful look at Table 5.2, is now clearer how the already known ID’srelate with the bytes sent. Byte 0x03 has bits 1 and 2 active, for a controller withID=1 and a device with ID=2, and byte 0x43 has also bit 7 active and a newdevice with ID=7. This information seems to indicate a simple masking process,and by adding more devices to this network, it becomes a certainty: each bitrepresents one device ID. The bit position indicates its ID number.

Table 5.2: Byte masking table

Byte Position 8 7 6 5 4 3 2 10x03 0 0 0 0 0 0 1 10x43 0 1 0 0 0 0 1 1

5.3 Z-Wave Version

The last response to a request made by Z-tool software to the Z-Wave network is:>01 03 00 15 E9

<01 10 01 15 5A 2D 57 61 76 65 20 32 2E 37 38 00 01 9B

The response to the request with code 15 provides information that, on afirst look, does not appear to be anything evident. Since there is no possiblecomparison, it is very difficult to make educated guesses on what that informationis. Using the ASCII table as a reference, and converting the received bytes to theirdecimal and char equivalents it turned out to be rather interesting, as it is shownin Tables 5.3 and 5.4.

36

Table 5.3: Response to the version request of the Z-Tool Initialization Process

Hex 0x5A 0x2D 0x57 0x61 0x76 0x65Char Z - W a v e

Decimal 90 45 87 97 118 101

Table 5.4: Response to the version request of the Z-Tool Initialization Process

Hex 0x20 0x32 0x2E 0x37 0x38Char 2 . 7 8

Decimal 32 50 46 55 58

In conclusion, the request with code 15 obtains the Z-Wave version of theprotocol implemented in the Z-Wave controller can be obtained.

The following information regarding Z-Wave versions can be found freely inthe Internet [11]:

- 2.40 = Zensys Firmware 4.27;

- 2.48 = Zensys Firmware 5.02;

- 2.60 = Zensys Firmware 5.02 Service Pack 2;

- 2.78 = Zensys Firmware 5.02 Service Pack 3.

Hence, the Z-Wave dongle that was used in this work has a firmware withversion 5.02 and a Service Pack number 3.

5.4 Device Interaction

The Z-Tool software, besides its initialization process, features a few options totest functionalities of common Z-Wave devices, for example: switching on and offa switch or a dimmer and dim the load up to a desired level. It also features thepossibility of getting the name and location of Z-Wave devices in a network andsetting new names for them.

Tests were made in order to observe the network traffic when tasks are per-formed on devices in the network.

5.4.1 Basic Switch

On a first test using the Qees Wall switch, Figure 5.1, here with ID=2, it wasattempted to switch it on while it is not powered.

37

Figure 5.1: Qees Power

Intercepted Z-Wave frames in a communication are:>01 0A 00 13 02 03 20 01 FF 05 03 3F

<01 04 01 13 01 E8

<01 05 00 13 03 01 EB

5.4.1.1 Turn On

A first message is sent to turn the Qees Wall switch on using the Z-Tool softwarealthough it can also be turned on by means of a physical button. The secondand third messages, underlined below, are at the moment unknown. Every timea request is made the first underlined message appears either directed to a spe-cific device or several. This message has been the same every time a message hasbeen successfully delivered to the network. A confirmation could not be obtained,however so far this seems to be its meaning. Since the switch is not turned on,the controller should reply with some type of error saying it cannot find the node.To better understand how this process takes place, it is necessary to compare thismessage with a different one sent when the switch is powered, to turn it on.>01 0A 00 13 02 03 20 01 FF 05 03 3F

<01 04 01 13 01 E8

<01 05 00 13 03 00 EA

This results in the device being switched on.By comparing both scenarios were the switch was turned on, with and without

the device being powered, it can be seen that apparently the controller tries tosend the same message twice to the device when it does not acknowledge that amessage was received the first time. Another important thing is that the bytemarked in bold changed according to the device being powered or not. In theprevious subsection 5.4.1, this byte had value 0x01, after being powered its valuechanged to 0x00. As such this indicates that value 0x01 is a Node Not Found andvalue 0x00 is a Node Found information.

5.4.1.2 Turn Off

To actually see which command is sent to turn the switch on and off, it is neces-sary to turn the switch off using Z-Tool and compare the messages.

38

>01 0A 00 13 02 03 20 01 00 05 03 C0

<01 04 01 13 01 E8

<01 05 00 13 03 00 EA

The underlined byte 0x00 is different from the byte in the same position sentin previous message. When the device is turned on this byte has the value 0xFF.It is fair to deduce that this byte is the one that indicates the state that the switchshall be, either ON or OFF.

5.4.1.3 Get Status

To inquire the switch state it is necessary to use the command class BASIC andperforme a GET command to the switch. The GET command is 0x02 as under-lined below. Also, as shown before in picture 4.4, following the command classcode there is a command. The Node ID remains the same, 0x02.

When the switch is OFF and a request for its status is made, the followingmessages are observed.>01 08 00 13 02 02 20 02 05 C3

<01 04 01 13 01 E8

<01 09 00 04 00 02 03 20 03 00 D0

Repeating the query when the device is turned on, makes evident the bytethat contains the sate. In the last message from the total of the transmission, theunderlined byte is the status of the switch. As observed and stated before, 0x00means that the switch is turned OFF and 0xFF signals the ON state.>01 08 00 13 02 02 20 02 05 C3

<01 04 01 13 01 E8

<01 09 00 04 00 02 03 20 03 FF 2F

5.4.2 Dimmer Switch

The ZDM230 multilevel switch, Figure 5.2, is also tested using Z-Tool. The soft-ware has a multilevel control that enables the user to dimm a load to a selectedlevel. Besides a multilevel control, the ON and OFF buttons are also present andcontrol the multilevel switch as if it were a binary switch.

5.4.2.1 Turn On

The multilevel switch has ID=7. When the multilevel switch is turned sent a TurnOn command, the messages sequences is the following:>01 0A 00 13 07 03 20 01 FF 05 03 3A

<01 04 01 13 01 E8

<01 05 00 13 03 00 EA

39

Besides the difference of the device ID, the message sent to the device is exactlythe same as the one sent to turn on the Qees Power binary switch. It makes useof the same command class and the same method, GET, here represented with0x20 and 0x01 respectively.

Figure 5.2: ZDM230 Dimmer Switch

5.4.2.2 Turn Off

As stated in Section 4.2.1, everything leads to the belief that the multilevel switchis a specialization of the binary switch, and as such the commands used to oper-ate the binary switch are the same used for the multilevel switch. The other wayaround is not be true.To turn the multilevel switch off it is only necessary to send the same commandas before with the value 0x00, as it can be seen below.>01 0A 00 13 07 03 20 01 00 05 03 C5

<01 04 01 13 01 E8

<01 05 00 13 03 00 EA

5.4.2.3 Get Status

Since the multilevel switch is a specialization of switch, the procedure to get thecurrent status of the former is similar to the one used for the latter, changing onlythe Node ID (in this case 7). With the dimmer regulated to about 20% of theload, the result of the enquiry was the following.>01 09 00 13 07 02 20 02 05 16 D1

<01 04 01 13 01 E8

<01 05 00 13 16 00 FF

<01 09 00 04 00 07 03 20 03 19 CC

The third message in the previous response is similar to other messages alreadyreceived but due to the different value of one of its bytes, 0x16 might have a dif-ferent meaning. When messages with a format like the one below are received, thebyte shown as XX is always equal to the byte before the checksum in the originalrequest, in this case, 0x16.<01 05 00 13 XX 00 CHK

40

Since there is a link between the request and one of the messages of the re-sponse, this might be used as a message tracking mechanism so that the controllerknows from which device the response comes from. In every situation so far, thereare only two situations present: either the two bytes before the checksum in therequest do not exist and the response does not contemplate the message with theformat above, or those two bytes exist and the response has the message with itsXX byte with value equal to the one that the byte before the checksum has in theoriginal request. Further studies of this situation would be required to confirmthis information. The underlined byte in the fourth message is the returned statedata, in this case 0x19 in decimal notation is 25. As in the previous case, thisvalue is in percentage. At this point a new response stands out.

To confirm that this is in fact the value of the multilevel switch being read,the next step was to regulate it to two known points: no load and full load.

With no load, the value read is 0x00, at full load status the value is 0x64

or 100% as for the Qees Power Switch, in a few intercepted messages this is theresult.No Load:<01 09 00 04 00 07 03 20 03 00 D5

Full Load:<01 09 00 04 00 07 03 20 03 63 B6

5.4.2.4 Dimm the Load

After being successful at turning the multilevel switch on and off, the next step isto dimm the multilevel switch to a desired level.

For this to happen, it makes sense that there is one dedicated command classfor this type of device, i.e. multilevel switches, and one command class for basicswitches. However, it also makes sense to expect that the basic switch commandclass is supported by multilevel switches, since these can also react to ON/OFFcommands accordingly. Using the Z-Tool multilevel control and regulating it to97% results in receiving the following messages:>01 0A 00 13 07 03 20 01 61 05 03 A4

<01 04 01 13 01 E8

<01 05 00 13 03 00 EA

Once again the only difference is the value sent to the device, the type of re-quest sent is exactly the same. Value 0x61 written in decimal notation correspondsto 97, i.e. 97% of the possible dimm level.

In conclusion, it can be said that the value sent to the multilevel switch can beeither 0x00 or 0xFF to act as a binary switch, or from 0x01 (1%) to 0x64 (100%)if the desired behaviour is the one of a multilevel switch.

41

5.4.3 Power Meter

5.4.3.1 Instant Energy Consumption

To read the instant energy consumption value measured by the power meter in-cluded with the Qees Power Switch, it is necessary to send a request to the device,read the value and interpret it. It is also necessary to have a load turned on bythe switch. A 11 Watt lamp was used.

As [12] states, ”The Module will report its instant or accumulated energy con-sumption to Z-Wave Controller.” and ”When receiving Meter Get Command, itwill report Meter Report Command to the node of Grouping 1.” This documentalso specifies that the structure of both commands is:

Table 5.5: Meter Get Command Structure

Meter GetCommand Class Meter Meter Get Scale

Table 5.6: Meter Report Command Structure

Meter ReportCommand Class MeterMeter ReportRate Type + Meter TypePrecision + Scale + SizeMeter Value 1Meter Value 2

And how to calculate the final value from the message’s meter values fields.

Meter (W) = Meter Value 1 * 256 + Meter Value 2 = result

As it is already known, the structure of a Z-Wave frame includes a commandclass byte, after the byte that indicates the number of command bytes sent andbefore the command class command byte. Comparing with the command class listin [13] the command class found is 0x31, named SENSOR MULTILEVEL. In themessage sequence immediately below and as referred in [12], after the commandclass code, comes the command class GET (0x04) and the Scale (0x02). The finalbyte is the checksum.>01 0A 00 13 02 03 31 04 02 05 2A FF

<01 04 01 13 01 E8

<01 05 00 13 2A 00 C3

<01 0C 00 04 00 02 06 31 05 04 22 00 69 88

42

Therefore, according to [12] the following values for the various fields areobtained: Command Class Meter (0x31), Meter Report (0x05), Rate Type +Meter Type (0x04), Precision + Scale + Size (0x22), Meter Value 1 (0x00) andMeter Value 2 (0x69), 105 in decimal notation. According to the formula tocalculate the instant energy consumption, the result is:

Meter (W) = 0 * 256 + 105 = 105 Watts

This is not coherent with the load attached to the binary switch, (11 Watt),but if the value read from the power meter is interpreted as 10,5 Watt, then itwould be ok. Several loads were tested to evaluate this hypothesis, and theyproved it to be true.

5.4.3.2 Accumulated Energy Consumption

The power meter is capable of registering the total energy consumption of everyload ever used by the device. Using the instantaneous values measured throughoutthe device life of operation, the device calculates the energy consumption. Thiscounter can be reset if necessary. The request made to the device is structuredlike stated in [12] and similar to the structure of the previous request. The requestuses the following commands:

- 0x32 - Command Class Meter;

- 0x01 - Command Class Get;

- 0x01 - Scale;

- 0xD6 - Checksum.

The request is:>01 08 00 13 02 02 32 01 01 D6

<01 04 01 13 01 E8

<01 0E 00 04 00 02 08 32 02 01 A4 00 00 3F DD 88

The response to the previous request is interpreted as:

- 0x32 - Command Class Meter;

- 0x02 - Command Class Report;

- 0x01 - Rate Type + Meter Type;

- 0xA4 - Precision + Scale + Size;

- 0x00 - Meter Value 1;

- 0x00 - Meter Value 2;

- 0x3F - Meter Value 3;

- 0xDD - Meter Value 4.

43

The total energy consumption calculation is detailed by the equation in [12]:

Accumulated Energy Consumption = Meter Value 1 * 232 + MeterV alue2 ∗216 +MeterV alue3∗28 +MeterV alue4∗20 = 0+232 +0+216 +63∗28 +221∗20 =16128 + 221 = 16349

According to [14], the value read can be up to 5 decimals precision and isgiven in KW.h, hence the value should be read as 16349 KW.h. In section 1.3 it isstated that ”Measurements are accurate to 0.1 watt or 1% depending on the loadsize.”. Also according to the same document the calculated value has a given scaleand precision. This leads to the conclusion that the value is in fact not 16349 buta decimal variation of it such as: 1,6349 or 16,349 for instance.

Listing 5.1 is an excerpt of code taken from a project called Open-zwave.This project is meant to be a Z-Wave API with support for every Z-Wave de-vice. This specific code is taken from a file named Meter.cpp from [15], whichis, as it is written at the beginning of the file, ”Implementation of the Z-WaveCommand Class Meter”. Paying attention to a specific function in this file thatis listed in 5.2, several details can be dissected.

The first condition to be met is if data[0] variable is equal to the value of avariable declared at the beginning of the file, MeterCmd Report. In the responseobtained earlier, the value of the MeterCmd Report was 0x02, hence this condi-tion is met, so the program execution flow enters the condition. This variable isdepicted in Listing 5.2.

Listing 5.1: Excerpt of code from open-zwave Project

{enum MeterCmd{

MeterCmd Get = 0x01 ,MeterCmd Report = 0x02 ,MeterCmd GetSupported = 0x03 , // Vers ion 2 OnlyMeterCmd ReportSupported = 0x04 , // Vers ion 2 OnlyMeterCmd Reset = 0x05 // Vers ion 2 Only

} ;}

After entering into the part of the program that concerns the meter readings,it is necessary to decode the next few bytes. The first byte to be processedis the scale, here shown as data[2], which is used as an argument to functionExtractValueAsString. The second byte is used to determine, within a switch casecycle from which type of meter is the reading from. 0x01 for electricity meter,0x02 for a gas meter and 0x03 for a water meter.

Within the switch case cycle, the units are set for this type of reading withthe value->SetUnits( c electricityUnits[scale] ); expression. This expression readsthe position given by scale, in this case, the value returned by the ExtractVal-ueAsString function, which should be the first of the following depicted at thebeginning of the Meter.cpp file, that is, the one with value 0 and shown in listing5.3. Since what it is being discussed here are accumulated power consumptions itonly makes sense that these are shown relative to time and as shown in section 4of [12], the scale parameter can either be 0x00 for KWh or 0x02 for W, which isconsistent with the variable disposition in the c electricityUnits[] array, position

44

0 for KWh and position 2 for W (Watt).

Listing 5.2: Excerpt of code from open-zwave Project

{i f (MeterCmd Report == (MeterCmd) data [ 0 ] ){

s t r i n g va lueSt r = ExtractValueAsStr ing ( & data [ 2 ] , &s c a l e ) ;

i f ( ValueDecimal∗ value = m value . GetInstance ( i n s t an c e ) ){

i f ( value−>GetLabel ( ) == ”Unknown” ){

switch ( data [ 1 ] ){

case 0x01 :{// E l e c t r i c i t y Metervalue−>SetLabel ( ” E l e c t r i c i t y ” ) ;value−>SetUnits ( c e l e c t r i c i t yU n i t s [ s c a l e ] ) ;break ;}case 0x02 :{// Gas Meter}case 0x03 :{// Water Meter}

}}

}}}

Listing 5.3: Excerpt of code from open-zwave Project

{s t a t i c char const∗ c e l e c t r i c i t yU n i t s [ ] ={

”kWh” ,”kVAh” ,”W” ,””

} ;}

5.4.4 Sensor

The HomeSeer HSM100 is a 3 in 1 device. It features an embedded motion detec-tor, temperature sensor and a luminance sensor. Moreover, it allows the controllerto monitor its battery level. It is shown in Figure 5.3.

Figure 5.3: HSM100 3 in 1 Sensor

45

This device has one blue button, which is used to perform the inclusion/exclu-sion/awake processes. When awaken, the device will report back to the controllerthe data collected by each of its sensors upon request.

At this point, because of the lack of interaction of the Z-Tool software withsensor devices it was necessary to use another tool named HomeSeer Pro. This toolis used in a personal computer with the Aeon Labs USB Z-Stick. After adding thedevice to the network, using the HomeSeer software, several informations aboutthe sensor device were obtained. The HSM100 device manufacturer is: HomeSeerTech, with ID=30=0x1E. The type is 2 and the ID is 1, although the meaning ofthis last mentioned id is still unknown at the moment. The supported commandclasses for this device are:

- 0x60 - Command Class Multi Instance

- 0x31 - Command Class Sensor Multilevel

- 0x70 - Command Class Configuration V2

- 0x84 - Command Class Wake Up

- 0x85 - Command Class Association V2

- 0x80 - Command Class Battery

- 0x72 - Command Class Manufacturer

- 0x77 - Command Class Node Naming

- 0x86 - Command Class Version

- 0xEF - Command Class Mark

- 0x20 - Command Class Basic

Pressing the blue button results in the device sending information to the net-work, specifically, the readout of each of its sensors. The ones that are relevantfor this study are presented in the next subsections.

5.4.4.1 Temperature

Using HomeSeer one can read all the sensor values. One of the informations sentto the network controller is the temperature of the sensor within the HSM100. Bysearching, within the messages exchanged with the node, for the command classSENSOR MULTILEVEL value 0x31 the following extract of messages is found:>01 0C 00 13 0B 05 60 06 03 31 04 05 03 B8

<01 04 01 13 01 E8

<01 05 00 13 03 00 EA

<01 0F 00 04 00 0B 09 60 06 03 31 05 01 2A 02 ED 63

In this case the node ID has value 0x0B. Both classes MULTI INSTANCE andSENSOR MULTILEVEL are present in this small excerpt of communication. For

46

the time being, the use of the MULTI INSTANCE command class is still unknown.The command class SENSOR MULTILEVEL is used to report the value of thetemperature, in this case, since the value of the temperature is 74.9, according tothe HomeSeer, this value must be represented in this excerpt of communication.Temperatures are not uncommon to vary between 30 and 105 Fahrenheit or -1 and45 Celsius, therefore the values are expected to be found between the two sets ofmore commonly used temperature units. Due to the fact that values can possiblyhave four significant digits, it is likely that they are represented in two bytes. Itis far more likely, that due to the fact that values can easily go up to four digits,they are represented as two different bytes. One byte can go up to 3 digits (255),but it is not enough to represent decimal values. There are two easy options torepresent a number with four digits and a decimal parcel. Either using two bytes,one for each 2 digits, or using two bytes that can represent a number up to 65536.Either way, for representing the number 749 for example, using the first methodthe result is: 7 = 0x07 and 49 = 0x31. Using the second method, it is: 749 =0x02ED. In the last frame of the responses from the device above just before thechecksum byte, the two bytes match the latter result. To confirm this fact, a fewmore tests with different temperature values were performed.

In the previous request, the byte just after the class SENSOR MULTILEVELbyte, 0x04, appears to be an indicator that a request for a new value is being made,a Sensor Get. In the response, the byte in the same position as the previous, justafter the command class byte, appears to indicate that a response is being given,byte 0x05 Sensor Report.

5.4.4.2 Light Measurement

Similarly to the temperature reading, the luminance reading is displayed by theHomeSeer software. The luminance value ranges from 0% to 100% and one of thevalues read is 75%. Using a simple conversion of decimal to hexadecimal notationof the percentage value, results the number 0x4B, which is found in the followingextract of traffic between the controller and the device.>01 0C 00 13 0B 05 60 06 02 31 04 05 03 B9

<01 04 01 13 01 E8

<01 05 00 13 03 00 EA

<01 0E 00 04 00 0B 08 60 06 02 31 05 03 01 4B EF

After several tests with different temperature values, it is confirmed that thebyte before checksum is the luminance level. Much like in the temperature read-ing, there are indicators that a command class command Get is being sent, byte0x04, and a response, command class command Report is being given, 0x05. Fur-thermore, both the request and the response encapsulate the MULTI INSTANCEcommand class as in the temperature reading. Figure 5.4 resumes what was statedpreviously.

47

Figure 5.4: Summary of Z-Wave Frame Structure for Luminance Responses

5.4.4.3 Multi Instance

In subsections 5.4.4.2 and 5.4.4.1 two different values are read from the same deviceand one new Z-Wave feature was revealed, the MULTI INSTANCE commandclass. Every time a request is made using this command class, the bytes relatedto it in the request are exactly the same as the ones present in the response, i.e.for the luminance reading. Figure 5.5 shows this.

Figure 5.5: Multi Instance Command Class Structure

When the luminance request is compared to the temperature request read-ing some conclusions can be drawn. When reading the temperature, the thirdMULTI INSTANCE byte is the same both in the request and the response withvalue 0x03, when reading the luminance that same byte has value 0x02 as seenbelow in Figure 5.6.

Figure 5.6: Multi Instance Command Class Structure Comparison

48

One possible explanation for this fact is that the reading is made by the samecomponent but uses different channels. Much like a multi channel Analog toDigital Converter, a channel has to specified so that a reading can be obtained asthe diagram in Figure 5.7 details.

Figure 5.7: Multi Instance Data Selection Possible Diagram

5.4.4.4 Battery Level

The battery level displayed by HomeSeer is 14%. The battery level must be presentin this excerpt of the transmission, as all the other readings from the sensors do.>01 09 00 13 0B 02 80 02 05 03 68

<01 04 01 13 01 E8

<01 05 00 13 03 00 EA

<01 09 00 04 00 0B 03 80 03 0E 77

The battery level is obtained by making a request for information using theBATTERY command class, value 0x80 similar to the previous requests madeusing the SENSOR MULTILEVEL command class. There is, however a differencebetween these two command classes. The byte value used to request informationin the SENSOR MULTILEVEL command class is 0x04 and in the BATTERYcommand class that same request uses value 0x02. The same happens with thebyte used to report information, command class SENSOR MULTILEVEL usesvalue 0x05 and the BATTERY command class uses 0x03. The value of the batterylevel can be obtained by converting 14 to hexadecimal, that is 0x0E, value foundin underlined byte before the checksum in the last message of the transmissionexcerpt.

5.4.4.5 Motion Sensor

The HSM100 is a motion sensor that can respond to motion in front of it. However,this is only possible if the device is associated with another one. The motion sensoris meant to trigger some kind of action, therefore an association to a device thatperforms that kind of action is required.

49

5.4.5 Device Association

Z-Wave devices are capable of association between each other. Groups of devicescan be triggered by a state from a single device. These actions happen withoutthe knowledge of the Z-Wave controller, in fact they are interactions between thedevices and only between those devices.

To illustrate this feature an association was made between the Qees PowerSwitch and the ZDM230 Dimmer. The association request involves the followingdata:

- Node ID

- Command Class Association

- Command Class Association Set

- Group ID

- Target Node ID

The first two fields to know are the ID’s of the nodes involved, 0x02 for theQees Power and 0x07 for the ZDM230 dimmer. The command class association isrepresented with 0x85 as it is described in [13] and the command class associationcommand is expected to be represented with 0x01. Furthermore, in any Z-Waverequest, just before the checksum, at least one byte is used for some sort of controlmechanism for the messages. In this example a tentative value of 0x01 was used.

The request to perform an association between the two devices is included inthe following sequence:>01 0A 00 13 07 04 85 01 01 02 01 63

<01 04 01 13 01 E8

<01 05 00 13 03 00 EA

The two latest responses are the acknowledgement that the association processwent well. After this process, if the button on the ZDM230 dimmer is pressed once,it turns on the Qees Power Switch and pressed once again turns it off, hence anassociation exists between two devices. After the association process takes place,the interaction between both devices occurs without the main network controller,this is why this topic was not further explored.

5.4.6 Configuration Parameters

There are six known configuration parameters for the HSM100 device, as describedin [16]:

- Off Delay;

- Led Enable;

- Sensitivity;

- Wakeup Interval;

50

- Device Activation State;

- Sleep State.

These parameters can also be configured in HomeSeer. The Wake Up Intervalparameter is configured by using the WAKE UP command class. The remaining5 parameters are configured using the CONFIGURATION command class.

Each parameter is configured separately. There is one request to change aparameter and a subsequent response to confirm that change. Each parameterhas a code, included in table 5.7.

Table 5.7: Codes of Configuration Parameter for the HSM100 device

Off Delay 0x02Sensitivity 0x01Led Blink 0x03Sleep State 0x05Device Activation State 0x06

The following excerpt of Z-Wave communication is obtained when using Home-Seer to configure the Wake Up Interval parameter with a new value of 10 minutes.>01 00 13 0B 06 84 04 00 02 58 01 05 03 31

<01 04 01 13 01 E8

<01 05 00 13 03 00 EA

Before any further analysis it is necessary to find out how are the 10 minutesvalue encoded in the frame. The values can range from minutes up until hours.And the time value written in the message can also have a unit of seconds orhours. 10 minutes are 600 seconds and 0,1666 in hours. 600 seconds written inhexadecimal are 0x258, which can be found in the message in the underlined bytes0x02 and 0x58. Since up until a day can be encoded and it is 86400 seconds, inhexadecimal it results in 0x15180. Reversing the process, value 0x15180 wouldbe encoded into 3 bytes, 0x01, 0x51 and 0x80, which means all underlined bytesin the message correspond to that parameter’s value.

The byte with value 0x04 indicates that this is a Set value command which ispreceded by the command class WAKE UP byte with value 0x84.

To inquire the device regarding its configuration of the Wake Up Interval pa-rameter, it is necessary to make the request that is shown in the following sequenceof messages:>01 09 00 13 0B 02 84 05 05 03 6B

<01 04 01 13 01 E8

<01 05 00 13 03 00 EA

<01 0C 00 04 00 0B 06 84 06 00 01 68 01 10

51

In this case, the request uses a Wake Up Interval GET command with value0x05 to inquire the device about the value of the parameter. Later, in the lastmessage the device answers. Byte with value 0x06, which comes after byte withvalue 0x84 indicates that the message is a Report with the value of the parameterin the bytes with value 0x0168, or 360 in decimal, that is a total of 6 minutes.

The default Sensitivity value was changed from 200 (0xC8) to 255 (0xFF).

To set the Sensitivity to 255:>01 0C 00 13 0B 05 70 04 01 01 FF 05 03 63

<01 04 01 13 01 E8

<01 05 00 13 03 00 EA

As it can be noted above 0xFF represents the Sensitivity value. That value isconfigured using the CONFIGURATION command class, byte 0x70, a parameterwith value 0x04 followed by the parameter number, 0x01 for the sensitivity andanother byte with value 0x01 which function is unknown. The next value is theSensitivity value.

To ensure that this value was correctly sent, the device sensitivity is then readusing the HomeSeer Web Interface. Among other communications the result is:>01 0A 00 13 0B 03 70 05 01 05 03 9C

<01 04 01 13 01 E8

<01 05 00 13 03 00 EA

<01 0B 00 04 00 0B 05 70 06 01 01 FF 77

Apparently, the Sensitivity is read by sending a request using the CONFIG-URATION command class, 0x70, with the GET parameter 0x05, to the configu-ration item 0x01 also known as Sensitivity.

The response is very straightforward. As expected the response is 0xFF (255),as setted before. After the CONFIGURATION command class byte 0x70, comesthe byte that indicates a response 0x06 followed by the parameter code, in this case0x01 for Sensitivity, and another byte 0x01 with meaning unknown just beforethe actual value.

Another test was conducted to ensure that this interpretation is valid.

Set the Sensitivity to 200:>01 0C 00 13 0B 05 70 04 01 01 C8 05 03 54

<01 04 01 13 01 E8

<01 05 00 13 03 00 EA

Get the current value of Sensitivity :>01 0A 00 13 0B 03 70 05 01 05 03 9C

<01 04 01 13 01 E8

<01 05 00 13 03 00 EA

<01 0B 00 04 00 0B 05 70 06 01 01 C8 40

The rest of the parameters are configured as the Sensitivity, but the byte codeto be used is different and consequently the message will suffer some changes.

52

All the parameters were tested exactly the same way as the Sensitivity was, andall of them worked.

5.4.6.1 Dimmer Switch Configuration Parameters

The ZDM230 multilevel switch features two blue LED in the front of the device.Those LED’s are used among other things to acknowledge the current device state(ON or OFF ). Several other features are available to the user. One of the mostimportant configuration parameters allows the user to configure one of the LEDto be used as a night light. It features two options: LED on when the switch isON or LED off when the switch is ON.

To configure the Night Light parameter it is necessary to use the CONFIGU-RATION command class and the parameter number and value to be sent. In thiscase, each parameter number and range of allowed values is described in [18] aswell as [17].

It is possible to configure the device using this information and generating aframe that includes a SET command to the CONFIGURATION command classwith a given value (in this case either 0 or 1). The excerpts of communicationbetween the Z-Wave controller and the device below demonstrate how to configurethe Night Light parameter. To test the parameter setting feature the HomeSeersoftware was used. The essential information to set a parameter on a Z-Wavedevice is:

- Name: Night Light;

- Parameter Number: 3;

- Range of Values: 0-1.

To turn the Night Light parameter OFF when the switch is ON and use it asa night light the following message is sent:>01 0C 00 13 07 05 70 04 03 01 01 05 22 B2

<01 04 01 13 01 E8

<01 05 00 13 22 00 CB

On the request, the first underlined byte represents the parameter number tobe configured and the second underlined byte represents the value of that param-eter. Below is the message necessary to turn the Night Light parameter ON whenthe switch is ON. To turn the LED ON when the switch is ON as it can be seen,this request confirms what was stated before for the previous excerpt.

>01 0C 00 13 07 05 70 04 03 01 00 05 22 B3

<01 04 01 13 01 E8

<01 05 00 13 22 00 CB

53

Besides the Night Light parameter, there are many others that can be config-ured for this particular device. Below is a list of all the ZDM230 multilevel switchparameters:

- Set Ignore Start Level Bit When Transmitting Dim Commands;

- Suspend Group 4;

- Disable Group 4 During a Dim Command;

- Night Light;

- Invert Switch;

- Ignore Start Level When Receiving Dim Commands;

- Do not Send Level Command After Transmitting Dim Commands;

- Adjusting Dim Rate;

- Enable Shade Control Group 2;

- Enable Shade Control Group 3;

- LED Transmission Indication;

- Poll Group 2 Interval (minutes).

The parameter number does not follow the order of the list taken from [18].All configuration parameters will be reset to their default value when the

ZDM230 device is erased from the Z-Wave network, that is, when the networkcontroller is reset to its default configuration.

This is just an example of how configuration parameters can be configured.This should be similar for other devices, with the exception of parameter numbersand values which are device specific.

5.4.7 Dimmer Switch Supported Features

By pressing the button Get Names and Locations in the Z-tool GUI, the ZDM230Dimmer responds and the next message is an excerpt of that communication.>01 04 00 60 07 9C

<01 04 01 60 01 9B

<01 14 00 49 84 07 0E 04 11 01 26 27 85 73 70 86 72 EF 20 26 50 01 F1

When any of the buttons on the multilevel switch is pressed, the messagereceived is the same.

The first underlined byte is the node ID of the device, followed by the size ofthe payload; byte with value 0x0E or 14 in decimal and the next three underlinedbytes are the same received during the Z-Tool initialization routine. The lastgroup of underlined bytes are all part of the list of command classes in [19]. This

54

document provides valuable information about the list of command classes and thebyte values that identify them. So far this information has proved to be reliable.

Below, is a list of command classes that correspond to the bytes underlinedabove:

- 0x26 - Command Class Switch Multilevel

- 0x27 - Command Class Switch All

- 0x85 - Command Class Association

- 0x73 - Command Class Powerlevel

- 0x70 - Command Class Configuration

- 0x86 - Command Class Version

- 0x72 - Command Class Manufacturer Specific

- 0xEF - Command Class Mark

- 0x20 - Command Class Basic

- 0x26 - Command Class Switch Multilevel

- 0x50 - Command Class Basic Window Covering

5.4.8 Manufacturer Information & Device Type

The same document provides information to find more details such as: ZDM230type of device is 0x11, the manufacturer ID (01D), which corresponds to theACT manufacturer, type 44 4D, ID (33 30), and Z-Wave device version (Lib1.99 and App 1.10). Although [19] provides some insight about the meaning ofthese ZDM230 features, most of its meaning is still unknown. For instance, typeof device byte 11H, can be a switch, controller, dimmer, transmitter, thermostat,shutter and other (the type of hardware) or a controller, static controller, slaveor routing slave (the type of device within the network). By cross-referencing theinformation in [19] and [13], a confirmation can be obtained regarding the meaningof each of the command classes. The ID Manufacturer list is also mostly unknownas well as the device type, but through a comparison with additional informationpresent in [19], two lists shown in tables 5.8 and 5.9 below.

Further investigation upon devices of different manufacturers and types wouldbe required to complete these tables.

5.4.9 Node Version Information

One of the command classes supported by all three devices in this study is theVERSION command class, with byte value 0x86. As the name already implies,this command class provides the user with version information regarding a device.

- Product Type ID: 0x444D

55

- Product ID: 0x3330

- Library Type: 0x00

- Protocol Version: 0x01

- Protocol Sub Version: 0x63

- Application Version: 0x01

- Application Sub Version: 0x0A

To request the version information from the device, the request that starts thefollowing message sequence was sent by HomeSeer.>01 07 00 13 07 02 86 11 79

<01 04 01 13 01 E8

<01 0D 00 04 00 07 07 86 12 06 01 63 01 0A 0D

Based on previous successful attempts of interaction with Z-Wave devices, thevalues to request the version information were found to be low, such as 0x02,0x03 or 0x04. The remaining bytes in the frame follow the general Z-Wave frameformat. In contrast, the analysis of this request reveals that the value of GetVersion command byte is 0x11. The version information for ZDM230 can befound in [18].

ID Device Type0x01 CONTROLLER0x10 APPLIANCE0x11 DIMMER0x20 SENSOR0x12 TRANSMITTER0x08 THERMOSTAT0x09 WALL ROLLER SHUTTER

Table 5.8: Device Type List

ID Manufacturer0x01 ACT0x02 DANFOSS0x12 HOUSEKEEPER0x60 EVERSPRING0x59 HORSTMANN0x77 INNOVUS0x7A MERTEN

Table 5.9: Manufacturer ID List

56

By comparing this information with the received response, it is noticeablethat there are common byte values, underlined in the excerpt above, and someparameters that do not have the same value.

- Product Type ID: 0x444D

- Product ID: 0x3330

- Library Type: 0x00

To obtain the Version Information of the Qees Power Switch is similar. Theonly difference is the device’s Node ID in the request.>01 07 00 13 02 02 86 11 7C

<01 04 01 13 01 E8

<01 0D 00 04 00 02 07 86 12 06 02 33 01 0B 5A

In this device, the following software versions are available:

- Protocol Version: 0x02

- Protocol Sub Version: 0x33

- Application Version: 0x01

- Application Sub Version: 0x0B

Comparing this request with the previous one, some similarities are foundbetween the responses. The first underlined bytes, 0x12 and 0x06 are the sameindependently of the device being inquired. At least for byte with value 0x12 justafter command class byte 0x86 it can be assumed that it signals that the messageis a report from the VERSION command class. Consequently, byte with value0x11 in the initial message can be interpreted as a Get command.

57

58

Chapter 6

Graphical User Interface

To control all the Z-Wave devices added to the network using the console, agraphical user interface (GUI) was developed. This GUI represents the iHotelconcept. Since this system is only a concept, the Z-Wave functions here are theones studied in this project. For demonstration purposes, the GUI has a full menuwith other function the concept should feature. Among these functions are:

- VoIP Phone

- Hotel Services

- Distributed Audio Control

- Digital Frame

- Hotel Statistics

The GUI was developed using C++ and designed using the Qt graphic inter-face libraries. The decision to use the Qt libraries was supported by the extensivedocumentation readily available and by the fact that cross-compiling the librariesfor this embedded system is fairly simple and also well documented.

Although the core part of this project is the interactivity with Z-Wave devices,the GUI contains not only the Z-Wave devices menu but also options for all otheriHotel functions. Functions that are not directly related to the device interactionare not active, therefore they cannot be used. Further down, the implementedfunction will be explored.

The GUI is part of a larger system constituted by:

- Graphical User Interface

- Socket2Serial software

- Hardware Interface with the Z-Wave Controller

A diagram showing the connections between the software and hardware of thesystem is shown in figure 6.1 below.

59

Figure 6.1: System Connections Overview

As the picture shows the GUI interfaces with the Socket2Serial software througha socket connection which in turn interfaces with the Z-Wave controller by meanof a UART device driver.

6.1 Main Screen

Although a text based interface could be more than enough, a graphical designwas preferred to give a modern style to the GUI and augment its attractivenessand intuitiveness. Figure 6.2 displays the GUI main screen. Each of the buttonsfeatures a iHotel system function.

The main screen of the application features different types of Qt objects,dialogs, buttons and other items. Each of these objects uses a specific Qt class thatallows the object to have its properties altered through a set of available methodsand even extended by creating new methods to those classes. The base class forthis application is MainWindow and inherits from Qt’s class QMainWindow.

In Figure 3.3 a diagram of how the GUI’s objects classes are related betweenthemselves is shown. This diagram is valid for all of the different screens that

60

feature system functionalities. The exception is that some screens use additionalobjects and therefore also use additional classes, that have as base class QWid-get ; some of these classes are: QAbstractSlider, QDial, QSlider, QProgressBar,QSplashScreen, QLineEdit and QMainWindow.

Figure 6.2: Graphical User Interface Main Screen

6.2 Socket2Serial - Graphical User Interface

As already stated, the Socket2Serial program, described in detail in chapter 7,interacts with the GUI through a network socket. Qt features a library, QTcp-Socket, that enables socket communication of data streams through a TCP socket.The main reason for using this Qt library is the fact that is written in C++ sointegration with the rest of the GUI is easier and cleaner. An alternative is theBSD sockets API written in C, but since the QTcpSocket library is based on it, itwould not make sense to use an old API in C within a C++ application. A classnamed Client is defined to represent the system as a client of the Socket2Serialcomponent, thus making it the system server. To use this class, a pointer to anobject of its type is declared within the MainWindow class. Besides that, usinga Qt library has a big advantage, the Qt Signals and Slots mechanism. This Qtabstraction is used to link GUI controls and/or functions through their behaviourby means of events that are sent and received. For example, when a GUI controlis activated or controlled, a Signal is sent to a Slot that has previously been linkedwith. That slot, in turn executes a specific function.

The GUI acts as a ”client” of the Socket2Serial component, this is shown inFigure 6.3 below.

Hence it has a Client object that, as a result of interfacing with the Z-Wavecontroller and a TCP socket, makes use of two classes: ZWave and QTcpSocket.

61

Figure 6.3: Main Window Classes Relationship

Using the QTcpSocket library, a connection is established every time a messageis sent and/or received by the Z-Wave network. Additionally, a class named ZWavewas created to aggregate all the details regarding the Z-Wave protocol, framebuilding, checksum calculation, functions to send and receive data and other.Both classes are used by the Client class, a pointer to QTcpSocket is declared anda ZWave object is instantiated as seen in Figure 6.4.

Figure 6.4: Client Object Relationship

62

When the GUI initiates, a verification is made to ensure that the Socket2Serialsoftware is ready to communicate. Listing 6.1 below shows the constructor of themain window. In the main window constructor a connection is made to see ifnew data is available using the signal readyRead(), if an error occurs, a connectionis made to enquire regarding the error type. The error is returned through theQAbstractSocket::SocketError variable and displayed in the command line.

Listing 6.1: Main Window Constructor

Cl i ent : : C l i en t (QWidget ∗parent ): QDialog ( parent )

{// Create a socket and con f i gu r e i t .

tcpSocket = new QTcpSocket ( t h i s ) ;

th i s−>ZW IP Adress = ” l o c a l h o s t ” ;th i s−>ZW Port Adress = 12345;

// Def ine when a readSocket ( ) and SocketError ( ) are invoked .connect ( tcpSocket , SIGNAL( readyRead ( ) ) , th i s , SLOT( readSocket ( ) ) ) ;connect ( tcpSocket , SIGNAL( e r r o r ( QAbstractSocket : : SocketError ) ) , th i s ,

SLOT( d i sp l ayEr ro r ( QAbstractSocket : : SocketError ) ) ) ;}

Whenever it is necessary to send a new message to the Socket2Serial compo-nent, a general function is available. For each message the function establishes anew connection with the server and sends a stream of data. Also, a Signal is emit-ted every time the socket has new incoming data and the readSocket() function isinvoked to deal with that data. This function is depicted in listing 6.2.

Listing 6.2: General Function to Send Data

void Cl i ent : : wr i teSocket ( const char message [ ] , i n t mes sage s i z e ){

b lockS i z e = 0 ;tcpSocket−>abort ( ) ;

// Es t ab l i s h e s a socket connect ion to the host and sends the message [ ] data through i t .tcpSocket−>connectToHost ( ZW IP Adress , ZW Port Adress ) ;tcpSocket−>wr i te (message , mes sage s i z e ) ;

}

Function 6.3 below is responsible for a first analysis of the incoming data. Thisconsists of checking if a valid Z-Wave message has been received. At this point avalid message has to meet the following requirements:

- Starts with a 0x01 byte.

- Has the correct size.

- Has a valid checksum.

Listing 6.3 shows how these requirements are met. The incoming data is anal-ysed to look for a byte with value 0x01. If that byte is found, the checksum byteis searched for and compared to a calculation of what it is expected to be. Func-tion network.checksum(message received, size) returns the expected checksum. Ifthe comparison result is positive the message is considered valid and the functionnetwork.decodeMessage(message received, size) is inked to decode it. If the check-sum calculation is not valid the message is considered invalid and according to theZ-Wave protocol specification a NAK, not acknowledge, is sent to the network.

63

Listing 6.3: Client::readSocket() Function

void Cl i ent : : readSocket ( ){

. . .// Ver i fy i f i t i s a va l i d Z−Wave frame .

i f ( ( message rece ived [ 0 ] == ”0x01 ”) ){

i n t checksum resu l t = network . checksum ( message rece ived , s i z e ) ;// Perform a checksum va l i d a t i on o f the incoming frame .

i f ( checksum read == checksum resu l t ){

. . .// Pass the frame data on to be decoded .

network . decodeMessage ( message rece ived , s i z e ) ;}e l s e{

qDebug ( ) << ”CHECKSUM FAILED ! ” ;}

}e l s e{ // I f the data i s not a va l i d Z−Wave frame , r epor t e r r o r .

const char message2 [ 1 ] = {0x18 } ;i n t s i z e mes sage2 = s i z e o f ( message2 ) ;C l i en t : : wr i t eSocket (message2 , s i z e mes sage2 ) ;

}

i f ( tcpSocket−>byte sAva i l ab l e ( ) < b lockS i z e )re turn ;

}

6.3 Z-Wave Devices

6.3.1 Switch

The Qees Power Switch control window enables the user to turn the device eitherON or OFF. Furthermore, the consumption values can be read, see picture 6.2.

Figure 6.5: Switch Graphical User Interface

Decoding a Z-Wave message implies that the program must be prepared toreceive any type of these messages. In this case, there are two major commandclasses that have to be supported: Basic and Meter. For the time being onlythe Meter command class is supported. It was decided not to implement theBasic command class since it added no immediate value because of its simple

64

usage to this study. Other command classes are more interesting and thereforepriority will be given to those. Also, when a request to set a given status is sent,a response with the current status is not sent back, only the confirmation thatthe status has been set, this is a characteristic of the Z-Wave protocol and can beobserved in subsection 5.4.1.2. The only thing that is replied to a Z-Wave messageis an acknowledge, not acknowledge or not available. In fact, the only way to beabsolutely sure about the switch status is to ask the device for its status. Listing6.4 shows the function used to ask the device for its status.

Listing 6.4: Switch On Function

void MainWindow : : on dev ice 01 pushButton On c l i cked ( ){

const char message [ 1 1 ] = {0x01 , 0x09 , 0x00 , 0x13 , 0x02 , 0x03 , 0x20 , 0x01 , 0xFF , 0x01 , 0x3B} ;i n t s i z e = s i z e o f ( message ) ;th i s−>c l i e n t−>wri teSocket (message , s i z e ) ;

}

The Meter command class is responsible for receiving details related to thepower consumption of the load to which the switch is connected to. The detailsto be received are:

- value - power consumption in kWh;

- precision - value precision;

- scale - value scale;

- size - number of bytes of value.

An example of a request and subsequent response is shown in subsection 5.4.3.Listing 6.5 shows the part of the decodeMessage() function responsible for decodingthe response to the consumption values request.

The Command Class Meter section of the ZWave::decodeMessage() functionis responsible for extracting the value of the meter, but not only that. Also,the values of Scale, Mask and Precision are extracted here. These are used tocalculate the value and present it correctly to the user. Details about how theseare interpreted are still not completely known at this point. These details arediscussed in subsection 5.4.3.

Listing 6.5: Meter Command Class Function

. . .

case COMMANDCLASSMETER:// I f i t i s a meter r epor t then ex t ra c t s ca l e , p r e c i s i o n and s i z e data .

i f ( frame [ 8 ] == METERREPORT) {s c a l e = ( ( unsigned char ) frame [ 1 0 ] & METER REPORT SCALE MASK ) >>

METER REPORT SCALE SHIFT;p r e c i s i o n = ( ( unsigned char ) frame [ 1 0 ] & METER REPORT PRECISION MASK ) >>

METER REPORT PRECISION SHIFT;s i z e = ( unsigned char ) frame [ 1 0 ] & METER REPORT SIZE MASK;shor t tmpval ;// Extract the meter r epor t value .

switch ( s i z e ){

case 1 :value = ( s igned char ) frame [ 1 1 ] ;break ;

case 2 :tmpval = ( ( unsigned char ) frame [ 1 1 ] << 8) + ( unsigned char ) frame [ 1 2 ] ;va lue = ( s igned shor t ) tmpval ;break ;

d e f au l t :

65

value = ( ( unsigned char ) frame [ 1 1 ] << 24 ) + ( ( unsigned char ) frame [ 1 2 ]<< 16 ) + ( ( unsigned char ) frame [ 1 3 ] << 8 ) + ( unsigned char ) frame [ 1 4 ] ;

va lue = ( s igned in t ) value ;break ;

}

switch ( frame [ 9 ] ) // Meter Type + Rate Type{

. . .

i f ( s c a l e == 0){

. . .}

. . .

6.3.2 Dimmer

Figure 6.6: Dimmer Graphical User Interface

Using the controls shown in picture 6.6 it is possible to switch the load connectedto the dimmer and to regulate it to a desired power level. As previously done withthe switch, the Z-Wave messages sent to the device to turn it both ON and OFFare hard coded into the GUI component, not using any specific command class.

Listings 6.6 and 6.7 show the functions used to turn the dimmer on and off,respectively. These functions prepare the Z-Wave messages to be sent to theSocket2Serial program and from there to the Z-Wave controller. Before data issent to the Socket2Serial component, its checksum is calculated and a message isbuilt according to the Z-Wave protocol. After this the message is ready to be sentto the Z-Wave controller.

Listing 6.6: Dimmer On Command Class Function

void MainWindow : : on ZDM230 on pushButton clicked ( ){

const char ZDM230 on [ 1 3 ] = {0x01 , 0x0B , 0x00 , 0x14 , 0x01 , 0x04 , 0x03 , 0x20 , 0x01 ,0xFF , 0x05 , 0x0A , 0x37 } ;

i n t ZDM230 on size = s i z e o f (ZDM230 on ) ;th i s−>c l i e n t−>wri teSocket (ZDM230 on , ZDM230 on size ) ;

// Set the value o f the GUI con t r o l s to the same one sent to the dev i ce .ui−>d ia l−>setValue ( 1 00 ) ;ui−>ZDM230 horizontalSl ider−>setValue ( 1 00 ) ;ui−>ZDM230 progressBar−>setValue ( 1 00 ) ;

}

66

Listing 6.7: Dimmer Off Command Class Function

void MainWindow : : on ZDM230 of f pushButton cl icked ( ){

const char ZDM230 off [ 1 3 ] = {0x01 , 0x0B , 0x00 , 0x14 , 0x01 , 0x04 , 0x03 , 0x20 , 0x01 ,0x00 , 0x05 , 0x0B , 0xC9} ;

i n t ZDM230 of f s ize = s i z e o f ( ZDM230 off ) ;th i s−>c l i e n t−>wri teSocket ( ZDM230 off , ZDM230 of f s ize ) ;

// Set the value o f the GUI con t r o l s to the same one sent to the dev i ce .ui−>d ia l−>setValue ( 0 ) ;ui−>ZDM230 horizontalSl ider−>setValue ( 0 ) ;ui−>ZDM230 progressBar−>setValue ( 0 ) ;

}

If the value is changed on the dial then Qt executes the on dial valueChanged()function: the value returned from the dial is converted to a valid number to besent as part of the message and a new checksum value is generated and substitutedin the pre-defined message. The resultant message is then sent to the network andthe dimmer is actuated accordingly. Listing 6.8 shows how this process takes placeand further information about setting a dimmer value can be seen in subsection5.4.2.4.

Listing 6.8: Dimmer Change Value Function

void MainWindow : : on dia l va lueChanged ( i n t value ){ // I f the d i a l i s rotated , the value changes and has to be sent to the dev i ce .

i n t i = 0 ;i n t r e s u l t = 0 ;char ZDM230 dimmer value [ 1 1 ] = {0x01 , 0x09 , 0x00 , 0x13 , 0x04 , 0x03 , 0x20 , 0x01 ,

0x00 , 0x05 , 0xFF} ;

ZDM230 dimmer value [ 8 ] = value ;// Reca l cu la t e the checksum to be incorporated in the frame to be sent .

r e s u l t = 0xFF ˆ ZDM230 dimmer value [ 1 ] ; // f i r s t valuef o r ( i =2; i < 10 ; i++){

r e s u l t ˆ= ZDM230 dimmer value [ i ] ;}// Encapsulate the dimmer value onto the frame .ZDM230 dimmer value [ 1 0 ] = r e s u l t ;

// Send the new frame .i n t ZDM230 dimmer value size = s i z e o f ( ZDM230 dimmer value ) ;th i s−>c l i e n t−>wri teSocket ( ZDM230 dimmer value , ZDM230 dimmer value size ) ;

}

6.3.3 Sensor

Figure 6.7: Sensor Graphical User Interface

67

To display values sent from the 3 in 1 sensor, HSM100, the GUI features a screenshown here in picture 6.7.

The GUI features information about temperature, light level and battery levelupon device request.

These requests are shown below in listings 6.9, 6.10 and 6.11 and are alreadyready to be sent to the Socket2Serial program.

Listing 6.9: Get Temperature Request

void MainWindow : : on HSM100 pushButton GetTemperature clicked ( ){

const char temperature [ 1 4 ] = {0x01 , 0x0C , 0x00 , 0x13 , 0x03 , 0x05 , 0x60 , 0x06 , 0x03 , 0x31 ,0x04 , 0x05 , 0x03 , 0xB0} ;

i n t t empera tu r e s i z e = s i z e o f ( temperature ) ;th i s−>c l i e n t−>wri teSocket ( temperature , t empera tu r e s i z e ) ;

}

Listing 6.10: Get Light Level Request

void MainWindow : : on HSM100 pushButton GetLightLevel c l icked ( ){

const char l i g h t l e v e l [ 1 4 ] = {0x01 , 0x0C , 0x00 , 0x13 , 0x03 , 0x05 , 0x60 , 0x06 , 0x02 , 0x31 ,0x04 , 0x05 , 0x03 , 0xB1} ;

i n t l i g h t l e v e l s i z e = s i z e o f ( l i g h t l e v e l ) ;th i s−>c l i e n t−>wri teSocket ( l i g h t l e v e l , l i g h t l e v e l s i z e ) ;

}

Listing 6.11: Get Battery Level Request

void MainWindow : : on HSM100 pushButton GetBatteryLevel c l icked ( ){

const char b a t t e r y l e v e l [ 1 4 ] = {0x01 , 0x09 , 0x00 , 0x13 , 0x03 , 0x02 , 0x80 , 0x02 , 0x05 ,0x03 , 0x60 } ;

i n t b a t t e r y l e v e l s i z e = s i z e o f ( b a t t e r y l e v e l ) ;th i s−>c l i e n t−>wri teSocket ( b a t t e r y l e v e l , b a t t e r y l e v e l s i z e ) ;

}

For the time being, battery information is not available since it belongs toa different command class, Battery. At this point, only the Sensor Multilevelcommand class was implemented. In subsubsection 5.4.4.4, it is demonstrated howthe battery level readings should be interpreted. Listing 6.12 shows part of thedecodeMessage() function responsible for interpreting luminance and temperaturereports.

Listing 6.12: Sensor Multilevel Command Class Function

case COMMAND CLASS SENSOR MULTILEVEL:// I f a data repor t has been r e c e i v ed from the sensor .i f ( frame [ 8 ] == SENSOR MULTILEVEL REPORT){

// Extract s ca l e , p r e c i s i o n and s i z e data .i n t s c a l e = ( ( unsigned char ) ( unsigned in t ) frame [ 1 0 ] &

SENSOR MULTILEVEL REPORT SCALE MASK ) >> SENSOR MULTILEVEL REPORT SCALE SHIFT;i n t p r e c i s i o n = ( ( unsigned char ) ( unsigned in t ) frame [ 1 0 ] &

SENSOR MULTILEVEL REPORT PRECISION MASK ) >> SENSOR MULTILEVEL REPORT PRECISION SHIFT;i n t s i z e = ( unsigned char ) ( unsigned in t ) frame [ 1 0 ] & SENSOR MULTILEVEL REPORT SIZE MASK;in t value ;shor t tmpval ;

// Extract the value depending on i t s s i z e .switch ( s i z e ){

case 1 :value = ( s igned char ) ( unsigned in t ) frame [ 1 1 ] ;

break ;case 2 :

tmpval = ( ( unsigned char ) ( unsigned in t ) frame [ 1 1 ] << 8) + ( unsigned char ( unsigned in t ) frame [ 1 2 ] ;va lue = ( s igned shor t ) tmpval ;

break ;d e f au l t :

va lue = ( ( unsigned char ) ( unsigned in t ) frame [ 1 1 ] << 24 ) + ( ( unsigned char )( unsigned in t ) frame [ 1 2 ] << 16 ) + ( ( unsigned char ) ( unsigned in t ) frame [ 1 3 ] << 8 ) +

( unsigned char ) ( unsigned in t ) frame [ 1 4 ] ;

68

value = ( s igned in t ) value ;break ;

}

i f ( p r e c i s i o n > 0) { value = value / pow(10 , p r e c i s i o n ) ; }// Pr int the va lues accord ing to t h e i r nature .

switch ( ( unsigned in t ) frame [ 9 ] ){case SENSOR MULTILEVEL REPORT LUMINANCE:

i f ( s c a l e == 0) {qDebug (”Luminance measurement r e c e i v ed : %d” , value ) ;

} e l s e {qDebug (”Luminance measurement r e c e i v ed : %d Lux” , value ) ;

}break ;

case SENSOR MULTILEVEL REPORT TEMPERATURE:i f ( s c a l e == 0) {

qDebug (” Temperature l e v e l measurement r e c e i v ed : %d C” , value ) ;} e l s e {

qDebug (” Temperature l e v e l measurement r e c e i v ed : %d F” , value ) ;qDebug ( ) << ”Convert to Farenhe i t ! ” ;

}break ;

d e f au l t : // ExceptionqDebug (” Sensor type 0x%x not handled ” , ( unsigned char ) ( unsigned in t ) frame [ 9 ] ) ;break ;

}

6.4 Configurations

Figure 6.8: Configurations Graphical User Interface

As described previously the GUI connects with the Socket2Serial componentthrough a socket connection, and in order to do so, it needs an address and anavailable port. These two parameters are configured at this configurations screen.Furthermore, the system provides a place to configure another socket connection,but with the main hotel server. For both connections, it is necessary to configurethe IP address and the port. In this project, when the Socket2Serial component isinitiated, two parameters are passed onto it: IP and port. These two parametersare defined by the developer and are fixed and must also be configured in the GUIconfiguration screen so that the GUI can connect with the Socket2Serial.

Further development would be necessary regarding the hotel server configura-tions, since these are meant to be used when a hotel features a network of iHotel

69

systems connected to a central server. At this point, an option to configure thesystem time is provided for debug purposes.

70

Chapter 7

Socket2Serial Interface Software

This software is essentially a message router, from the TCP socket to the serialport, where the Aeon Labs USB Z-Stick is connected. The interface between theZ-Wave network and the embedded system or a standard personal computer isestablished by means of a USB device. By examining this device, the Z-Wavenetwork controller, up close it was possible to determine that it consists of nomore than a Z-Wave radio transceiver embedded in a microcontroller connectedthrough a standard UART to USB signal converter named Silicon Labs CP2102.The microcontroller is already pre-programmed with the Z-Wave Application Pro-gramming Interface (API) application software. This API interprets commandsand the application software acts upon the network and/or its devices accordinglyand manages all the network activity.

This software, designated Socket2Serial handles the communication betweenthe user interface and the Z-Wave Controller device: it receives commands througha TCP socket connection and sends them to the Z-Wave device to be interpretedby the Z-Wave API, and receive commands from the Z-Wave device, sending themthrough the same TCP socket connection.

To better illustrate the data flow, it is represented below in picture 7.1. TheSocket2Serial component talks with the Z-Wave controller through a serial portconnection. Since data can be received or sent at any time it is necessary to handlethat data whenever necessary. For that reason, when designing a program, severalI/O techniques can be applied such as asynchronous I/O data receiving, blockingor non-blocking program flow according to the desired purpose.

Figure 7.1: Flow of data through Socket2Serial

71

7.1 Unix Signals

Handling asynchronous events such as incoming data from devices or processescan be done using a Unix resource named Unix Signals. The operating systemresponds to several different signals in different ways and for a range of differentevents. Signals come from Kernel space and can be initiated by processes or theKernel itself.

For this specific purpose the Socket2Serial should be notified that data hasarrived either on the serial port or on the specific socket connection active atthe time. Furthermore, to allow the user to have some control upon the softwareseveral other signals were registered. The list of signals registered for this softwarewere:

- SIGIO;

- SIGTERM;

- SIGINT;

- SIGHUP.

The SIGIO/SIGPOLL is a signal sent to a process when an asynchronousInput/Output event occurs. This might be the data coming through the serialport or the network socket. SIGTERM is useful to allow a process to be killed bythe user or other process, this signal can be blocked, handled and ignored. It isconsidered a polite way to terminate processes. During the development processit was useful to kill the process abruptly by using the ”Ctrl-C” key combinationfor that reason the SIGINT signal was registered. Finally, the SIGHUP signal wasalso registered since it allows to detect that a terminal connection, typically anRS-232 terminal, was lost or hangup.

To configure the way the iHotel should behave when receiving data and/orsignals each signal must be configured in a specific structure, the sigaction struc-ture (defined in the C header file sys/signal.h), the sigaction structure. In listing7.1 it can be seen how this is done by the configuration routine which is invokedwhen the program starts.

Listing 7.1: Configuration of the signals for Socket2Serial

void configure SIGNAL ( s t r u c t s i g a c t i o n s a i o ){/∗ i n s t a l l the s i g n a l handler be f o r e making the dev i ce asynchronous ∗/

sa i o . sa hand l e r = s i gna l h and l e r ;

/∗ i n i t i a l i z e the s t r u c t member ∗/s igemptyset (& sa i o . sa mask ) ;s a i o . s a f l a g s = 0 ;s a i o . s a r e s t o r e r = NULL;

/∗ when s i g n a l dr iven I /O i s enabled f o r a socket ∗/s i g a c t i o n (SIGIO , &sa io , NULL) ;/∗ CTRL−C ∗/s i g n a l (SIGINT , s i g na l h and l e r ) ;/∗ PROCESS TERMINATED ∗/s i g n a l (SIGTERM, s i gna l h and l e r ) ;

/∗ DISCONNECTED TERMINAL ∗/s i g n a l (SIGHUP, s i g na l h and l e r ) ;

p r i n t f (”\n∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗\n ” ) ;p r i n t f (”SIGNALS con f i gured !\n ” ) ;

}

72

The sigaction() function allows the process to examine or change the action tobe taken when, in this case, a SIGIO signal is issued. The second parameter, saio,points to a structure that describes the action to be taken on receipt of the signal,in this case, a function acknowledging that a signal has been received and thatterminates the application correctly. The function configure signal() also showsthe setup of the handler for each of the other signals that are able to interrupt theprogram, respectively SIGINT, SIGTERM and SIGHUP, by the signal() function.

7.2 Serial Port Input/Output

To perform terminal I/O functions, such as interfacing with a serial port, anapplication programming interface called termios was used. This UNIX API allowsthe programmer to interface not only with a serial port but with any kind ofterminal.

To develop a software program using this API, the program shall behave ac-cording to the following sequence of actions showed in picture 7.2:

Figure 7.2: Socket2Serial Diagram of Operation

73

For this particular application there is a set of pre-requisites that have to befollowed by the program:

- Receive a line of characters or a set of characters.

- Write and read data.

- Not block if the device is unable to be opened.

7.2.1 Opening a Serial Device

To open a serial device respecting the requirements specified above, one has toselect options, such as: the path to the device, a set of flags that control theopening method, access permissions, etc. The path to the device (/dev/ttyUSB0)is mandatory, and it is stored in MODEMDEVICE. The control flags used are:

- O RDWR opens the port for reading and writing;

- O NOCTTY to prevent the terminal device from controlling the application(and, for example, kill it if a CTRL+C is received;

- O NONBLOCK to prevent the opening process from blocking.

The process of opening the serial device is done as it can be observed in listing7.2. The function open UART() will return a value that indicates if the openingprocess was successful or not.

Listing 7.2: Open UART function

i n t open UART(){/∗ open the dev i ce to be non−b lock ing ( read w i l l r e turn immediately ) ∗/

in t c on f i g = open (MODEMDEVICE, ORDWR | O NOCTTY | ONONBLOCK) ;

i f ( c on f i g < 0){

per ro r (MODEMDEVICE) ;e x i t (−1);

}p r i n t f (”UART open !\n ” ) ;re turn con f i g ;

}

7.2.2 Configuring the Serial Device

The configuration of the serial device is done using a data structure named struct

termios shown in listing 7.3. This data structure is defined in the <termios.h>

header file and contains five fields that have to be filled to configure the deviceaccordingly to what is desired.

Listing 7.3: Struct termios

{s t r u c t termios {

t c f l a g t c i f l a g ; /∗ input modes ∗/t c f l a g t c o f l a g ; /∗ output modes ∗/t c f l a g t c c f l a g ; /∗ con t r o l modes ∗/t c f l a g t c l f l a g ; /∗ l o c a l modes ∗/c c t c c c [NCCS ] ; /∗ con t r o l chars ∗/

} ;}

74

One of the important decisions to make is how data is meant to be received.The possible modes of operation are:

- Canonical mode to provide data line-by-line, useful to deal with real termi-nals.

- Non-canonical mode to receive individual characters.

- Raw mode to prevent the input from being received line-by-line and to disablethe processing of special characters (e.g., delete).

The configuration of the serial port will be the same as the one defined by themanufacturer for the Aeon Labs Z-Wave Stick, 115200bps, 8 data bits, no paritybits and 1 stop bit. Furthermore, the graphical user interface returns individualcharacters and it does not process special characters hence the Non-Canonicalmode is used. Listing 7.4 displays the configure UART function that is responsiblefor configuring every option related to the serial port.

Listing 7.4: Configure UART function

void configure UART ( in t fd UART , s t r u c t termios o ld t i o , s t r u c t termios newtio ){

/∗ save cur rent port s e t t i n g s ∗/t c g e t a t t r ( fd UART ,& o l d t i o ) ;

/∗ speed , 8 data b i t s , . . . ∗/newtio . c c f l a g = BAUDRATE | CS8 | CLOCAL | CREAD;

/∗ NO PARITY BITS ∗/newtio . c c f l a g &= ˜PARENB;

/∗ RAW input ∗/newtio . c i f l a g = IGNPAR | INLCR;

/∗ Raw output ∗/newtio . c o f l a g = 0 ;

/∗ d i s ab l e canon i ca l input ∗/newtio . c l f l a g = (˜ICANON) ;

/∗ number o f bytes to r e c e i v e be f o r e the s i g n a l i s a c t i va t ed ∗/newtio . c c c [VMIN] = 1 ;

// newtio . c c c [VTIME] = 0 ;

t c f l u s h (fd UART , TCIFLUSH) ;

/∗ APPLY SETTINGS ∗/t c s e t a t t r ( fd UART , TCSANOW,&newtio ) ;p r i n t f (”UART con f i gured !\n ” ) ;

}

7.2.3 Writing to and Reading from the Serial Interface

To read from and write to the device the system calls read() and write() are used,as shown in listing 7.5. Each of the used the file descriptor obtained by open(),specifies the buffer where the data is located or is to be stored and the size of thatsame buffer.

Listing 7.5: Reading and Writing data to the Serial Device

/∗ \ t e x t i t {Read from the S e r i a l Device} ∗/. . .

char number 01 = read (fd UART , Socke t bu f f e r , s i z e S o c k e t b u f f e r ) ;. . .

/∗ \ t e x t i t {Write to the S e r i a l Device} ∗/. . .

char number = wr i te ( fd UART , message , mes sage s i z e ) ;. . .

75

7.2.4 Close Serial Interface

The final step taken when interacting with the serial port in closing it using thestandard Unix close() system call. Besides closing the device, the UART is alsoflushed, i.e., every remaining data on the buffer is actually written. Listing 7.6shows how this is done.

Listing 7.6: Flush UART function

void flush UART( in t fd UART , s t r u c t termios o l d t i o ){

t c f l u s h (fd UART , TCSAFLUSH) ;t c s e t a t t r ( fd UART , TCSANOW, &o l d t i o ) ;p r i n t f (”UART FLUSHED!\n ” ) ;c l o s e ( fd UART ) ;

}

7.3 Network Sockets

The graphical user interface connects with the Socket2Serial server by means ofsocket connections. The data that is received from the serial port is reroutedthrough a socket connection to the GUI. That network socket allows the GUI toreceive and send information to the Z-Wave controller.

The basic behaviour of a socket server and respective client software is illus-trated in figure 7.3.

This structure is replicated in the Socket2Serial software and the graphicaluser interface (GUI).

The implementation of a network socket implies the use of the functions listedbelow.

- socket(), creates a socket connection.

- bind(), associates the socket to the specific port present in the socket addressstructure.

- listen(), puts the socket in listening mode.

- connect(), requests a connection to an existing socket.

- accept(), accepts an received incoming connection.

- send(), recv(), write() or read(), sends and/or receive data.

- close(), terminates the connection.

7.3.1 Establishing a Socket Connection - Server Side

7.3.1.1 Creating a Server

First the server creates a socket connection, it fills all the fields in the sockaddr instructure with the necessary data to specify either a local or remote endpoint towhich to connect a socket as: the address family, the IP port and the IP address.

76

Structure sockaddr in is a data structure containing an internet address that isused to specify either a local or remote endpoint where to connect a given socket.This structure has the definition given in listing 7.7:

Figure 7.3: Server and Client Socket Flow Diagram

Listing 7.7: sockaddr in Data Structure

s t r u c t sockaddr in{

shor t s i n f am i l y ; /∗ must be AF INET ∗/u shor t s i n p o r t ;s t r u c t in addr s in addr ;char s i n z e r o [ 8 ] ;

} ;

7.3.1.2 Configuring a Socket

The socket configuration is done by the function configure SOCKET() in listing7.8. The setsockopt() function is used to set the options associated with a socket,

77

in this case, the options are the following:

- SOL SOCKET is the specified protocol level for which the options are beingset. Other levels, such as TCP, can be used by indicating the respectiveprotocol number, which can be found using the getprotobyname() function.

- SO REUSEADDR defines whether local addresses are able to be reused.This is useful during the development process to avoid ”Address already inuse.” messages when the server restarts after a crash. Typically, when anabnormal termination of the server or client happens, the connection entersin a state called TIME WAIT which is the state that ties up the port for severalminutes after the process has completed. To avoid this, the SO REUSEADDR

options is used to explicitly allow a process to bind to a port which remainsin the TIME WAIT state.

Listing 7.8: Configure Socket function

i n t configure SOCKET ( in t fd SOCKET){

. . .e r r o r f l a g = se t sockopt (fd SOCKET , SOL SOCKET, SO REUSEADDR, ( char ∗)& f l ag ,s i z e o f ( f l a g ) ) ;

. . .

e r r o r f l a g = i o c t l (fd SOCKET , FIONBIO, ( char ∗)& f l a g ) ;

. . .}

The other important option to set is FIONBIO. The ioctl system call is usedto control the operating characteristics of a socket and therefore to set this optionon. Turning it on allows the socket not to block whether it is for input or outputdata.

By default, TCP sockets are blocking, that is, when a connect() call is madeit blocks until a response is issued or an error occurs. This would be impracticalsince the desired behaviour of the program is that it never hangs at any connection.It simply puts one connection on hold, attends a new one, and later returns tocomplete the first. For this reason, a non-blocking socket is used. Even if theconnection would return no data, the socket would not block.

7.3.1.3 Bind Socket

The bind process associates the socket identified by the socket descriptor pre-viously obtained by socket() with a local address. Before that, the sockaddr instructure previously declared has to be filled with all the details regarding thesocket connection. Listing 7.9 shows the complete process.

Listing 7.9: Bind Socket function

void bind SOCKET( in t fd SOCKET , in t s e rve r po r t , s t r u c t sockaddr in addr ){

. . .

addr . s i n f am i l y = AF INET ;addr . s in addr . s addr = htonl (INADDR ANY) ;addr . s i n p o r t = htons ( s e r v e r p o r t ) ;e r r o r f l a g = bind (fd SOCKET , ( s t r u c t sockaddr ∗)&addr , s i z e o f ( addr ) ) ;

78

. . .

p r i n t f (” Socket binded !\n ” ) ;}

7.3.1.4 Accept Connection

Whenever an application is listening for connections and is notified of a new one,in this case by using the select() function, it starts the connection by calling theaccept() method, hence a new socket is created for each connection. The accept()method returns the new socket descriptor for the accepted connection.

7.3.1.5 Sending and Receiving Data

While receiving data is done asynchronously using the select() mechanism, sendingdata can be done at any time during the program’s flow of execution simply be-cause the send() function can be invoked at any time. the function send MESSAGE(),in listing 7.10, is responsible for sending data through a network socket. Basicallyit uses the send() system call for that purpose.

Listing 7.10: Send Message function

i n t send MESSAGE( unsigned char message [ ] , i n t s i z e , i n t c lo se conn , i n t socket number ){

. . .

e r r o r f l a g = send ( socket number , message , s i z e , 0 ) ;

. . .}

7.3.1.6 Closing a Socket Connection

Finally, to close a socket connection, which its file descriptor is registered in theselect() structure, detailed in section 7.5, all that is necessary to do is, makingsure it is in fact registered and after that just invoke the close() system call onit. Listing 7.13 shows how this takes place.

Listing 7.11: Closing Socket Connection function

void cleanup SOCKET( in t max sd , f d s e t mas te r s e t ){

i n t i t e r a t o r 0 0 1 = 0 ;

f o r ( i t e r a t o r 0 0 1 = 0 ; i t e r a t o r 0 0 1 <= max sd ; ++i t e r a t o r 0 0 1 ){

i f (FD ISSET( i t e r a t o r 0 01 , &maste r s e t ) )c l o s e ( i t e r a t o r 0 0 1 ) ;

}}

7.3.2 Establishing a Socket Connection - Client Side

On the client side, GUI, a socket connection is established with the Socket2Serialsystem component as shown previously in 6.2.

The GUI, developed in Qt, makes use of the QtNetwork module which makesuse of QTcpSocket class to establish TCP reliable connections to transfer streamsof data.

79

The client application is always running in the foreground and with the serveralso running in the background a connection between both is maintained. Theconnection is never closed as a result of the client. In fact, the client is neverclosed. The objective of the system is to be on all the time, so the possibilityof shutting down the whole system was not part of the design, the system wouldsimply restart as soon as it was turned on. On a formal point of view, thispossibility should be considered but since it was not absolutely necessary, theoption was made to leave it out.

7.4 Data Exchange

Functions read Buffer() in listing 7.12 and process socket() in listing 7.13 receiveand process respectively incoming data from the serial port and the network socket.

Listing 7.12: Read Buffer function

void read BUFFER( unsigned char So ck e t bu f f e r [ ] , i n t s i z e S o c k e t bu f f e r , i n t socket number ,i n t fd UART){

. . .

char number 01 = read (fd UART , Socke t bu f f e r , s i z e S o c k e t b u f f e r ) ;

. . .

i f ( c l i e n t c onne c t ed == 1){

char number 02 = send ( socket number , Socke t bu f f e r ,s i z e S o c k e t bu f f e r , 0 ) ;

}e l s e

p r i n t f (”NO CLIENT CONNECTED!\n ” ) ;

. . .}

Listing 7.13: Process Socket function

void p r o c e s s s o ck e t ( i n t fd UART , in t c lo se conn , i n t socket number , unsigned char bu f f e r [ ] ,i n t s i z e b u f f e r ){

. . .

chars received SOCKET = recv ( socket number , bu f f e r , s i z e b u f f e r , 0 ) ;

. . .

chars written UART = wr i te ( fd UART , bu f f e r , chars received SOCKET ) ;

. . .}

7.5 Select() Application Programming Interface

The select() API is used to monitor the input or output of data through a set offile descriptors. This allows multiplexing of several I/O channels or file descrip-tors. This API can be configured to monitor the following events: read, writeand exception. The select() function is sleeping and awakes when one of thoseevents takes place in one or several of the file descriptors monitored, if previouslyconfigured for that purpose. The file descriptor sets are specified as fd set ob-jects. When a file descriptor is activated, a bit is set on the file descriptor set.

80

This is actually a bit array. To manipulate a file descriptor set, four functions areavailable:

- FD CLR() clears the bit for the file descriptor fd in the file descriptor set,fd set.

- FD ISSET() returns a non-zero value if the bit for the file descriptor fd is setin the file descriptor set pointed to by fd set, and 0 otherwise.

- FD SET() sets the bit for the file descriptor fd in the file descriptor set, fd set.

- FD ZERO() initializes the file descriptor set fd set to have zero bits for all filedescriptors.

7.5.1 Communication Management

In Socket2Serial, the function FD ISSET is used to monitor any change in bothserial port and network socket file descriptors. Once one of these file descriptorschanges the data is received and immediately sent through the other one. Thatis, if received trough the serial port, is sent through the socket connection or ifreceived from a socket connection is sent through the serial port. This behaviourcan be observed in listing 7.14 by respectively calling functions read Buffer() andprocess Socket() described in section 7.4.

Listing 7.14: Wait Connections function

. . .do{

. . .

i f (FD ISSET(fd UART , work ing se t ) ){

read BUFFER( Socke t bu f f e r , s i z e S o c k e t bu f f e r , socket number , fd UART ) ;print BUFFER( Sock e t bu f f e r ) ;

}i f (FD ISSET(fd SOCKET , work ing se t ) ){

socket number = accept (fd SOCKET , NULL, NULL) ;

. . .

p r o c e s s s o ck e t ( fd UART , c lo se conn , socket number , bu f f e r , s i z e b u f f e r ) ;}

}whi le ( 1 ) ;. . .

7.5.2 Registering the Socket File Descriptor

The function initialize FDSET() in listing 7.15 is used to manipulate an fd setstructure to register each one of the file descriptors (FD) to be used. Along withthe serial port FD fd SOCKET, the fd set structure was also used to registerthe socket FD fd UART. Registering implies setting a bit to 1 in the declaredstructure. That is accomplished with the FD SET() function.

Listing 7.15: Initialize FDSET Socket function

i n t in i t i a l i z e FDSET ( in t fd UART , in t fd SOCKET , f d s e t mas te r s e t ){

81

. . .

FD ZERO(&maste r s e t ) ;max sd = fd SOCKET + fd UART + 1 ; /∗ Number o f d e s c r i p t o r s ∗/FD SET(fd SOCKET , &maste r s e t ) ; /∗ s e t t e s t i n g f o r so cke t s ∗/FD SET(fd UART , &maste r s e t ) ; /∗ s e t t e s t i n g f o r s e r i a l port ∗/

. . .}

7.6 Running the Application

The Socket2Serial component is started by the following command:$ socket2serial [-p netport] device

To start the software a few things have to be specified. In which port theservice is meant to be running, that is parameter netport. The device to use isspecified in the device parameter. This is where the Aeon Labs USB Z-Stick isconnected, for example: /dev/ttyUSB0.

Once Socket2Serial is running, it is possible for any other program or webservice to use the a socket connection to send and receive commands to the Z-Wave network. This enables a whole new range of possibilities, like a server beingable to remotely control a Z-Wave network.

82

Chapter 8

Conclusion

8.1 Future Work

Besides all that has been done to unravel the Z-Wave protocol and build a conceptaround it, much could be added and/or improved in the iHotel. Either softwareor hardware modifications would be able to improve the iHotel in several ways.

8.1.1 Processing Power

Although no quantitative study has been conducted regarding the platform’s per-formance in terms of video playback (which at the time is not available), loadspeed of the application, boot time, speed of change between menus and severalother, some delays and lags are noticeable to the user. These lags or delays thatmay influence user interaction with the system can easily be overcome by usinga more powerful platform, with a faster and more capable processor, more RAMmemory or even a dedicated graphics processor.

8.1.2 Complete Z-Wave Application Programming Inter-face

The Z-Wave protocol details discovered throughout this project are far from beingcomplete. A complete application programming interface to the Z-Wave protocolwould enable the iHotel system to interact with every Z-Wave compatible deviceindependently of its vendor. This would take a large amount of time and moneyto try many other devices, or only a lot of money to buy the protocol license.

8.1.3 Larger Display

Depending on the specific final use of the system, a different LCD size or touchscreen technology could be used. Modifications to the Linux kernel are needed inorder to use a bigger or smaller display. Considerations regarding the processorpower have to be made if a higher resolution and color depth display is to be usedsince considerably more processing power is required to drive such LCD.

83

8.1.4 iHotel Web Control

A powerful advantage to any home control system is to be able to control itremotely. Either by the hotel room client or by the hotel staff, remote controlover the system enables a great deal of comfort and liberty as well as resourcemanagement for increased functionalities and costs reduction.

8.2 Conclusions

The iHotel concept demonstrates how a home automation protocol that is notopen can be studied thoroughly and used to support an idea.

As a conclusion, it can be said that the protocol had its basic features explored.Reading the status of switches, actuating upon them, read sensor values andgather basic network information were the basic topics explored during this work.Although some features were revealed, many other remain to be explored andtested. The graphical interface developed is basic and relies mostly on hard-codedZ-Wave frames to operate. This allowed flexibility and less time consumed withdetails that added no relevant information regarding the protocol, which is theobject of study depicted here.

Taking into consideration the information obtained during the investigationprocess of this work, it can be said that the protocol is much more extensivethan this work can possibly demonstrate. One of the limitation for this work wasprecisely the limited access to Z-Wave devices. Having access to different typesof devices, from different brands and launched into the market at different timeswould allow for more information to analyse and a better comparison term thatsurely would enable more results.

The objectives of this work were achieved since basic control of a Z-Wavenetwork and its devices was obtained.

84

Bibliography

[1] Cristensen, Carlos Mlia; Patent Number: 6,980,080; RF Home Automationsystem With Replicable Controllers, 27 of December of 2005. 3, 28, 32, 34, 35

[2] Franck, Jargen; INS10244 - Instruction: Z-Wave Node Type Overview andNetwork Installation Guide 23

[3] Johansen, Niels Tybo; Patent Number: 7,680,041; Application Number:11/684,430; Node Repair in a Mesh Network, 16 of March of 2010. 24, 26,28

[4] T. Galeev, Mikhail; Catch the Z-Wave, October of 2006. 25, 26, 27

[5] Johansen, Niels Tybo; SDS10243 - Software Design Specification: Z-WaveProtocol Overview 26

[6] Johansen, Niels Tybo; ZM3102 Z-Wave Module Datasheet 28

[7] Qees ApS; Qees Power - Model 0300002 Datasheet 31

[8] Jorgensen, Thomas; T. Johansen, Niels; Z-Wave as Home Control RF Platform33

[9] Shorty, Peter; Patent Number: 6,879,806; Application Number: 09/870,497;System and a Method for Building Routing Tables and for Routing Signals inan Automation System, 12 of April of 2005. 33, 35

[10] Website: http: // en. wikipedia. org/ wiki/ List_ of_ checksum_

algorithms , List of Checksum Algorithms 35

[11] Website: http: // wiki. micasaverde. com/ index. php/ ZWave_ Dongle

37

[12] Datasheet: http: // downloads. ezhome. nl/ en/ EVR/ EVR_ AN1582_ in_

en. pdf , AN158 Wall Switch 42, 43, 44

[13] Website: http: // wiki. micasaverde. com/ index. php/ ZWave_

Command_ Classes 42, 50, 55

[14] Datasheet: http: // us. bosscom. com/ files/ pdf/ BossDim-RS. pdf ,BossDimm RS - Technical Document 44

85

[15] Openzwave Project Website: code. google. com/ p/ open-zwave/ 44

[16] HomeSeer Website: http: // www. homeseer. com/ wiki/ index. php/

HomeSeer_ HSM100 50

[17] Datasheet: ACT ZDM230 Z-Wave Controlled Dimmer Receiver, Dual Switch.Act Solutions, 2007. 53

[18] Website: http: // www. pepper1. net/ zwavedb/ device/ 4 53, 54, 56

[19] Website: http: // www. smarthus. info/ support/ download/ zwave/

Z-WaveConfigurationInformation. pdf 54, 55

86