國
立
交
通
大
學
資訊科學與工程研究所
碩
士
論
文
基於訊息導向中介軟體之異質環境家庭自動化
平台
A MOM-based Home Automation Platform in Heterogeneous
Environments
研 究 生：陳俊元
指導教授：袁賢銘 教授
基於訊息導向中介軟體之異質環境家庭自動化平台
A MOM-based Home Automation Platform in Heterogeneous
Environments
研 究 生：陳俊元 Student：Chun-Yuan Chen
指導教授：袁賢銘 Advisor：Shyan-Ming Yuan
國 立 交 通 大 學
資 訊 科 學 與 工 程 研 究 所
碩 士 論 文
A ThesisSubmitted to Institute of Computer Science and Engineering College of Computer Science
National Chiao Tung University in partial Fulfillment of the Requirements
for the Degree of Master
in
Computer Science June 2006
Hsinchu, Taiwan, Republic of China
基於訊息導向中介軟體之異質環境家庭自動化平台
研究生：陳俊元 指導教授：袁賢銘 國立交通大學資訊科學與工程研究所 摘要 近年來已有多種之可支援家電控制之家庭網路技術，如 X10、UPnP、HAVi 等； 但採用不同家庭網路技術的家電無法互通，也無法組成進一步合作構成家庭自動 化系統。目前已出現許多異質家庭網路互通性之研究；但有關異質環境之家庭自 動化研究依然十分匱乏。本研究提出一家庭自動化平台；使支援不同家庭網路技 術之家電得以可動態合組家庭自動化系統。異質環境下之家庭自動化系統須面對 家電規範彼此不相容、難以支援事件驅動類型之自動化動作、可靠性、延展性、 擴充性與重新組態之問題。本平台底層遵循開放服務閘道器規範 (Open Service Gateway Initiative)，以訊息導向中介軟體作為核心整合所有家電網路。本平台以 根據家庭自動化規則進行之訊息路由為方法，完成可動態組態之事件驅動類型家 庭自動化；家電可動態加入或退出平台而不影響正在其他進行之自動化動作。本 平台以持續性之訊息與訊息訂閱達到高可靠性，透過一對多之訊息模式與跨越子 網路之訊息提供高延展性。平台本身由彼此獨立之服務合作組成，所有服務之軟 體元件均可根據彼此之相依關係透過網際網路動態安裝、啟動，具備高擴充性。 本平台並以基於可延伸標記語言(XML)之描述子抽象化家電服務，增加系統之彈 性，減少軟體之更新需求。家庭自動化可透過本平台延展至網際網路，與網際網 路服務結合，便利生活。A MOM-based Home Automation Platform in Heterogeneous
Environments
Student：Chun-Yuan Chen Advisor：Shyan-Ming Yuan
Department of Computer Science National Chiao Tung University
Abstract
While there have been many home networking technologies such as INSTEON, UPnP and HAVi, appliances supporting different home networking technologies cannot collaborate to finish Home Automation (HA). Recently, many studies of interoperability among heterogeneous home networking technologies have been done, but researches on further Home Automation in heterogeneous environments are still critically lacking. This paper proposes the MOM-based Home Automation Platform (MHAP), which accomplishes event-driven Home Automation in incompatible home networks. MHAP is independent of any home networking technology and integrates home networking technologies in home gateway. For users, MHAP provides the easy-to-use and standardized way to configure complex Home Automation scenarios by rules. Through introducing Message Oriented Middleware (MOM) and Open Service Gateway Initiative (OSGi), MHAP offers reliable automatic operations, fault tolerant and reconfigurable Home Automation, high extensibility and large scalability. The large scalable collaboration in MHAP is among appliances, other MHAP gateways and Internet services such as Web Services.
Acknowledgements
The author is indebted to Dr. Shyan-Ming Yuan, his advisor, Mr. Chi-Huang Chiu, Mr. Ming-Chun Cheng, Mr. Ruey-Shyang Wu and Mr. Tsun-Yu Hsiao, the candidates for Ph.D. of the Department of Computer Science, National Chiao-Tung University, Dr. Ping-Jer Yeh of Computer Science, National Chiao-Tung University, and Miss Hui-Wen Lin of MediaTek Inc, for their assistance and helpful comments in this research. The author especially thanks to Mr. Ming-Chun Cheng for his thoughtful reviews of the earlier drafts of the manuscript.
Table of Contents
摘要... iii
Acknowledgements ...v
Table of Contents ...vi
List of Figures...x
List of Tables... xiii
Chapter 1 Introduction...1
1.1 Motivation...2
1.2 Objective and System Goals ...2
1.2.1 Event-driven Home Automation ...6
1.2.2 Protocol and Platform Independence...6
1.2.3 Reliability and Fault Tolerance ...6
1.2.4 High Scalability...7
1.2.5 Extensibility...7
1.2.6 Easy to Use...8
1.3 Problems ...8
1.3.1 Low Interoperability of Home Networking Technologies ...8
1.3.2 Hard to Support Event-driven Model ...9
1.3.3 Reliability ...9
1.3.4 Scalability and Extensibility ...9
1.3.5 Deployment and Management...10
1.4 MHAP Solution...10
1.4.1 Message Oriented Middleware (MOM)... 11
1.4.2 Standard Deployment and Service Management Infrastructure...12
1.4.3 Rule Based Home Automation...12
Chapter 2 Background and Related Work ...14
2.1 Home Automation...14
2.2 Home Networking Technologies ...14
2.2.2 INSTEON...15
2.2.3 Universal Plug and Play (UPnP) ...16
2.2.4 Home Audio/Video Interoperability (HAVi)...16
2.2.5 Jini...17
2.3 Home Gateway...18
2.3.1 Home Gateway Device ...18
2.3.2 Middleware of Home Gateway ...18
2.3.3 Open Service Gateway Initiative ...19
2.4 Message Oriented Middleware ...21
2.4.1 Publish/Subscribe Model...21
2.4.2 Benefit of MOM ...22
2.4.3 Persistent Message ...22
2.4.4 Durable Subscription ...22
2.5 Related Work...24
2.5.1 Interoperability of Home Networks ...24
2.5.2 Application in Heterogeneous Environment...25
Chapter 3 System Architecture ...26
3.1 Layered Architecture...26
3.1.1 Physical Device and Network...26
3.1.2 Service Infrastructure ...26 3.1.3 MHAP Service ...27 3.1.4 Application ...27 3.2 MHAP Messaging...27 3.2.1 Command Message...29 3.2.2 Query Message ...30 3.2.3 State Message ...30 3.2.4 Event Message...31
3.2.5 Routing and Topic Naming ...31
3.3 MOM Service...33
3.4 Rule Engine...33
3.5 Adaptor ...34
3.5.1 Publishing/Subscribing MHAP Message...34
3.5.2 Bridging MHAP and Native Messages ...35
3.7 Device Management Service ...36
Chapter 4 MHAP Descriptors...37
4.1 MHAP Descriptors Overview ...37
4.1.1 High-level Abstraction...37
4.1.2 Flexibility ...37
4.1.3 Based on XML ...38
4.2 Device Descriptor ...38
4.2.1 Root of Descriptors ...38
4.2.2 Device and Service Type Classification...38
4.3 Service Descriptor...40
4.3.1 Actions, Services and Events ...40
4.3.2 Values of Sate Variables...41
4.4 Protocol mapping descriptor ...41
4.4.1 Flexible Mapping ...41
4.4.2 Association with Service Descriptors ...42
Chapter 5 Implementation ...44
5.1 Target Environment...44
5.1.1 Hardware Environment for MHAP...44
5.1.2 Software Environment for MHAP...44
5.1.3 Environment for End-User Application...45
5.2 MHAP Implementation...45
5.2.1 Life Cycle Control of MHAP Services ...45
5.2.2 Indicating Dependency between Services...50
5.2.3 Publishing/Subscribing Topic...50
5.2.4 Reliable Message...51
5.3 End-user Application Implementation ...52
5.3.1 Universal Remote Controller...53
5.3.2 Remote Rule Configuration tool...53
Chapter 6 Application Demonstration ...55
6.1 Demonstration Environment ...55
6.1.1 MHAP Gateway...55
6.1.3 Devices for Configuration and Control ...58
6.2 Deployment Architecture ...59
6.3 Universal Control...60
6.4 Rule-based Home Automation...61
6.4.1 Rule Management and Configuration ...61
6.4.2 Home Automation Executing ...63
6.4.3 Message Flow...64
6.5 Scaling to Internet and Other Network ...65
Chapter 7 Discussion and Conclusion ...66
7.1 Benefit of MHAP...66
7.1.1 Event-driven Home Automation in Heterogeneous Environment ...66
7.1.2 Device and Protocol Independent Platform ...66
7.1.3 Reliable Fault Tolerant Home Automation...66
7.1.4 High Scalability...68
7.1.5 High Extensibility ...68
7.1.6 Easy to Use...69
7.2 Comparison between MHAP and UMB ...69
7.2.1 Home Automation Support ...69
7.2.2 Messaging...70 7.2.3 Extensibility...70 7.2.4 Scalability...71 7.2.5 Reliability ...71 7.3 Conclusion ...72 7.4 Future work...73 7.4.1 Security...73
7.4.2 Integrating Sensor Network...73
7.4.3 MHP Support...73
List of Figures
Figure 1-1 appliances supporting different home networking technologies...1
Figure 1-2 the use cases of a Home Automation System in Heterogeneous Environment...3
Figure 1-3 reliability requirement of Home Automation System ...7
Figure 1-4 low interoperability of home networking technologies ...9
Figure 1-5 overview of HMAP ... 11
Figure 1-6 power on the air conditioner when the temperature rises over 28 ...12
Figure 1-7 power on the light and play a song when a FAX is coming...13
Figure 2-1 X10, IEEE 1394 and UPnP home networks...15
Figure 2-2 different kinds of home gateways devices ...17
Figure 2-3 OSGi: a case of the service management and deployment infrastructure..18
Figure 2-4 OSGi defines the environment for gateway networked services ...19
Figure 2-5 MOM decouples message passing between applications...21
Figure 2-6 the nondurable subscribers and subscriptions ...23
Figure 2-7 the durable subscriber and subscription ...24
Figure 3-1 architecture of MOM-based Home Automation Platform (MHAP) ...26
Figure 3-2 message routing in MHAP ...28
Figure 3-3 the service uses command message to control devices ...30
Figure 3-4 the services use query and state messages to get device states ...30
Figure 3-5 a event message reflects the change of the device state...31
Figure 3-6 dependencies among services in MHAP...32
Figure 3-7 the components of MHAP rules ...33
Figure 3-9 the message follow of “turn on X10 light when UPnP TV is powered on”
...35
Figure 4-1 the XML-based MHAP descriptors...37
Figure 4-2 an example of the device descriptor...39
Figure 4-3 an example of the service descriptor...40
Figure 4-4 allowed value list in service descriptor ...41
Figure 4-5 allowed values range in service descriptor...41
Figure 4-6 the mapping descriptor offers two-way protocol mapping information ....42
Figure 4-7 a piece of the mapping descriptor for a X10 device...43
Figure 5-1 the bundle cycle of MHAP services ...46
Figure 5-2 code example implementing BundleActivator...48
Figure 5-3 Implementing bundle handler ...49
Figure 5-4 code example implementing BundleListener...49
Figure 5-5 the manifest file of the MHAP rule engine bundle ...50
Figure 5-6 various Home Automation applications in MHAP ...53
Figure 6-1 the basic demonstration hardware ...55
Figure 6-2 appliances and sub systems of demonstration environment ...57
Figure 6-3 simulated devices of project CyberLink for Java...58
Figure 6-4 the deployment architecture of MHAP ...59
Figure 6-5 turn on a X10 light with a universal control application...60
Figure 6-6 the demonstration of universal control and the message flow ...61
Figure 6-7 rule management with configuration console ...62
Figure 6-8 set the demonstration rule with configuration console ...62
Figure 6-9 a demonstration of Home Automation accomplished by MHAP...63
Figure 6-10 message flow in Rule 2 of demonstration showed in Figure 6-9...65 Figure 7-1 region division provides the fault tolerant and reconfigurable Home
Automation ...67 Figure 7-2 Digital TV services join the automation through MHAP in the future ...74
List of Tables
Table 1-1 configuration and control use cases for a Home Automation System ...4
Table 1-2 administration use cases for a Home Automation System...4
Table 1-3 device automation use cases for a Home Automation System ...5
Table 3-1 attributes of MHAP messages...29
Table 5-1 the bundle states of MHAP service bundle...47
Table 5-2 listener interfaces about bundle, service and framework events ...48
Table 6-1 appliances in the demonstration environment ...56
Chapter 1 Introduction
In the last three decade, the science and technology for accomplishing Home Automation (HA) have progressed tremendously. On the other hand, with proposing of Digital home, many digital appliances may increasingly join the Home Automation system at home. Home Automation makes human life convenient through connection and collaboration between appliances and sub systems at home such as secure system [1]. For collaboration, such smart appliances and sub systems use home networking technology [2] to communicate with each other. Therefore, there have been more then twenty different kinds of home networking technologies on market such as X10 [3], INSTEON [4], UPnP[5] and HAVi [6].
Figure 1-1 appliances supporting different home networking technologies
Although there are many appliances supporting different home networking technologies (Figure 1-1), building a Home Automation system should use the appliances supporting one of them traditionally. A home network middleware doesn’t
Digital TV
AV player
Dimmers and switches Audio system Control console Mobile phone Sensors
U
U
P
P
n
n
P
P
H
H
A
A
V
V
i
i
X
X
1
1
0
0
I
I
N
N
S
S
T
T
E
E
O
O
N
N
Chimeunderstand the messages of the other home network. Even the appliances in one home network couldn’t physically connect to the other home network. However, in Digital Home environment, a home gateway such as a PC or a set-top-box can physically connect to each kind of home network. Recently, there have been substantial studies performed on one-to-one and one-to-many interoperability of heterogeneous home networking technologies. While some studies on device control in heterogeneous environments have been done, researches on Home Automation in such situation are still critically lacking.
1.1 Motivation
Although a home gateway can physically connect each home network, the appliances can’t communicate with each other because of the low interoperability of existing home network technology. For example, even a power line network connects to a wireless LAN through a home gateway; the event message from an UPnP media player is not understood in X10 network. Furthermore, a Home Automation system can’t consist of appliances in heterogeneous environments. Therefore, this paper proposes the MOM-based Home Automation Platform (MHAP), which integrates all home networks and offer Home Automation in heterogeneous environment.
1.2 Objective and System Goals
The objective of this study is to integrate all home networks and offer Home Automation in heterogeneous environment. Therefore, the study proposes a MOM-based Home Automation platform (MHAP) in heterogeneous environments to achieve the objective.
Figure 1-2 shows the use cases of a basic Home Automation system in heterogeneous. The rule manager is the user configuring the scenario of automation. The appliance operator is the user controlling the appliances. The system
administrator is the user managing the system. The appliances includes X10, Jini and LonWorks appliances. The external systems participating the Home Automation include location, temperature, motion detect and time system.
Figure 1-2 the use cases of a Home Automation System in Heterogeneous Environment
As Table 1-1 indicates, an ideal Home Automation system offers easy-to use configuration and control functions for user. Therefore, the user can reconfigure the scenario of Home Automation every time when his requirement changes. The user can also control and monitor the appliances and the subsystems at home through a consistent method. They needn’t prepare different controllers to control different appliances or subsystem. Set automation rule View automation rule Delete automation rule View appliance
information Maintain appliance information Set user permission Add user View user information Delete user Control appliance Detect motion Detect temperature Provide location information Execute home automation rule Change appliance state Provide time information Rule manager Appliance operator Motion detection system Temperature detection system Location system Time system Jini appliance LonWorks appliance UPnP appliance X10 appliance System administrator
A Home Automation System in Heterogeneous Environments Login <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<extend>> <<extend>> <<extend>> <<extend>> <<extend>> <<extend>> <<extend>>
Table 1-1 configuration and control use cases for a Home Automation System
Use Case Actors Description
Login
Rule manager, System administrator, Appliance controller
The User uses account and password to login to MHAP.
Set automation rule Rule manager The user sets the rules for Home
Automation.
View automation rule Rule manager The user browses the rules for Home
Automation set before. Delete automation
rule Rule manager
The user removes the specified rule for Home Automation set before.
View appliance
information Rule manager
The user browses the states of specified home appliance.
Control appliance Appliance operator The user sets the states of specified home
appliance.
On the other hand, a Home Automation system requires the administration mechanism to manage the user permission and device information. Table 1-2 indicates the function of administration in a Home Automation.
Table 1-2 administration use cases for a Home Automation System
Use Case Actors Description
Add user System administrator The system administrator adds the
account for new user.
Delete user System administrator The system administrator deletes the
account of specified user. View user
information System administrator
The system administrator browses the account of specified user.
Set user permission System administrator The system administrator sets the
permission of specified user. Maintain appliance
information System administrator
The system administrator sets URL for the profiles of the appliances.
automation. As Table 1-3 describes, the appliances can cooperate with any other subsystem or appliances even if they are supporting incompatible home network technologies.
Table 1-3 device automation use cases for a Home Automation System
Use Case Actors Description
Detect motion Motion detection system
External motion detection system detect the change of motion states and then MHAP checks if any Home Automation operation should be finished according to the rules.
Detect temperature Temperature detection system
External temperature detection system detect the change of temperature states and then MHAP checks if any Home Automation operation should be finished according to the rules.
Provide location
information Location system
External Location system detect the change of location states and then MHAP checks if any Home Automation operation should be finished according to the rules.
Execute Home Automation rule
Appliance operator, Motion detection system, Temperature
detection system, Location system
The MHAP executes Home Automation operations to control the X10 appliance, UPnP appliance, LonWorks appliance or Jini appliance.
Change appliance state
X10 appliance, UPnP appliance, Lonworks appliance, Jini appliance
The appliances change it state by itself, and then MHAP checks if any Home Automation operation should be finished according to the rules.
Provide time
information Time system
External time system detect the change of time states and then MHAP checks if any Home Automation operation should be finished according to the rules.
goals indicated and explained as follows: 1.2.1 Event-driven Home Automation
In a Home Automation system, events represent the changes of states of appliances or sub systems. Some Home Automation operations need events to trigger them. Therefore, a complete Home Automation platform should support the event-based Home Automation. MHAP is proposed to provide the events across different home networks. To take a simple example, in MHAP, the change of the power state of an UPnP media player is an event which may trigger another Home Automation operation like closing an X10 light. With such mechanism, the person at home can close the light in living room by powering off the television in bedroom.
1.2.2 Protocol and Platform Independence
Another goal of MHAP is being device and protocol independent. Therefore, Home Automation not limited by the kinds of home networking technology. MHAP is designed for heterogeneous environments and over any existing or new device and protocol. Any kinds of the appliances capable of any home networking technology such as UPnP multimedia players, X10 motion sensors or INSTEON dim lights could join a MHAP system. When adding an appliance which uses an additional protocol, it can also cooperate with the existing appliances to finish Home Automation through MHAP.
1.2.3 Reliability and Fault Tolerance
Reliability and Fault Tolerance: Certain kinds of Home Automation operations, especially the operations of security systems, must be reliable (Figure 1-3). For example, there were a series of Home Automation operations executing, which automatically lock the door at 11:00 PM. If a child shut down the home gateway at that time, the MHAP should continue to finish the previous locking operation after
system restart.
Figure 1-3 reliability requirement of Home Automation System
On the other hand, when some appliances or certain part of the network fail, the system should be still effective because the Home Automation operation may relate to security closely. The MHAP should offer fault tolerant function to ensure the system’s working to handle the situation, especially when cooperating with Internet services. 1.2.4 High Scalability
People may buy new appliances and the appliances are joining Home Automation increasingly. However, increasing of the number of appliances at home should not apparently affect the performance of the MHAP. On the other hand, MHAP is designed to scale from home domain to building, campus and Internet. That is, the appliances at home can cooperate with other appliances at the building or an Internet service to facilitate human life.
1.2.5 Extensibility
High extensibility is an important goal of the MHAP. There may be some appliances only supporting additional home networking technology on market. The extensibility of MHAP makes new smart appliances and new home networking
L
Loocckktthheeddoooorroonn1111::0000PPMM……......
technologies join the MHAP dynamically. 1.2.6 Easy to Use
MHAP is designed for providing human reconfigurable Home Automation and human convenient way to configure Home Automation at home. Every change of the Home Automation setting or scenario needn’t complex processing such as downloading separate macro program or configuration to each appliance. On the other hand, MHAP is proposed to provide convenient service deployment and management mechanisms. The Home Automation software needs update when the user plugs the additional appliances into the platform. MHAP will automatically download the updating software bundle from service provider through internet. When updating and activating the additional bundle, the other service running will not be affected. Besides, the user can easily install, activate, deactivate and uninstall the software bundle from MHAP without stopping all services.
1.3 Problems
Although different home networks can be physically connected through home gateway, MHAP needs to solve problems on Home Automation in heterogeneous environment.
1.3.1 Low Interoperability of Home Networking Technologies
Most home network technologies have low interoperability. Although connecting physically, the message of one home networking technology can’t be understand by the other home networking technology. For example, even the power line network used by connected to a wireless LAN used by UPnP, the event message of UPnP could not be understand in X10 network.
Figure 1-4 low interoperability of home networking technologies
1.3.2 Hard to Support Event-driven Model
A complete Home Automation system needs event-driven model to trigger the device operation. But in heterogeneous home networking environments, low interoperability of the home networking technologies led to the absence of the events passing through different home networks.
1.3.3 Reliability
Such a Home Automation system needs reliability. As the automation operation interrupted for some reason such as fault of the home gateway, the reminder operation may need to be finished. Therefore, MHAP needs to take extra effort to make both the operation and the event triggering the operation reliable.
1.3.4 Scalability and Extensibility
A Home Automation system should consider the scalability problem. The number of appliances at home will constantly increase. If the Home Automation system can’t scale well, it will influence the automation operations or even crash the system. Sometimes people may hope that the automation scales to Internet. However,
Jini fax machine
UPnP audio system Jini network
UPnP network
the home networking technologies such as X10 and INSTEON can’t scale to Internet. The MHAP should solve the problem caused by the existing home networking technologies. Besides, the MHAP has to make the device be identified by Internet Service. In the future, new home networking technologies may be proposed. A Home Automation system should work with the appliances of the networking technology. A Home Automation system in heterogeneous environment needs to solve such extensibility problem.
1.3.5 Deployment and Management
A Home Automation system may need to be updated for support new appliance or home networking technology. The internet accessibility provide home gateway the opportunity, but different service provider may provide different update method or software bundle. While updating, maybe the Home Automation can’t be interrupted or stopped. The deployment and management problems may exist in a Home Automation system.
1.4 MHAP Solution
To accomplish the goals and solve the problems, MHAP solution introduces the Message Oriented Middleware (MOM) [7] into Home Automation systems and provides event-driven Home Automation. Figure 1-5 represents the MHAP solution. Inside home, MHAP on home gateway connects each home network and the rule engine service performs as an application router. MHAP accomplish Home Automation through platform and protocol independent MHAP message flow. Application router handles the message flow among the appliances depends on the Home Automation rules of MHAP.
Figure 1-5 overview of HMAP
MHAP is entirely deployed on the standard deployment and service management infrastructure, for example, Open Services Gateway initiative (OSGi) [8]. Therefore the services or software bundles on MHAP could be installed and updated through Internet from service provider and easily managed.
1.4.1 Message Oriented Middleware (MOM)
MHAP is based on Message Oriented Middleware (MOM). The MOM introduces the event-driven into the platform since the event is a special message in MOM. The model of MOM in MHAP is publish/subscribe. This kind of model scales well while the receiver such as appliances increases. Because different appliance subscribes different channel in MOM, plugging in new appliance will not influence the Home Automation currently running in MHAP. Even adding the protocols and appliances of the new Home Automation technology will not influence the system. Furthermore, the durable subscription and persistent message of MOM makes messaging reliable. With MOM core, MHAP support the reliable operation required in Home Automation systems. MHAP uses Java Message Service, the standard MOM interface for Java, to access all function of MOM. Therefore, different MOM providers can be chosen to
X10 light
Message oriented middleware
X10 temperature sensor UPnP Media Server
Jini FAX machine
HA rule engine (Application router) Internet Inside home HA Rule configuration consoles Service provider :OSGi Gateway :Gateway, PC or Server
gain different degrees of performance of MHAP.
1.4.2 Standard Deployment and Service Management Infrastructure
All MHAP components are deployed on the standard deployment and service management infrastructure which is OSGi presently. Through the OSGi, software or service bundles on MHAP can be transferred from service provider through Internet, and the software and hardware provider can developer their own products without influencing each other. Deploying on such infrastructure makes MHAP highly extensible. Furthermore, the services on MHAP such as protocol adaptor can install independently without stop all the system or current automation operation.
Figure 1-6 power on the air conditioner when the temperature rises over 28
1.4.3 Rule Based Home Automation
MHAP provides the rule services instead of the traditional API or program. The Home Automation operation is indicated by rule. For example, a user can set the rule “Power on the air conditioner when the temperature rises over 28” with various kinds of configuration console. Then the temperature becoming over 28 degrees centigrade will trigger the Home Automation operation which is to power on the are conditioner.
Figure 1-7 indicates another MHAP rule which three different appliances
X10 UPnP
2. The air conditioner is powered on.
X10 temperature sensor
UPnP air conditioner 1. The
temperature rises over 28 degrees centigrade.
participate in. If a fax is coming, the Home Automation that CD player starts to play the song “Unchained Melody” and power on the light will be finished.
Figure 1-7 power on the light and play a song when a FAX is coming
There is one other thing that is important for HMAP rule. All device and appliances are abstracted by XML descriptors. The HMAP rule which has been set will not need to change even thought the appliances belonging to home technologies added in the future.
HA platform
X10 light
Jini FAX machine UPnP CD player X10 Jini UPnP 1. A FAX is coming. 2.b The Light is powered on. 2.a The CD player starts to play “Unchained Melody”
Chapter 2 Background and Related Work
2.1 Home Automation
Home Automation (HA) means that the device or appliance at home connects and collaborates with each other to facilitate the human life. A Home Automation system can schedule and automatically operate the appliances in the home network for convenient or secure purpose. Besides, the change of an appliance’s state may also cause the change of another appliance’s state or trigger some action of another appliance in a Home Automation environment.
Basically, the main components of a Home Automation system include devices with automation programs or services and various appliances being controlled or providing state information. With the vigorous development of Digital Home, the former may be home gateways in the future. The latter are subsystems supporting any home networking technology, for example, the lighting, security system, entertainment, thermostat, irrigation or other appliances.
2.2 Home Networking Technologies
Many home networking technologies [10] recently developed such as UPnP, HAVi, X10, INSTEON, Jini [11] and LonWorks [12] have provided appliances with connectivity. Traditionally, the appliances supporting one of these home networking technologies communicate with each other to finish Home Automation. Because most home networking technologies use different protocols and different kinds of networks usually can’t be connected physically, they have low interoperability (Figure 2-1). Therefore, the appliances of a Home Automation system must support the same home networking technology before.
Power line network IEEE 1394 network HAVi appliances IP network X10 appliances UPnP appliances
Figure 2-1 X10, IEEE 1394 and UPnP home networks
2.2.1 X10
Pico Electronics Company developed the X10 in 1975. For accomplishing Home Automation, the X10 defines the protocols for communication among devices. It uses the power line as primary physical media of signaling and control and also defined a radio based transport. All appliances and controllers in a network can only transmit one command at a time with X10 singles. The X10 receivers can’t decode the command when two signals collide. The traditional X10 protocol is slow compared with other technologies using power line such as LonWorks and INSTEON.
2.2.2 INSTEON
The INSTEON also use electrical wiring and radio frequency to transmit messages like X10. However, INSTEON confirms that every message is received and will automatically resent the message when detecting errors. Each INSTEON device is a repeater to enhance the quality of the network. Although the INSTEON protocol and X10 protocol are not compatible, INSTEON allows manufacturers to develop
INSTEON-compatible products which are X10-ready. Therefore, the kind of INSTEON can work in existing X10 networks. However, the INSTEON devices don’t repeat X10 signals and can’t improve the disadvantage of existing X10 networks. 2.2.3 Universal Plug and Play (UPnP)
UPnP is a distributed, open home networking technology based on existing standards such as Transmission Control Protocol (TCP), Hypertext Protocol (HTTP) and Extensible Markup Language (XML). UPnP offers the architecture to accomplish pervasive peer-to-peer network connectivity of devices such as the personal computer, intelligent and wireless devices [13]. The networking architecture of UPnP is on the top of TCP/IP to control and transfer data among networked devices among the home, office, and public spaces. Therefore, the UPnP are used to discover other devices on the network and remotely control appliances and share information among devices and the World Wide Web. Besides, the UPnP also offers the event subscription mechanism for devices [14]. The UPnP forum is standardizing the device and service with defining and publishing UPnP device and service descriptions. The standardization makes the devices easily connect with each other and simplify the implementation of networks.
2.2.4 Home Audio/Video Interoperability (HAVi)
The home audio/video interoperability (HAVi) is vendor-neutral audio-video standard for home entertainment environment. With IEEE 1394 as the interconnection medium, the architecture of HAVi includes a set of application programming interfaces (APIs) and services. In HAVi environment, different home entertainment devices such as VCRs, security systems connects together and the primary device such as a television can control the others. HAVi associated each physical device with a software proxy [16]. Therefore, adding software proxy can extend the feature of the
device. On the other hand, when a user installs a new device, the HAVi system is able to configure itself to accommodate it. The HAVi also offers the function of addressing scheme, resource discovery, posting and receiving events, streaming and controlling isochronous data streams.
2.2.5 Jini
Jini network technology is an open software architecture for building distributed systems which is highly adaptive to change [17]. Jini offers object services to clients and the discovery of the available services [18]. Differing from other distributed object systems, Jini is designed for the dynamic distributed environment, where the services are transient and the network is unreliable. Before the client use the service, the Jini environment downloads the mobile code into the client. The client then communicates with services through the mobile code. The client needn’t be re-implement when the protocol changes. The changes of the protocol are private to the service and to the mobile code. Therefore, Jini is the technology suitable for building the evolvable, flexible and adaptive network required in dynamic computing environments such as a home network.
Figure 2-2 different kinds of home gateways devices Personal computer
Game console
2.3 Home Gateway
2.3.1 Home Gateway Device
A home gateway is a device being able to connect to the Internet and to be an entertainment and networking center at home. Therefore it allows communication and control between service providers and the devices within the home network. The communication channels used by the device are seen in home networking technologies such as UPnP and TCP/IP. The communication among different notions of services and service discovery are accomplished by XML-like standard [19]. The hardware of home gateway can be personal computers, set-top-boxes, DSL gateways or game consoles such as Xbox and PS2.
Figure 2-3 OSGi: a case of the service management and deployment infrastructure
2.3.2 Middleware of Home Gateway
Some middleware technologies provide the standard way to connect the home gateway to the Internet. Therefore, some middlewares such as Open Services Gateway initiative (OSGi) provide not only the application programming interface (API), but
C Clliieenntt S Seerrvviicceepprroovviiddeerr W Wiiddeeaarreeaanneettwwoorrkk C Clliieenntt SSeerrvviiccee11 SSeerrvviiccee22 DDeevviiccee O OSSGGiiFFrraammeewwoorrkk G GaatteewwaayyOOppeerraattoorr H Hoommeenneettwwoorrkkss O Oppeennsseerrvviicceeggaatteewwaayy S Seerrvviicceemmaannaaggeemmeenntt s syysstteemm : :OOSSGGiissttaannddaarrddiizzeeddAAPPII A Apppplliiaanncceess
also the deployment infrastructure and service management platform. In a Home Automation system, the home gateway may physically connect to different kinds of home network and control the appliances within them.
2.3.3 Open Service Gateway Initiative
The OSGi is a set of specifications which defines a standardized and component oriented computing environment for networked services [20]. Executing in a networked device such as an embedded device, an OSGi service platform is capable of managing the life cycle of the software components in the device. The management includes dynamically install, update, or remove the software components without disrupting the operation of the device. The software components in OSGi can dynamically discover and use other components and dynamically integrates into a further application or library [21]. The OSGi contains some standard component interfaces such as HTTP servers, logging, security, XML, and many more. Therefore, an OSGi service platform can use different implementations of the components from different vendors to obtain different optimizations.
Figure 2-4 OSGi defines the environment for gateway networked services B Buunnddlleess M Moodduulleess L LiiffeeCCyyccllee S Seerrvviiccee R Reeggiissttrryy L1: define class loading policies L2: manage the life
cycle of services
Applications in OSGi
L3: provides a model to share objects among
bundles OOSSGGiiFFrraammeewwoorrkk E Exxeeccuuttiioonn E Ennvviirroonnmmeennts L0: specification of the Java environment
Traditionally, developing software component in a service gateway require complex developing and maintaining configurations. However, the OSGi software component architectures can simplify this configuration process [22]. The unit of application software for OSGi is called the bundles. The OSGi framework which is the core of the OSGi specification provides a standardized environment to the bundles. As Figure 2-4 shows, the OSGi framework is divided into four layers which are execution environment, modules, life cycle management and service registry.
Execution environment: Since the OSGi framework is based on Java, the lowest layer is the specification of valid Java environment, for example, J2SE, CDC, or CLDC. In this layer, the OSGi also define the minimum requirements on an execution environment for bundles.
Modules: Based on the top of Java environments, the OSGi framework offers modularization and defines the class loading policies in this layer. The basic Java environment only has a single shared classpath containing all the classes and resources. Furthermore, the OSGi Modules layer enhances the base environment. The layer which is a class loading module controls linking between modules and allows each module has private classes.
Life Cycle layer: The layer offers the API managing the life cycles of bundles in runtime. Therefore, the bundles can be dynamically installed, started, stopped, updated and uninstalled. The layer also provides the extensive dependency mechanisms assuring the correct operation of the environment.
Service Registry: The traditional Java class sharing is not very compatible with dynamically installing and uninstalling code. Therefore, the service registry layer offers a comprehensive cooperation model to share objects between bundles. OSGi services are represented as Java objects. The layer also defines the events to handle the services in runtime.
Because of the characteristics of OSGi, the companies especially developing embedded system will benefit from adopting the specifications in many aspects. The benefits include development cost, customization, deployment cost and unification. 2.4 Message Oriented Middleware
Message oriented middleware (MOM) technology was used for enterprise applications for many years. Functionally, MOM is a middleware transporting messages from a source component to target components. It decouples the message passing between the client and the server. Therefore, when passing message, the client and server don’t have to be online simultaneously. Nowadays, the application of MOM has extended from enterprise to mobile applications [23] [24] [25]. Many different MOM products coexist on market. Nevertheless, the system can move from one to another MOM implementation without large change through the standard API for MOM such as Java Message Service (JMS). [26]
Figure 2-5 MOM decouples message passing between applications
2.4.1 Publish/Subscribe Model
There are two main types of MOM, message queuing and publish/subscribe. Message queuing MOM handles messages through point-to-point approach. The massages should pass the virtual channel which is called "queue," and each message will be received by only one receiver.
MOM Application logic Client MOM Client MOM Subscribe message Server
MOM Message Broker Publish message
By contrast, MOM of publish/subscribe transmits messages by one-to-many way. The message sender, which is called publisher in MOM, produces and publishes messages under a certain topic, such as “upnp.bedroom.tv.” A topic is a virtual channel in publish/subscribe approach. The receivers, which are called subscriber in MOM, subscribe to a topic and then the MOM will push the messages addressed as the certain topic to subscribers. The middleware ensures that all subscribers receive all messages from all publishers on topics. For example, the MOM guarantees all subscribers of “upnp.bedroom.tv” receive all information from all publishers on the topic.
2.4.2 Benefit of MOM
Most present MOM products have the common properties of reliability and scalability. Supporting durable subscription and persistent message of MOM provides the guaranteed delivery of messages. Guaranteed delivery of messages also makes MOM suitable for machine-to-machine communication. The publish/subscribe model let MOM systems scale well when message simultaneously passing to many receivers. Besides, for an event is just considered as a special message, MOM is suitable for building event-driven system.
2.4.3 Persistent Message
The persistent message mechanism of MOM makes sure that a message published will still push to the subscriber after the MOM provider fails. When the publisher publishes a persistent message, the MOM provider will make extra effort to ensure that the message is not lost in transit. For example, the MOM provider usually logs the persistent message to persistent storage when it is sent.
2.4.4 Durable Subscription
consumer by the subscriber which is offline or inactive when the message arrives. The durable subscriptions offer the reliability of queues to the publish/subscribe model of MOM. When subscriber creating a durable subscription is offline, the MOM provider retains the messages of the subscription until the subscriber consumes them or the subscription expires. Once the subscription is reactivated, the MOM provider delivers the messages published while the subscriber was inactive or offline.
Figure 2-6 and Figure 2-7 show the difference between a nondurable subscription and a durable subscription. In the case of durable subscription, the subscriber and the subscription are coterminous. Therefore, when subscriber is closed or offline, the subscription ends. Between the time when the subscriber is inactive and the time when the subscriber is active again, the subscriber can’t consume the message published to the topic. Therefore, in the Figure 2-6, the subscriber consumes messages m1, m2, m5, and m6, but can’t consume messages m3 and m4 which will be lost.
Figure 2-6 the nondurable subscribers and subscriptions
In the case of durable subscription, the subscription continues to exist and to hold messages until the application unsubscribe the topic when the subscriber is offline or close. The MOM provider stores the messages and pushes them to the subscriber Subscription Subscription
Subscriber Subscriber Time
m1 m2 m3 m4 m5 m6
Create Close Create Close
: Message received : Message lost
when the subscriber is online again. The subscriber will still receive the messages published when the subscriber is inactive or closed. In Figure 2-7, the messages m3, m4 arrive while the subscriber is inactive are not lost and the MOM push them to the subscriber when the subscriber is active later.
Figure 2-7 the durable subscriber and subscription
2.5 Related Work
2.5.1 Interoperability of Home Networks
The past researches about heterogeneous home network focused on interoperability among different home networking technologies. There are two kinds of approaches to developing the interoperability of heterogeneous home network The first kind is the one-to-one bridge and the second kind is the one-to-any middleware.
One-to-One Bridge: There are many one-to-one bridge middleware such as “Experimental Bridge LONWORKSR/ UPnP” [27] and “Jini Meets UPnP: An Architecture for Jini/UPnP Interoperability.” [28] Besides, there has been also the bridge between Jini and the SLP-Jini [29] and the bridge between Bluetooth ESDP
Subscription
Subscriber Subscriber Time
m1 m2 m3 m4 m5 m6
Create Close Create Close
: Message received : Message lost
Create Unsubscribe m3 m4
and UPNP [30]. The bridge develop the interoperability between two protocols, and the makes the appliances and services in the two networks can cooperate and communicate with each other. However, when there is a new home network added to the environment, the developer should develop bridges between the kind of the new home network and each kind of the existing home networks. Therefore, the (n*(n-1))/2 cost conversion complexity through one-to-one bridges is too high when the number of home networking technologies is increasing.
One-to-Any: The one-to-any approach may be more suitable for Home Automation in heterogeneous environment [31][32][33], for example, “A Framework for Connecting Home Computing Middleware” proposed by Eiji Tokunaga et al.[34] and Universal Middleware Bridge (UMB)” proposed by Kyeong-Deok Moon et al. [35]. With the former, all the converting interfaces should be regenerated via javassist tool when user adds an appliance which is supporting new protocol. Therefore, the former is not convenient for Home Automation. On the other hand, UMB is also not the platform for Home Automation. The research on Home Automation in heterogeneous environment like MHAP is very lacking.
2.5.2 Application in Heterogeneous Environment
There are some studies on application in heterogeneous home networking environments. Universal Remote Console (URC) is a study to offer control function of all device for user [36]. “A Communication Architecture for Spontaneous Systems” proposed by J. Latvakoski et al. [37] uses Session Initiation Protocol (SIP) [38] and OSGi to provide a spontaneous system among personal area networks. However, researches on Home Automation in heterogeneous home networking environment are critically lacking.
Chapter 3 System Architecture
3.1 Layered Architecture
For adapting heterogeneous Home Automation environment and application, MHAP has a four-layered architecture showed by Figure 3-1.
3.1.1 Physical Device and Network
The bottom layer consists of any home network and physical device or appliance supporting of home networking technology. MHAP aims at working over any device and home network environment, even the new one appearing in the future.
Figure 3-1 architecture of MOM-based Home Automation Platform (MHAP)
3.1.2 Service Infrastructure
The layer provides service management and deployment functions for MHAP services. With increasing on different protocols or appliance manufacturer, MHAP needs to install new service bundles and update the existing service bundles. Infrastructure layer guarantees MHAP service bundles activate and deactivate
O OppeennSSeerrvviicceeGGaatteewwaayyIInniittiiaattiivve e M MOOMMSSeerrvviiccee C Coonnffiigguurraattiioonn S Seerrvviicceess R RuulleeEEnnggiinnee MMaanDnDaaeeggvveeiiccmmeeeenntt S Seerrvviiccee A Addaappttoorrss EExxtteennssiioonn S Seerrvviicceess A Addmmiinniissttrraattiioonn T Tooooll R Ruulleeccoonnffiigguurraattiioonn T Teerrmmiinnaall A Apppplliiaannccee M Moonniittoorr U Unniivveerrssaall C Coonnttrroolllleerr P PhhyyssiiccaallDDeevviiccee a annddNNeettwwoorrkk S Seerrvviiccee M Maannaaggeemmeenntt&& D Deeppllooyymmeenntt M MHHAAPPSSeerrvviiccee L Laayyeerr A Apppplliiccaattiioonn L Laayyeerr
dynamically with dependency check. It must provide standardized methods to control life cycle of services including downloading and installation from service provider through Internet. In the apparent reference implementation, MHAP choose the Open Service Gateway Initiative as the layer.
3.1.3 MHAP Service
The third layer is MHAP service layer, which is the core of MHAP and consists of many services. In brief, the layer provides all functionalities in event-based Home Automation, which includes event notification, appliance control, Home Automation rule configuration and device management, etc. MHAP service layer is also an adaptation layer, which let program or services operate appliances supporting different Home Automation technologies with the same method. Internally, the layer introduces MOM technology as the method to support event-driven Home Automation in heterogeneous environment. Furthermore, the special application routing in MOM makes the design and implementation of message routing more simple and visual especially when there is more rule added.
3.1.4 Application
The top layer is application layer. Facilitating Home Automation needs many different kinds of applications, for example, the administration tools, rule configuration terminal, appliance monitor or controllers. With assistance of the first three layers in MHAP, developing all of these Home Automation applications is easier. Even through there are many different kinds of home network appliances and technologies, developers needn’t consider the complex differences in appliance and network.
3.2 MHAP Messaging
Furthermore, the message routing in MOM is the main method to finish rule-based Home Automation. There are four main MHAP message types, which are respectively command, query, state and event.
Figure 3-2 message routing in MHAP
As Figure 3-2 shows, two main services communicating with each other are the rule engine and the adaptor. MHAP rule is the basic unit representing automatic Home Automation operations assigned by the user. Rule engine is the application router in MHAP to route the Home Automation message between the adaptors through referring MHAP rules. An adaptor service is the proxy of some kinds of physical home appliances, which creates virtual appliance objects through MHAP descriptors. Different appliance manufacturers or service provider could implement different adaptor to make such appliances join into MHAP.
There are four main MHAP message types, which are respectively command, query, state and event (Table 3-1).
MHAP message Native message
Jini adaptor
Message Oriented Middleware
UPnP adaptor
X10 adaptor
Jini home appliances X10 home appliances Jini
UPnP Messages
X10 signals Rule engine UPnP home appliances
Subscribe/Publish [protocol/adaptorID].[location].[deviceType]
Message Main Field Meaning
Device ID Indicate the target appliance
Source ID
Indicate the source of the message; for example, the value is the service id of a rule engine when it send a command
Service ID Assign the service inquired
Action name Indicate the action demanded to invoke
Argument name Indicate the arguments needed Command
Argument value Carry the value of a argument
Device ID Indicate the appliance sending the event
Service ID Indicate the service which the event belongs to
State variable name Indicate the state variable of the service which the
event reflects the change of it
State variable vale Carry the value of the state variable associated with
the event Event
Date type Indicate the date type of the state variable
Device ID Indicate the target appliance or service
Source ID Indicate the source of the message
Service ID Assign the service which is demanded to query the
state Query
State variable name Indicate the state variable which is queried
Device ID Indicate the appliance sending the message
Service ID Indicate the service which the state belongs to
State variable name Indicate the state variable of the service
State variable vale Carry the value of the state variable State
State variable type Indicate the date type of the state variable
Table 3-1 attributes of MHAP messages
3.2.1 Command Message
The MHAP controls the appliances by command message. For example showed by Figure 3-3, the rule engine sends the “power on” command messages to power on the appliances. The adaptors of the appliances received the control message need not response.
Figure 3-3 the service uses command message to control devices
3.2.2 Query Message
The function of MHAP query message is to attain the state of appliances. MHAP services can publish query message if it wants to know the state of an appliance. Then the MOM provider will push the query message to the adaptor handling the appliance. 3.2.3 State Message
Once the adaptor of the appliances receives the query message, the adaptors respond the MHAP state message containing the state information inquired. Figure 3-4 shows an example of query message and state message. The device management sends a query message to ask the power state of a light and the adaptor of the light replies a state message indicating that it is powered on.
Figure 3-4 the services use query and state messages to get device states R RuulleeEEnnggiinnee U UPPnnPP A Addaappttoorr Command Play video Query State I INNSSTTEEOONN A Addaappttoorr State is “On” Query power state D DeevviicceeMMaannaaggeemmeenntt S Seerrvviiccee
3.2.4 Event Message
To notify the services, such as the rule engine, needed to be notified when some state of an appliance changes, the MHAP event message may be sent by the adaptor of the appliance while the state of the appliance changes (Figure 3-5). To send event messages, the event of the state should be subscribed by at least one service.
Figure 3-5 a event message reflects the change of the device state
3.2.5 Routing and Topic Naming
For introducing the publish/subscribe model of MOM, MHAP accomplishes high extensible Home Automation through message flow. In MHAP, every component subscribes and publishes different topics. As Figure 3-2 shows, a topic is an independent channel from a component to the MOM provider. Because each virtual appliance subscribes and publishes messages through independent channel, the joining of new appliance does not affect the existing Home Automation completely. There are some components in the figure. Rule engine is the application router in MHAP dispatching the message among the components according to MHAP rules. MHAP rule is the basic unit representing automatic Home Automation operations assigned by the user. An adaptor service is a proxy of certain kind of physical home appliances, which creates virtual appliance objects through MHAP descriptors.
R Ruullee EEnnggiinnee U UPPnnPP A Addaappttoorr Event State changed form “Play” to “Stop”
The handling of MHAP message flow could be simplified through topic naming. The application router such as rule engine just let different service or virtual appliance subscribe different topic to finish message dispatching. The naming rule of topics is [protocol/adaptorID].[location].[deviceType]. When a user set a Home Automation rule, the rule engine will subscribe the event indicated in the rule. For example, A rule engine is handling a rule which will turn on the X10 light in room1 when the UPnP TV in room2 is powered off. The rule engine just subscribes the topic “upnp.room2.tv” to receive the event. When receiving the event, the rule engine will publish a command message to the topic “x10.room1.light,” and then the MOM will push the message to the adaptor handling the command. Furthermore, the components in MHAP can use “*” to subscribe or publish messages of the same property at a time. For example, a component in MHAP can subscribe all x10 message from any appliance in every room through subscribing “X10.*.” The same is true of other properties in topics.
Figure 3-6 dependencies among services in MHAP X10 Adaptor Rule Engine Interface Rule Engine Service MOM Service UPnP Adaptor Adaptor Interface OSGI Framework MOM Provider Configuration Interface Configuration Service Configuration Terminal
3.3 MOM Service
As Figure 3-6 shows, the MOM service in MHAP provides the JMS standard interface to publish and subscribe MOM messages. The current MHAP implementation used ActiveMQ as default JMS provider. Because JMS doesn’t define load balancing, fault tolerance, security, and administration functionality, such mechanisms are provided by JMS providers and optional. Therefore, a MHAP system can choose different JMS provider software to achieve different degree of guarantee of such properties.
3.4 Rule Engine
The rule engine is the service handling MHAP message flow according to the rules set by the user with the rule configuration console. The rule engine is designed as an application router. By publishing and subscribing messages, the rule engine controls the message flow which finishing Home Automation according to the rules.
Figure 3-7 the components of MHAP rules
Once the user sets a rule, the rule engine subscribes the event messages the rule needs. When receiving event messages, the engine refers the rules to check if any operations should be triggered by the event. Then the rule engine will publish the command messages if the operation should be executed. A MHAP rule engine is an
R Ruullee 1 1 1 1..* 1 0..* A Accttiioonn E Evveenntt The Home Automation operation needs finishing The event which
triggers the operations assigned by the rule
Provide further function to determine if the rule should be applied by rule engine F
OSGi service. Therefore, it could be updated and activated dynamically. There is one thing to emphasize, which the MHAP consists of services and deployed on the service deployment and management infrastructure such as OSGi.
3.5 Adaptor
In MHAP, the adaptor is the proxy services of appliances (Figure 3-8). The adaptor is responsible for subscribing/publishing MHAP messages and bridging the MHAP message and native messages such as UPnP messages (Figure 3-9). The appliances belonging to a protocol or designed by a manufacturer may use the same adaptor. The adaptor needn’t be re-implemented through the MHAP descriptors such as the device descriptor, service descriptor and protocol mapping descriptor.
Figure 3-8 an example of the UPnP adaptor
3.5.1 Publishing/Subscribing MHAP Message
The adaptor subscribes and publishes MHAP messages as the proxy of the appliances. For the low interoperability of present home network technologies, the appliances only understand the native messages such as UPnP messages. Therefore, MHAP used the platform independent messages, MHAP message, to communicate
A
A
d
d
a
a
p
p
t
t
o
o
r
r
UPnP network UPnP Messages Inside MOMM
M
H
H
A
A
P
P
s
s
e
e
r
r
v
v
i
i
c
c
e
e
s
s
MHAP Messages Subscribe/Publish MHAP messages as a proxy of devicesBridge MHAP and native Messages
with each appliance and device.
The adaptor transmits or receives messages through publishing or subscribing messages. The adaptor publishes the state message when receiving the query message which requires the numbers of the appliances. The adaptor also publishes events messages when there are changes of the state occurring in appliances. Furthermore, the adaptor subscribes the query message and command messages belonging it manufacturer or home networking technology.
Figure 3-9 the message follow of “turn on X10 light when UPnP TV is powered on”
3.5.2 Bridging MHAP and Native Messages
According to the protocol mapping descriptor, one kind of the MHAP descriptors, the adaptor bridges the MHAP messages and the native message such as UPnP, X10 or INSTEON messages. For example, when receiving a MHAP command message to an INSTEON light, the adaptor sends the counterpart of native INSTEON command to the INSTEON light through the INSTEON network. When an adaptor receives the
