Introduction to Home Plug and Play Specification

Document Sample
Introduction to Home Plug and Play Specification Powered By Docstoc
					                                           ISO/IEC JTC 1/SC 25/WG 1           N 808
                                                              WG 1 (Cancun. Wacks) 3
                                                              Date: November 11, 1998



                              ISO/IEC JTC 1 SC 25 WG 1
                Interconnection of Information Technology Equipment
                               Home Electronic System



Title:                 Introduction to the Home Plug and Play Specification



Source:                United States



Project:               Working Group 1, Project 25.01.07.01 (subject to approval)



Requested Action: Review, critique and expand



Reason:                Action item assigned by WG 1 in Tokyo 6/98



Distribution:          All WG 1 members



Notes:

This document was composed by Dr. Kenneth Wacks of the United States with inputs from the
U.S. Technical Advisory Group. Comments should be directed to Dr. Wacks at +1-781-662-
6211, fax: +1-781-665-4311, E-mail: kenn@alum.mit.edu.
                                                     TABLE OF CONTENTS

1. Scope ............................................................................................................................................1

2. Adapting Home Plug and Play to HES ........................................................................................2

3. Home Plug and Play Overview ....................................................................................................3

1. Annex A: Overview of Home Plug and Play Specification ........................................................5

           1.1 Origin .............................................................................................................................5
           1.2 Scope ..............................................................................................................................5
           1.3 Purpose...........................................................................................................................5
           1.4 Organization ...................................................................................................................5
           1.5 Specification Compliance ..............................................................................................6
                  1.5.1 Levels of Compliance .....................................................................................6
           1.6 Versions .........................................................................................................................6
                  1.6.1 Past ..................................................................................................................6
                  1.6.2 Future ..............................................................................................................6
           1.7 Nomenclature .................................................................................................................7
           1.8 References ......................................................................................................................7
                  1.8.1 Base Standards ................................................................................................7
           1.9 Glossary .........................................................................................................................7
           1.10 Acknowledgments........................................................................................................7

2. Overview of the Interoperability Model.......................................................................................9

           2.1 The HomePnP Interoperability Vision ...........................................................................9
           2.2 CAL Application Layer Used Across Multiple Home Networks ................................12
                  2.2.1 Communication Protocol Independence .......................................................13
           2.3 Device and Subsystem Interaction ...............................................................................14
           2.4 HomePnP Architecture for Interoperability .................................................................14
                  2.4.1 Basic CAL Building Blocks used in HomePnP ............................................14
                  2.4.2 HomePnP Building Blocks ...........................................................................15
                  2.4.3 Interoperability ..............................................................................................18
                          2.4.3.1 Intersystem Interoperability ...........................................................18
                          2.4.3.2 Intrasubsystem Interoperation ........................................................19
                  2.4.4 State Vector Overview ..................................................................................19
                  2.4.5 Dynamic Context Numbers for Multiple Context Instances .........................20
                  2.4.6 HomePnP Zoning and Binding .....................................................................20

3. Detailed System Requirements ..................................................................................................21



                                                                        -ii-
4. Glossary .....................................................................................................................................21

5. Subsystem Definitions ...............................................................................................................22

           5.1 Current Subsystem List ................................................................................................22
           5.2 Format of Subsystem Definitions ................................................................................24
                  5.2.1 Subsystem Organization ...............................................................................24
                  5.2.2 Context Specific Information ........................................................................24
                          5.2.2.1 Special Object use by Context ......................................................24
                  5.2.3 Interconnectivity Diagrams ...........................................................................24
                          5.2.3.1 Interconnectivity Diagram Format ................................................26
                          5.2.3.2 Diagram Conventions ...................................................................27
                  5.2.4 Context Table Definition Format ..................................................................28
                          5.2.4.1 Context Numbering......................................................................28
                          5.2.4.2 Context Description Format ..........................................................28
                          5.2.4.3 Object Definition Format ..............................................................29
                          5.2.4.4 Extending Object Use ....................................................................30
                          5.2.4.5 Extending IV Use ...........................................................................30
                  5.2.5 Context IV Definitions ..................................................................................30
                          5.2.5.1 Context IV Definition Format .......................................................31
                          5.2.5.2 Using the current_value IV ...........................................................31
                  5.2.6 Using the Context Control Object.................................................................32
                          5.2.6.1 Context Control Object IV Use......................................................33
                  5.2.7 Object State Vector Usage ............................................................................33
                          5.2.7.1 Use of the Keypad Object for State Vector Generation .................33
                          5.2.7.2 Use of the List Memory Object for State Vector Reception ..........34
                  5.2.8 Context Applications Information ................................................................35

6. Contexts Groups ........................................................................................................................35

7. Context Tables ...........................................................................................................................35

8. Appendix - Recommended Practices .........................................................................................35




                                                                      -iii-
                                     FOREWORD
ISO (the International Organization for Standardization) and the IEC (the International
Electrotechnical Commission) form the specialized system for world-wide standardization.
National bodies that are members of ISO or IEC participate in the development of
International Standards through technical committees established by the respective
organization to deal with particular fields of technical activity. ISO and IEC technical
committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.




                                          -iv-
                                       INTRODUCTION

WG 1 has proposed a new work item on product interoperability. This document contains an
initial specification for interoperability. Basic definitions of interoperability modes are included.
A method of interaction among subsystem is presented. It is expected that further details will be
provided once WG 1 accepts this premise for interoperability and SC 25 accepts this work item
(currently out for ballot).




                                                 -v-
1.     Scope

In the proposal for this work item, WG 1 N 774C, the United States offered to initiate work on
interoperability by introducing the Home Plug and Play (HomePnP) specification for
consideration by WG 1. This specification was developed by the CEBus Industry Council
(CIC), a non-profit trade association, and was offered to WG 1. The goal is to provide tools for
manufacturers to develop products that can interoperate without any complex user installation
procedures. The CIC has launched the Home Plug and Play initiative to broaden the market
for home automation and to define how appliances communicate for integrated applications.

At the Tokyo meeting, WG 1 accepted this proposal to introduce HomePnP. The entire
specification for HomePnP is hundreds of pages long. Therefore, this initial submission by
the U.S. is an overview.




                                              -1-
2.     Adapting Home Plug and Play to HES

The Home Plug and Play specification was designed around EIA-721, a standard of the
Electronic Industries Alliance. EIA-721 is a specification for an Application Layer conforming
to the OSI Reference Model for Communications. The language for command, control, and
reporting in EIA-721 is Generic CAL (Common Application Language).

The proposed HES language shares features of object-orientation with Generic CAL. It is
possible to consider the proposed HES language as a subset of Generic CAL. Therefore, the
principles embodied in the HomePnP specification could be adapted for HES without difficulty.

Following are some of the key concepts in HomePnP that merit consideration for HES:

          Interoperation of subsystems in the home

          Communications among subsystems

          Communications within subsystems

          The relationship between devices and subsystems

          Binding prior to interoperation

          Loose coupling versus tight coupling

          The state vector for subsystem communications




                                              -2-
3.     Home Plug and Play Overview

Following is the outline of the portion of the Home Plug and Play specification that starts in the
next section. (numbered according to the HomePnP document). The entire HomePnP
specification is available at www.cebus.org.

HomePnP Specification Version 1.0

1 INTRODUCTION

1.1 ORIGIN
1.2 SCOPE
1.3 PURPOSE
1.4 ORGANIZATION
1.5 SPECIFICATION COMPLIANCE
1.5.1 Levels of Compliance
1.6 VERSIONS
1.6.1 Past
1.6.2 Future
1.7 NOMENCLATURE
1.8 REFERENCES
1.8.1 Base Standards
1.9 GLOSSARY
1.10 ACKNOWLEDGMENTS


2 OVERVIEW OF THE INTEROPERABILITY MODEL

2.1 THE HOMEPNP INTEROPERABILITY VISION
2.2 CAL APPLICATION LAYER USED ACROSS MULTIPLE HOME
2.2.1 Communication Protocol Independence
2.3 DEVICE AND SUBSYSTEM INTERACTION
2.4 HOMEPNP ARCHITECTURE FOR INTEROPERABILITY
2.4.1 Basic CAL Building Blocks used in HomePnP
2.4.2 HomePnP Building Blocks
2.4.3 Interoperability
2.4.4 State Vector Overview
2.4.5 Dynamic Context Numbers for Multiple Context Instances
2.4.6 HomePnP Zoning and BindingHomePnP Specification Version 1.0HomePnP Specification
Version 1.0

4 GLOSSARY

5 SUBSYSTEM DEFINITIONS


                                               -3-
5.1 CURRENT SUBSYSTEM LIST
5.2 FORMAT OF SUBSYSTEM DEFINITIONS
5.2.1 Subsystem Organization
5.2.2 Context Specific Information
5.2.3 Interconnectivity Diagrams
5.2.4 Context Table Definition Format
5.2.5 Context IV Definitions
5.2.6 Using the Context Control Object
5.2.7 Object State Vector Usage
5.2.8 Context Applications Information




                                    -4-
1.        Annex A: Overview of Home Plug and Play Specification

1.1 Origin
This specification was developed by the CEBus Industry Council (CIC), a trade organization originally
founded by manufacturers of CEBus products. The CIC expanded its charter to include the more general
problem of interoperability among home automation products using the Common Application Language
(CAL). It is this expanded mission for which this specification was written. For more information on the
CIC and its activities, contact the staff at:

                                 CEBus Industry Council
                                 4405 Massachusetts Ave.
                                 Indianapolis, IN 46218

                                 Tel 317-545-6243
                                 fax 317-545-6237
                                 www.cebus.org

1.2 Scope
This specification includes the information necessary to build interoperable CAL-based products. Device
interaction at the application level is the focus. As such, this document specifies what a device must do to
be easily installable and to interoperate with other products built to this specification. The scope does not
include details of the transport protocol below the Application layer.

1.3 Purpose
The purpose of this specification is to be the primary document that a manufacturer acquires to build
CAL-based interoperable products for the home. This is a technical specification with informative
material provided as needed to convey key concepts. The approach taken here is a top-down view of
interoperability. Because of this approach, detailed device interactions are not the focus. More attention
is paid to subsystem operation with respect to the desires of the homeowner. The fact that the approach is
top-down does not imply that the specification skimps on details. This document, in conjunction with
reference material clearly specified herein, provides all of the information necessary to build either single
products or complete subsystems.

1.4 Organization
Sections 1 and 2 serve as an introduction and overview to the Home Plug & PlayTM1 (HomePnPTM 2)
concepts and to this specification. Section 3 provides detailed requirements need to implement
HomePnP products. Section 4 is a glossary of terms. Section 5 deals with definitions needed to develop
contexts, objects and instance variables for product models. Section 6 contains text and drawings
describing both general and industry specific contexts and the way they may be interconnected. Section
7 is a series of Excel tables providing the detailed context specifications for each industry group. Section



1
    Home Plug & Play is a trademark of the CEBus Industry Council.
2
    HomePnP is a trademark of the CEBus Industry Council.

                                                    -5-
8 is an Appendix containing the Recommended Practices that are either optional or mandatory for
HomePnP devices.

1.5 Specification Compliance


1.5.1 Levels of Compliance
A description of conceptual „levels of interoperability‟ makes it easier to understand why certain
information is in this specification and other information is included by reference. The first level is called
Communication Interoperability. Devices operating at this level can successfully communicate bits from
one product to another over some medium. Communication Interoperability guarantees that a transmitted
message will arrive at the intended destination in its appropriate form. This level is necessary but not
sufficient to create a large retail market for networked consumer products - the goal of this specification.

Application Interoperability is the second level. This level is characterized by an assurance that message
content is meaningful on a device-specific basis. In other words, when a controller asks a dimmable
lighting product to ramp to full brightness, the recipient of the message interprets the sequence of bytes
to mean just that. Application Interoperability is a detailed problem unto itself for which there is not
much dependency on the details of Communication Interoperability. Both levels are necessary for
products to interact in the home.

The highest conceptual level is Scenario Interoperability. At this level, products cutting across
manufacturer and category boundaries operate in an orchestrated manner. There is no distinct line
between these levels. The concept simply helps divide the big problem - designing interoperable products
- into manageable pieces.

This document focuses on device requirements necessary to achieve Scenario and Application
Interoperability. Less emphasis is placed on Communication Interoperability because other standards are
available that address this problem. This specification is complete in that it addresses all interoperability
levels either directly or by reference to specific standards.

1.6 Versions


1.6.1 Past
This specification is based on work by various CIC technical committees and the HomePnP Task Force
specification (version 0.71). [The revision history page provides detail of the changes from previous
work.]


1.6.2 Future
The intent of this effort is to provide a useful specification as soon as possible. Version 0.9 was
available before the 1997 CIC Users Conference and functions as a provisional specification to allow
interested vendors to prototype products. Version 0.91 picked-up errors in 0.9 and adds work completed
after the Developers Conference. Additional changes found in the prototyping phase have been
incorporated in version 1.0. Versions following Version 1.0 will be required to maintain backward
compatibility with version 1.0.

A second version is planned that will include additional functions and subsystem definitions.


                                                     -6-
1.7 Nomenclature
This document uses the following notation conventions:

-   The names of CAL instance variables are in italics font with an underscore used to connect multiple
    words

-   The acronym for Home Plug & Play is HomePnP. HomePnP is a trademark of the CEBus Industry
    Council

-   References to specific context classes, context numbers and objects are capitalized

1.8 References


1.8.1 Base Standards
This specification is based on the Common Application Language found in CEBus Standard EIA 600,
Sections .81 and .82, and the application layer described in section .46.

1.9 Glossary
A glossary of terms is located in Section 4.

1.10    Acknowledgments
The CEBus Industry Council would like to thank the following companies, individuals, and organizations
that have contributed to the development of this specification.

       ABB
       Ademco
       AMP
       Caddx Controls
       Chamberlain Group
       CIC staff
       Cutler-Hammer
       Diablo Research Corporation
       Domosys Corporation
       Dr. Ken Wacks
       Full House Control
       Honeywell
       Hypertek
       IBM
       Intel
       InteliHome
       Intellon Corporation
       Interactive Media Systems


                                                   -7-
   ISO/IEC JTC 1 SC 25 WG 1 Home Electronic System
   Leviton
   Lucent Technologies
   Microsoft
   Philips
   Siemens
   Smart Corporation
   The Training Department
   Thomson Consumer Electronics
   XLSynergy




                                         -8-
2.      Overview of the Interoperability Model

2.1 The HomePnP Interoperability Vision
Interoperation of subsystems in the home--In today‟s residential market, home control is typically
achieved through stand-alone subsystems (e.g., environmental control, security, and lighting). Although
the environmental subsystem may maintain a home and away schedule, and the lighting system may have
the ability to provide a lived-in look, interoperation between these two subsystems is generally
nonexistent. Each subsystem is installed by different tradespeople with no way to be part of a larger
home control system. This is illustrated in Figure 2-1.

        No Interoperation Available Today

 Environmental                   Security              Lighting


Figure 2-1. Individual Subsystems, No Interoperation
The installation of a home control system can be highly complex. Typically, a home control system is not
installed at one time. Rather, individual subsystems (environmental, lighting, security, etc.) are installed
by separate subcontractors who have little knowledge of the entire home system design, potentially few
tools, and little training for the integration of their subsystem into a total home control system. Although
each subsystem vendor may have detailed knowledge of their own subsystem, it would be unusual for an
individual tradesperson to be cross-trained on other subsystems or on the total system operation.

Exceptions to this environment are provided for high-end customers via professionally installed home
control systems. Homeowners who desire highly customized behavior may contract with these vendors
to install and program these systems. With the lack of interoperablity standards, these professionally
installed systems typically use proprietary networks and interfaces.

One of the visions of the HomePnP specification is that stand-alone subsystems may be delivered as
today and through other distribution channels. These HomePnP subsystems have the additional feature
that they may be easily integrated into a single home control system that is harmonized with the activities
of the occupants and other subsystems present in the home. This is illustrated in Figure 2-2.

          Home PnP Subsystem Communications


 Environmental        Security              Lighting      Other
                                                        Subsystems


Figure 2-2. Interoperation Using HomePnP Subsystem Communications
With the HomePnP subsystem communications capability available on the major subsystems in the
home, standardized state information is shared among all subsystems. This allows a security subsystem,
for example, to notify all other listening subsystems that it is in an „armed‟ state. In response, a lighting
subsystem may go into a lived-in-look mode, and a windows control subsystem will not allow opening a
window without authorized user intervention.



                                                       -9-
This level of cooperation among subsystems provides a basic level of integration. It can supply benefits
to the homeowner in the form of convenience, peace of mind, and savings. Additional interoperation can
be provided using the HomePnP specification with professional installation tools.

Home Control System Upgrades--Installations of cooperating subsystems can be separated by multiple
years as the homeowner incrementally upgrades existing equipment or adds entire new subsystems. For
each subsystem within the home, the owner chooses from a variety of vendors and installers as well as
subsystem complexity and cost. For example, one homeowner may desire a simple heating subsystem
with a single setback. Another may prefer a highly sophisticated environmental control subsystem
complete with heating, air conditioning, multiple zones, air filtration, multiple setback modes, and
energy-saving features. Both of these environmental subsystems must operate consistently within the
same home control system with little or no installer reconfiguration of the existing subsystems in the
home.

To enable a mass market, HomePnP subsystems must be expandable and upgradeable. This allows the
homeowner to purchase and easily install new functionality when it becomes available. It also permits
vendors to compete in a larger market, providing unique functionality while still being able to
interoperate with both new and legacy (earlier models of HomePnP) subsystems. This is illustrated in
Figure 2-3.


                       HomePnP Subsystem Communications


     Subsystem               Subsystem            New Subsystem               Future
      Type A                  Type B                 Type C                 Subsystem

      Built to                Built to                Built to           Built to Future
     HomePnP                 HomePnP                 HomePnP             Versions of the
     Version 1.0             Version 1.0             Version 2.0         HomePnP
                                                                         Specification
Figure 2-3. Adding On to an HomePnP System
Vendor-Specific Features--Although available for the upscale market for many years, home control in
the mass market is still evolving. Many new applications, features, and devices will evolve over the next
few years. Therefore, any attempt to provide an industry specification in this market must allow for
vendor-specific adaptations and evolution of the standard itself.

To further enable the home control market, it is important for each vendor to be able to provide features
that differentiate their product in the marketplace. The HomePnP specification allows vendors to add
vendor-specific state vector information for unique functionality. This is illustrated in Figure 2-4.




                                                  -10-
                       HomePnP Subsystem Communications


Subsystem Type           Subsystem Type          Subsystem Type         Subsystem Type
 A - Vendor X             B - Vendor Y            C - Vendor Z           D - Vendor Z
      Built to                Built to          Built to HomePnP        Built to HomePnP
     HomePnP                 HomePnP            Specification plus      Specification plus
    Specification           Specification          Vendor Z‟s              Vendor Z‟s
                                                  Custom State            Custom State
                                                  Information             Information
Figure 2-4. Vendor-Specific Messages
Customization--Basic integrated behavior of these multiple subsystems can be accomplished without
requiring the used of intelligent installation tools and procedures. For highly customized homes, this
approach is not adequate. In these situations, homeowners may have extensive rules to be used for
augmenting system and subsystem behavior, and usually these rules will be specific to individual
homeowner lifestyles. These systems require extensive cross-subsystem knowledge and are often
implemented with the help of a general-purpose computer. The HomePnP vision allows for this level of
customization; however, it calls for owners of advanced homes that desire greater amounts of
customization and integration to bear the cost of custom rules and/or centralized control schemes. This
helps enable low-cost entry products for a mass market.

The same subsystems that are used for stand-alone and harmonized interaction should also be
controllable from a central system. This allows both the market and the homeowner to begin with the
subsystem essential for normal house operation and add features, customization, and integration.

The top of Figure 2-5 illustrates a customized system, showing an embedded controller and a portable
installation tool as one possible approach. This approach may be used for the professionally installed
market segment. The bottom of Figure 2-5 shows a sample configuration where a PC is part of the home
control system. The PC can host application programs to supply many types of subsystems in software, to
act as a user interface for both system and subsystem control, and to function as a gateway across
different home networks.




                                                 -11-
                    HomePnP Subsystem & Directed Communications




Environmental        Security      Lighting        Custom Logic on           Professional
                                                    an Embedded            Installation Tool
                                                      Controller

                    HomePnP Subsystem & Directed Communications



        Environmental         Security        Lighting           PC-Based
                                                            Applications, User
                                                            Interfaces, Custom
                                                             Logic, Tools, and
                                                                 Gateways

Figure 2-5. Configurations for Highly Customized Homes
The contexts and objects described in this specification contain mechanisms for both loosely coupled and
tightly or centrally controlled home control system environments. When a configuration tool is available,
messages may be routed to central controllers and/or directed communications links between subsystems
may be established. The intersubsystem connections in Figure 2-5 depict HomePnP broadcast
communications, directed communications, or both coexisting in the same HomePnP home control
system.

2.2 CAL Application Layer Used Across Multiple Home Networks
Home devices communicate over a variety of home networks. Physical media for home networks include
power line, twisted pair, IEEE 1394, coaxial cable, and wireless RF and infrared. The HomePnP vision
calls for a home control device to be able to query or control another home device using any HomePnP
network available in the home. Each network in the home serves a different aspect of the market.
HomePnP strives to provide application level communications and interoperation among subsystems
without regard to the lower level protocols.

Home control protocols can be classified in terms of the OSI communication model. In general, home
control protocols define physical, data link, and network components as well as an application-level
protocol. Physical and data link protocols are specific to physical home networks. For example, CEBus
defines its own physical and data link protocols for power line, twisted pair, coaxial cable, and other
networks. The CEBus network protocol operates on top of any CEBus physical and data link protocols.

We will refer to a set of physical, data link, and network protocols as low-level or transport-level
protocols. Low-level protocols describe how data is sent between two devices. Application-level
protocols describe home control commands and responses that can be exchanged between devices. The
HomePnP vision calls for an application protocol able to run on top of different low-level protocols.

The HomePnP specification is intended to help establish an industry standard within the application
level. The application protocol defines the content of the control messages that are exchanged between

                                                  -12-
controllers and devices. This includes the structure of the message and the control codes used within the
message. The application protocol provides all the details necessary to build a message to effect a
specific operation on a device or subsystem. This is illustrated in Figure 2-6.

The HomePnP specification takes, as a starting point, the CAL and Application layer parts of the EIA
600 standard. In a survey of existing application protocols, CAL was found to be sufficiently complete
and flexible enough to support a wide variety of devices. CAL has also been adopted by many
companies, spanning a number of different industries. CAL also has the advantage of being an open
specification, available at nominal cost to all interested parties.


                     System Guidelines
                 Context Data Structures
         CAL & Application Layer from EIA-721




             Transport Adaptation Layers
                          (as required)


 CEBus Network       IEEE 1394                  Transport
  (EIA 600.45)       Transaction                    /
                                                 Network

   CEBus Data        IEEE 1394
       Link          Data Link                     Link
  (EIA 600.41)

     CEBus           IEEE 1394
    Physical          Physical                   Physical
  (EIA 600.3x)
     EIA 600          IEEE 1394        Other Potential Comm Stacks
   Comm Stack        Comm Stack            IrDa,TCP/IP, EIB, etc.


Figure 2-6. Supporting HomePnP on Multiple Communication Stacks


2.2.1 Communication Protocol Independence
Although sections .81, .82 (CAL) and .46 (Application layer) of the EIA 600 standard has been selected
to serve as the basis for the HomePnP specification, this does not imply that the full EIA 600 protocol
stack must be used. Other communication protocol stacks can be used to pass CAL messages between
devices, as shown in Figure 2-6. Efforts have been made to create a CAL specification/standard that is
independent of the CEBus Standard. This new standard is numbered EIA 721.

Manufacturers of devices can implement a single application protocol, and depending on the media upon
which they wish to support their devices, they can select the appropriate communication stack.


                                                   -13-
Developers of controllers can use a single application layer for communicating with their devices and
support this on the appropriate communication protocol stacks, depending on the media on which those
devices are expected to exist.

2.3 Device and Subsystem Interaction
The CAL standard provides a detailed description of the building blocks (contexts and objects) used to
define home control devices. Constructs using these building blocks, to be used by product designers
wishing to provide HomePnP interoperability, are included in later sections of this specification. These
constructs support both loose and tight coupling approaches to interoperability.

2.4 HomePnP Architecture for Interoperability
The HomePnP architecture for interoperability may be described in five different layers of constructs.
The most basic layer begins with the Basic CAL building blocks. These constructs are documented in
EIA 600. They include the concepts of addressable devices, contexts, context numbers, a foundation set
of objects that contain instance variables, and a reporting mechanism. It also embraces a required set of
transport-level services. In the second layer, we add the HomePnP building blocks of a subsystem, status
and listener objects, sensors, alarms, and a subsystem for developing and sharing house mode
information. At the third level, we find the mechanisms available for creating interoperability among
HomePnP devices and subsystems. These include default binding, loose coupling, dynamic context
numbers, HomePnP broadcast of status information, and state vectors. The fourth layer describes the use
of tightly coupled objects for intra-subsystem communications. A final layer adds other elements that are
essential for interoperation. This is illustrated in Table 2-1.

Table 2-1. HomePnP Constructs

     Constructs         Used        By Elements
     HomePnP
     Building blocks provided by CAL     Devices, contexts, context numbers, objects, instance
                                         variables, CAL reporting, HomePnP broadcast and
                                         directed messaging
     Building blocks       used     by   Subsystems, status & listener objects, sensors, alarms,
     HomePnP                             house mode.
     Interoperability constructs for     Loose coupling, dynamic context numbers, broadcast
     subsystem       to    subsystem     of status information, state vectors, automatic binding
     (Intersubsystem) communications     and manual binding
     Interoperability constructs for     Tight coupling, installation tools
     tightly coupled (Intrasubsystem)
     communications
     Other requirements essential for    Start-up,    configuration, resource    management,
     interoperation                      heartbeat messages, authentication and encryption and
                                         transport requirements




2.4.1 Basic CAL Building Blocks used in HomePnP
Using the CAL building blocks of contexts, objects, and instance variables, various levels of products
may be built. These may be sensors or actuators, single-function devices, or devices that contain many

                                                  -14-
functions. To interoperate in a Home Plug & Play manner with other CAL entities, these products need to
be designed using the CAL standard and with the contexts, objects, and instance variables specified in
this document.

The EIA 600.81 (CAL) standard (section 8) provides a standard set of object definitions. Multiple of
these objects may be combined in contexts to be used for specific functions. Multiple contexts may be
provided in one product to perform the desired combinations of functions.

To help clarify these concepts the following definitions are provided:

object - A CAL term used to define a single control function within a context. For example, an Audio
context contains a Gain Object.

context - A group of one or more CAL objects representing a common device function. Several of these
contexts may be present in a single device.

device - A mechanism that exposes state and control variables through a home network using the CAL
protocol. Devices might be stand-alone hardware devices or might be implemented in software on a PC.
A device is a container for a set of CAL contexts that collectively receive messages addressed to the
same transport layer address. This address may be a unique system or unit address, one of many group
addresses, or a broadcast address.


2.4.2 HomePnP Building Blocks
The first HomePnP building block to consider is the subsystem construct. A subsystem is a device that
manages a major set of functions within a home control system. Examples of subsystems include:
security system, lighting system, environmental control system, home entertainment system. A subsystem
contains a set of CAL contexts that collectively are assigned responsibility for a portion of a control
region. A subsystem typically consists of a subsystem controller and other hidden or exposed functions.
Exposed functions are visible to other subsystems and devices on the network.

HomePnP subsystems may reside in a single device or may be spread over many devices. A device may
contain all or parts of multiple subsystems. A subsystem may be packaged in multiple devices. This is
illustrated in Figure 2-7, Figure 2-8, and Figure 2-9. For example, a user interface on a security
subsystem may be packaged as a wall panel, whereas a security system controller may be packaged for
mounting in a utility area for connection to a large number of door and window sensors. Both devices
may be visible on a home network and still be part of the same subsystem. The information flow
between multiple devices such as these may be extensive and detailed. Depending on the design, this
information may or may not need to be shared with other subsystems. Also, depending on the design, the
binding of these types of devices may or may not require a professional installation tool.

.




                                                   -15-
        Device




       Context

                              Subsystem


Figure 2-7. One HomePnP Subsystem per CAL Device

       Device 1                Device 2




       Context                 Context




                          Subsystem

Figure 2-8. One Subsystem May Span Several Devices

      Device 1               Device 2               Device 3
       Context                Context                Context


                              Context                Context
      Context



      Context                Context                Context


Figure 2-9. Illustration of Six Subsystems Contained in Three Devices
One reason for implementing subsystems is to enable lower cost products. Few low-cost devices (such as
sensors) can bear the cost of a full network connection in today‟s market. The subsystem concept allows
multiple functions to be aggregated in a single network connection. Subsystems may include object
models of many types of home control functions. An example could be an outdoor temperature sensor
that is directly wired to an environmental controller. The environmental controller may share this
outdoor temperature with other HomePnP subsystems by providing a context that contains an object
model of the sensor.

Of course, the outdoor temperature sensor example above could also be connected to one of the home
networks with its own transport address. The object model is the same for both cases.

Subsystems may also contain status and state information for its control region that may be shared with
other subsystems. For example, a security subsystem may share its arm/disarm state with a lighting
subsystem so that the lighting subsystem could provide exit lighting and a lived-in-look function. When a


                                                  -16-
HomePnP product implements status or state information provided by this specification it will be able to
interoperate with other HomePnP products listening to the same information.

Standard Modeling Construct--Home Plug & Play specifies sets of CAL constructs in which
subsystems can publish their status, listen to other subsystem‟s status, and request status changes in other
subsystems. This is accomplished both by using objects developed by industry groups and by using a
new vector notation. This construct is intended for replication throughout HomePnP device construction
and is necessary for exchanging interoperable HomePnP vectors. Definitions of these object types
follow:

     Status objects (also called Providers) are any objects that use the CAL reporting mechanism to
      convey current state or parameter information and whose report header and destination address is
      configured to bind with a listener object.

     Listener objects are objects that receive reports from status objects of one context and have logic
      to modify the status in objects of other associated contexts based on the value(s) received. A
      listener object does not report.

     Request objects are any objects that send requests to change the value of a status object. A
      request object may change the value of a status object by sending a request.

Shared sensors are devices that contain a sensor context designed to share the sensor information with
subsystems and devices. This is illustrated in Figure 2-10.


       Device 1                           Device 2
   Status Context                     Listening Context




   Shared Sensor




                                         Device 3

                                      Listening Context




Figure 2-10. Illustration of a Shared Sensor Sending Information to Two Listening Contexts
When a sensor context reports to the HomePnP broadcast destination, the information is delivered to any
device that wishes to listen. To receive the sensor information the listening device must implement a
context containing a sensor listening object. If multiple sensors of the same type are available in the
home, a listening context may decide to listen to a particular sensor by adjusting its context number to
match that of the desired sensor.



                                                          -17-
HomePnP Alarms and Trouble Reporting--Another HomePnP building block are alarms and trouble
reports. Any control region of a home may develop alarms and trouble information. This building block
provides a common way to share this information with other subsystems in the home. Note that
HomePnP alarms are not intended to be compliant with approval bodies‟ requirements and therefore must
not be relied upon to support alarms in critical life-safety applications. Strict building code-type
requirements must be realized outside of HomePnP concepts by the subsystem responsible for the critical
life-safety functions.

House Mode Context--A feature of the HomePnP subsystem communications interaction is a new
context class for expressing house mode. This context provides a method for representing the major
activities of the home occupants to all HomePnP subsystems. By receiving HomePnP broadcast
information about occupancy and occupant activities, all listening subsystems can adjust their behavior
per their own design. This provides a basic level of integration and harmonization in the simplest of
home control systems.


2.4.3 Interoperability
Subsystems may wish to interoperate within their own subsystem or with other subsystems. The CAL
context model supports interoperation between contexts within a subsystem (intrasubsystem) and across
subsystem or subsystems (intersubsystem). The concept is illustrated in Figure 2-11.


 Subsystem                      Subsystem                 Subsystem
               STATUS                         STATUS
  Context X               Context A                        Context Y       HPnP
              REQUEST                        REQUEST
                                                                           Loose coupling
     Interproduct interoperability

                           Context B        Context C

                          Intraproduct interoperability   Tight coupling

                           Context D        Context E




Figure 2-11. The basic model of inter and intra subsystem interoperability.
Each industry context group in this document (Sections 5 and 6) contains the necessary contexts for
inter- and intraoperation of almost all types of equipment and/or functions within a subsystem. This
provides the details for subsystem component operation to be handled within the subsystem and for high-
level subsystem operation to be controlled and monitored by other subsystems.

2.4.3.1 Intersystem Interoperability
The loose coupling and default binding aspects of HomePnP, explained below, deal with intersubsystem
interoperability by providing contexts within each subsystem that are loosely coupled to contexts in other
subsystems for exchange of general request, status, and state information.

Each subsystem deals with intersubsystem communications by providing one or more contexts that
specifically provide status and possibly control information to and from one or more contexts in other
industry groups. This allows monitoring and control of subsystems on a whole-house level and is the
basis for the majority of HomePnP operation.


                                                            -18-
Default Binding--A key mechanism for interoperation among HomePnP products uses CAL‟s reporting
mechanism. Parameters and state change information to be shared with other products is reported when
the information changes by broadcasting to predetermined context and object types. This default report
mechanism is supplied in all HomePnP products, allowing entry-level interoperability without
customization. Professional installers may modify the reporting mechanisms as desired using CAL
commands in cases where CAL reporting is used as the reporting mechanism. Default binding is also
discussed in Section 3.2.2.2.1.

Loose Coupling--Status information from status objects, provided by default binding, is sent to all other
interested HomePnP subsystems in the home. The status object need not be aware of what other
subsystems are installed and listening. Interested peer subsystems can listen to information and modify
their own behavior per their own unique designs. This loose coupling mechanism allows HomePnP
products to be incrementally installed by the homeowner. It also allows vendors to design their
interoperable HomePnP products without having detailed knowledge of other vendor‟s products.

Loose coupling requires that the HomePnP broadcast address be used as the destination address of a CAL
reporting object in the transmitting node. The distinction between destinations is made based on the
transmitted CAL Context Class, Context Numbers, and Object Identifiers. A listener may subscribe to
this information by instantiating the correct context and object.

2.4.3.2 Intrasubsystem Interoperation
In addition to the loose coupling concepts discussed above, HomePnP systems may employ reports to
specific objects when appropriate. In these cases, the sender needs to know not only the context, object,
and instance variable IDs but, also the device address of the receiver. This is some times called tight
coupling and can be very useful for reducing HomePnP broadcast traffic on a network, and for messages
that require immediate acknowledgment.

Using tight coupling, a sending device may transmit its information to a specific receiving device. This
requires an installation routine in the transmitter to acquire an address (unit or group) of the destination
device. Tight coupling requires that a nonbroadcast address be used as the destination address of the
CAL reporting object in the transmitting node.

This document also includes the necessary context model information within each subsystem to provide
for intrasubsystem interoperability. Intrasubsystem communication generally relies on tight coupling
between contexts because messages are specific to devices working together within the subsystem. This
type of communication typically deals with status and control from, for example, the thermostat to the
heating/cooling equipment, the light switch to the light, the security sensor to the security panel, and so
on.


2.4.4 State Vector Overview
A major mechanism for HomePnP interoperablity is the state vector. This concept allows high-level state
information to be shared by each subsystem so that other subsystems may listen as desired. A subsystem
interested in listening to state information from its peers has only to instantiate an appropriate listener
object to receive this state information. HomePnP specifies that high-level state information provided be
abstracted so that listening subsystems need not understand all the details of how a particular subsystem
is constructed. As an example, it is desirable to know that an environmental control is operating in a
heating mode without knowing how heat is delivered, whether energy is currently being expended, or the
energy source. State vectors are discussed in Section 3.6


                                                   -19-
To allow for evolution in the type of state information that can be broadcast and received, HomePnP
specifies extensible hierarchical state vectors. The vectors are hierarchical in that each succeeding level
provides specialization of the previous level. Depending on the designs of these state vectors, listeners of
these subsystems can interpret them only to the level understood or desired. For example, a state vector
value describing a user‟s desire for how a home should be operating might be „Occupied.High Activity,‟
„Unoccupied.<1hour‟ or „Unoccupied.Vacation.‟ The top level vector component values of „Occupied‟
or „Unoccupied,‟ could stand alone, but the further specialization of „High Activity,‟ „<1 hour,‟ and
„Vacation‟ adds a more precise and useful interpretation for subsystems that can provide more
specialized behavior.

State vectors are broadcast to the HomePnP broadcast destination address so that all interested
subsystems can listen. The state vectors communicated for each subsystem type are different and are
specified in state vector tables found in later sections of this specification. The exact meaning of the
vectors is subsystem specific and determined by industry working groups.


2.4.5 Dynamic Context Numbers for Multiple Context Instances
Large homes sometimes require more than a single subsystem of the same type; for example, two or three
environmental subsystems may be required to heat or cool a large home. In HomePnP, this is referred to
as having multiple instances of a subsystem. HomePnP contexts contain an instance variable that is used
to enumerate these instances. This instance variable is in turn used to establish the context number of a
context. In HomePnP systems, these Context Numbers are established at installation time rather than be
a static value set by the manufacturer and are used to help assist in binding status, listener and requestor
objects.

This technique is referred to as dynamic Context Numbers. Listening objects decide which status objects
to listen to by adjusting their Context Numbers to match that of the desired source. If a physical
association is required, listeners will decide which Context Number to use based on information related
to physical locations. Dynamic Context Numbers are described in more detail in Section 3.5.


2.4.6 HomePnP Zoning and Binding
A HomePnP zone is a physical or logical portion of a control region. To accomplish zoning, various
methods for logical and physical association are required. In HomePnP, simple logical association is
accomplished with standard CAL constructs, including Context classes, Context numbers, Object IDs,
and Instance variable IDs. The dynamic Context Number technique described above plays a major roll in
establishing these associations.

The HomePnP configuration process provides automatic binding of objects in situations that are not
ambiguous (only one choice for a connection). In installations where multiple opportunities for
connections exist a manual binding process is needed. A manual binding process is also provided as part
of this specification.

In addition to the use of dynamic Context Numbers some low-cost devices (lights and light modules) may
rely on the use of group addresses to form associations. HomePnP also supports this technique.

Another construct provided in some HomePnP subsystems is based on a type instance variable. This
construct further differentiates context classes and allows listeners to automatically find an appropriate
status provider. The type IV is discussed in Section 3.18.



                                                   -20-
3.      Detailed System Requirements

[This section has been omitted from this overview.]


4.      Glossary
HomePnP broadcast

Data transmitted to the HomePnP broadcast address is received by all nodes which are loose coupling
clients (see Loose Coupling). The address used is FF FF hex.

House Broadcast

Data transmitted to the house broadcast address is received by all nodes in a single house code. This
address has a non-zero house code and zero for the unit address.

Global Broadcast

Data transmitted to the global broadcast address is received by all nodes on the network. This address
has zero for both the house code and the unit address.

Loose Coupling

Loose coupling is the mechanism by which a sending device may transmit its information to a receiving
device without knowing the specific address of the destination. Loose coupling requires that the
HomePnP broadcast address is used as the destination address of a CAL reporting object in the
transmitting node. The distinction between destinations is made based on the transmitted context and
object numbers. A listener may "subscribe" to this information by instantiating the correct context and
object.

Tight Coupling

Tight coupling is the mechanism by which a sending device may transmit its information to a specific
receiving device. This requires an installation routine in the transmitter to acquire an address (unit or
group) of the destination device. Tight coupling requires that a non-broadcast address be used as the
destination address of the CAL reporting object in the transmitting node.

Direct Application Messaging

Direct Application Messaging is the mechanism by which a sending device may transmit information to a
receiver without using reporting. This method is used when a packet transmission request originates with
the user element of the Application layer.

System Address (House Code)

EIA 600 intermixes the use of the terms System Address and House Code. These terms are synonymous.
This specification uses the term System Address.




                                                  -21-
5.     Subsystem Definitions
This section of the document provides a detailed description of the various CAL contexts organized by
industry groups or subsystems. Each subsystem provides a complete list of all the contexts in that
subsystem as well as the necessary support documentation to use the contexts for interoperable operation
across industry groups. The introductory material in section 5.2 describes how the subsystems are
documented

5.1 Current Subsystem List
The following is a list of the existing CEBus contexts as of the data of the revision of this document.
The contexts are organized by industry group and listed by context class/context name.

GENERAL                                                 COMPUTER/HOME OFFICE (in development)
00   Universal                                          38-3F Computer/Home Office
02   User Interface
04   Data Channel                                       HVAC
     Time                                               40      Environmental Zone
0E   Time Monitor                                       41      Environmental Sensor
0F   House Mode                                         42      Environmental Sensor Status
                                                        43      Environmental Zone Request
AUDIO/VIDEO                                             44      Environmental Zone Equipment
10    Audio Amp                                         45      Environmental Zone Status
11    Medium Transport                                  46      Humidification Zone Request
12    Tuner                                             47      Humidification Zone
13    Video Display                                     48      Humidification Zone Equipment
14    Audio Equalizer
15    Camera                                            UTILITY
17    Switch                                            50    Utility Metering
18    A/V System                                        51    Electric Monitor
19    A/V System Control                                52    Electric Status
                                                        53    Gas Monitor
LIGHTING                                                54    Gas Status
20    Light Sensor                                      55    Water Monitor
21    Light                                             56    Water Status
22    Lighting Scene                                    57    Service Monitor
23    Light Sensor Status                               58    Service Status
24    Lighting Scene Request                            5A    Load Request
25    Lighting Scene Status                             5B    Load
                                                        5C    Energy Management Request
COMMUNICATIONS (in development)                         5D    Energy Management
30-37 Telecom/Intercom




                                                 -22-
SECURITY
60    Security Sensor
61    Security Zone
62    Security Partition
63    Security Partition Status
64    Alarm Status
65    Alarm
66    Security Partition Request
67    Security Sensor Status
68    Security Zone Status
69    Trouble
6!    Trouble Status

APPLIANCE
70    Washer
72    Water heating
73    Dryer
74    Refrigerator/Freezer
75    Range
76    Oven
77    Coffee Maker

CONVENIENCE
80   Window
81   Window control
82   Door/gate
83   Door/gate control
84   Pool/Spa
85   Pool/Spa control
86   Bath
88   Fountain
8A   Lift




                                   -23-
5.2 Format of Subsystem Definitions


5.2.1 Subsystem Organization
Contexts are organized into groups, or „subsystems‟ that apply to specific industry categories. Each
context group is presented in a separate section of this document and contains the following information.

   A description of each context class in the group.

   Any specific information about the group that is unique to the use of the group.

   Any Interconnectivity diagrams for the contexts in the group.

   The complete object tables and IV definitions for each context in the group including any state vector
    tables.

   Any application notes for the context group.


5.2.2 Context Specific Information
5.2.2.1 Special Object use by Context
     In many cases, the use of one or more objects in a context requires additional application specific
     information such as the use of non-standard IVs, or unique values of IVs. This information is given
     for each context where required.


5.2.3 Interconnectivity Diagrams
A set of Interconnectivity diagrams is given for each context group. The diagrams provide a „schematic‟
diagram of how the contexts in a group are intended to be used together for inter and intra context
interoperability. The diagrams provide a context group organization overview.

In many cases, a context may not be associated with a context Interconnectivity diagram. This may be
because the context work within the category is not complete, or a binding relation ship with another
context has not been established. There are cases where all the objects in a context are „read-only‟, i.e.,
they do not report to any other specific objects in other contexts nor are they „reported to‟.

Context diagrams are a visual representation of the objects in a context using a symbol representation of
each object. The symbols used to represent all of the CAL objects are given in the following Figure 5-1.




                                                   -24-
Figure 5-1. Icon List of All CAL Objects Used in Context Interconnectivity Diagrams
Each object is depicted using an object class icon and a network category symbol. The symbols in the
figure show the object name and its hexadecimal class number. Figure 5-2 shows how to interpret the
symbol shape. The icon indicates the object class (analog control, binary switch, motor, etc.) and the
network object category.


                         Object Class
                         Object network category


           Object name

Figure 5-2 . Object Icon Format




                                                -25-
Objects can be divided into three general network message categories: network output, network input,
and network input/output. Object network categories define whether the object is primarily a sender of
messages, a receiver of messages, or both. Objects are represented by one of three symbols
corresponding to the network type.




Network output objects generate messages. The current_value IV of these objects is read-only and the
object is used to originate report messages. Typical network output objects include the binary sensor,
analog sensor, and multi-position sensor. Messages are generated when the object current_value changes
by some amount. Network output objects are referred to in this document as either request, status, or
network output depending on how they are used in a context.




Network input objects receive messages. The object‟s current_value IV can be set from an incoming
message, but it does not generate a message. Typical network input objects include the Meter, Display,
and Synthesizer/Tuner. Network input objects are referred to in this document as either status, listener
or network input. depending on how they are used in a context.




Network Input/Output Objects can receive or send messages, or both depending on the application. The
current_value IV is R/W and can be set from an incoming message. Messages can also be sent based on
local current_value changes. The change may be the result of an incoming message, or a local
application change. Typical Network I/O Objects are the analog control, binary switch, and multi-
position switch. Network input/output objects are referred to in this document as either status, listener,
or network input/output, depending on how they are used in a context.

All of the CAL network input/output category objects shown in Figure 5-1 (Binary Switch, Analog
Control, Multi-position Switch, etc.) can be used as network input objects if the CAL reporting capability
of the object is not used in a particular context application. When these objects are used as input only,
they are typically drawn using a network input category symbol.

5.2.3.1 Interconnectivity Diagram Format
 Figure 5-3 is an example context Interconnectivity diagram showing a portion of two contexts in the
security industry group. An Interconnectivity diagram is intended to show the implied „binding‟ between
objects at a context level. The diagram shows the objects in each context in the order they are defined in
the context with the object number. Note that while the object numbers are usually sequential they may
not be in a particular context. They are always drawn in increasing order. The name of the object used in
the context is given in the object symbol.

The lines drawn between objects in one context to objects in other contexts indicate the intended
„binding‟ between the objects. The output of network output or network input/output objects is always
sent to the input of a network input or network input/output object in another context. The type of line


                                                  -26-
indicates the most common type of binding: a dashed line indicates loose coupling (messages sent to the
HomePnP broadcast address), a solid line indicates tight coupling.




Figure 5-3. Example context Interconnectivity diagram showing context 66 and a portion of
context 62. The diagram shows object binding between the two contexts in the security industry
group.
Objects which do not have a predefined binding relationship are shown without a line entering or leaving
the object. These objects are always read or written by application specific messages.

5.2.3.2 Diagram Conventions
The Context Control Object in each context is always implied and is not shown in the diagram. Object
numbering is usually sequential from top to bottom in the diagram. The first object at the top of the
context is usually object 02, the second is object 03, etc. Gaps in object numbering may occur where
revisions have been made. If an object is removed, objects are not renumbered.

If an object is required, its name is bold and is preceded with an asterisk.

The output of an object in one context may bind to an object in multiple instances of another context.
Likewise, the input to an object may bind to an object in multiple instances of the same context.




                                                    -27-
5.2.4 Context Table Definition Format
The context definition tables given in each industry group section provide a detailed list of the objects in
each context and the IV use in each object.

A context consists of one or more object definitions grouped to form a necessary and complete set of
controls for a specific functional subunit of a product class. Whereas objects define generic control
functions, a context is intended to model a more specific operating function of products found in the
home. Each context model is designed to be generic in the description of the function but contains all
objects necessary to reasonably handle all levels of complexity of the function.

A device implementing CAL will always contain one or more contexts necessary to completely define
the functionality the manufacturer has implemented in the product, and made available for control or
monitoring by other products. Not all functions of a product need be accessible via a CAL context.

5.2.4.1 Context Numbering
Each context in a device implementing CAL is addressed by a unique context ID. The context ID
consists of an optional context number (A0 - DE hex preceded by an optional number of DF hex, which
is a context number extension) followed by a context class ID (00 - 9E hex preceded by an optional
number of 9F hex, which is a context class extension). The context number is used as part of the context
identifier (ID) if there is more than one context of the same class in the house (within the same system
address). The context number identifies the particular context; A0 being the first context, A1 the second,
and so on. If no context number is supplied in the message, and multiple instances of the context class
exist within a device, the first instance of the context class is assumed. The context class identifies the
context type and is always sent (as well as an object number) as part of any CAL command. Both the
context number and context class range can be extended by the use of one or more extension bytes
proceeding the number or class (refer to Section 4.1 of the CAL Specification).

A special context number, DE hex, is used to identify all contexts of the addressed class within a device.
This context number could be used, for example, to send a message to all lighting contexts within a
device. If the context number DE is followed by 00 (the context class of the Universal Context), the
message is applied to all contexts within a device.

5.2.4.2 Context Description Format
Each context table description provided in this document consists of a header that defines the name of the
context, and the context class number (in hex), followed by a brief description of the general intended
use of the context within the industry group.




                                                   -28-
   Name of Context                                                                      Context Class (hex)


                  A UDIO                                                                                          10
                          The Audio context contains necessary objects for the majority of audio amplifier
      General             functions. The basic context usage assumes one or two channels but additional objects
 description of           are provided for four channel and surround sound applications. Intended for A/V
       context            as well as non-A/V product use.

                   01     Context Co ntrol Obje ct                     (02) Context control
                          The context control object for this context.
                           IV R/W Type Name                               Con text Fun ction
                           o   R    d object_list                         list of objects u sed in con text


Figure 5-4 . Example Context Description Header
The context definition then lists all of the objects defined in the context



                  Name of object
                   in the context               Object class number and name
       Number of object
     (hex) in the context


                                     09   Tre ble Control                             (07) Analog Control
           Use of object                  Treble control of the amplifier (if available).
           in the context
                                           IV   R/W Type Name                         Context Function
                     IV identifier         U     R   n units_of_meas ure              8 = percent full scale
      Storage class (Read only,             S    R   n step_s ize                     Control value increment
                 Read/Writable)             r    R   n step_rate
  Specific IV use or value range           N     R   n min_value                      0 = minimum treble
      w hen used in this context           M     R   n max_value                      100 = maximum treble
                                           D     R   n default_falue                  50 = default treble
                    IV data type           C    R/W n current_value                   Current treble setting
                                            P    R   n previous _value
                        IV name             R   R/W d reporting_condition
                                           H    R/W d report_header
                                           A    R/W d report_address

Figure 5-5. Format of Object Definition

5.2.4.3 Object Definition Format
The format of the object definition is shown in Figure 5-5. The object number, name, and class
definition is given on the top line. Objects are numbered sequentially beginning with object 01. The
object number is given in hexadecimal. The object class number and class name are the same as those
used in the EIA-600 object definitions.


                                                            -29-
A brief description of the use of the object in the context is given with any restrictions or special use
information. This is followed by a listing of all IVs defined for the object class in EIA-600. The IV
label, storage class, data type, and name are taken directly from EIA-600. Any IV label and name in bold
type represents a required IV in the context. Required means that if the object is used, the IVs must be
supported per the requirements of EIA-600 for the data type.

The data type is either n = numeric, c = character, d = data, or b = Boolean. The storage class is either R
= Read only, W = Write only, or R/W = Read/Writable. A read-only IV can be made read/writable for
specific applications. The length of a type data IV element is determined from EIA-721.1, section 8.2,
“Object Specification Sheets.”

The Context Function column gives any specific value or use of the IV in the context. Additional values
and IV usage may be provided in the IV Definition section for the context if one is provided. While any
value or range given is not mandatory, it is recommended to insure interoperability since this is the value
that will be used by most implementers.

Context tables shown in section 7, Context Tables, indicate IVs required by EIA-721 in bold face type in
the IV label and name columns. A bullet symbol, “”, to the left of the IV label column indicates IVs
required for HomePnP compliant devices.

Some IV properties found in the standard context sheets can be modified according to the needs of the
manufacturer, except if changing a property compromises network interoperability. For example, a
utility Time provider context (context class 05, object #2) can implement its current_time IV with the
READ-ONLY (R) property instead of the proposed R/W property, so the time of the provider cannot be
changed by another device on the network.

5.2.4.4 Extending Object Use
Each context definition contains all of the objects that should be necessary to define the operation of the
context in any application. A manufacturer may add additional objects as necessary to define unique
control or sensing functions for a particular product. Any additional objects used by a manufacturer
should be numbered in accordance with the CAL specification in the range of 30 - 3E hex. This
numbering prevents possible conflicts as possible additional objects are added to the context class.

5.2.4.5 Extending IV Use
It is possible to add one or more IVs to an object when it is instantiated in a context to extend the
functionality of the object for a particular application. The Light Level Control object in the Light
Context is a typical example (see the lighting contexts in Section 6). Added IVs always use single lower
case letters.


5.2.5 Context IV Definitions
When the use of a particular set of IVs in a context can be defined to benefit interoperability, the
predefined values are given in an IV Definition page associated with the context.




                                                   -30-
5.2.5.1 Context IV Definition Format
The context IV Definition pages associated with a context contain a description of the use of
selected IVs in several objects used in the context that require a more detailed description of IV
values.
The typical format of the IV definitions for an object is shown in Figure 5-6. The object number,
name, and class definition is given on the top line and is the same as the corresponding object in
the context definition.
  Object header from
  corresponding context

                  05    Input Mode Switch
                        IV Name                   Value(C)   Value(F)          Description
 IV identifier and      C   current_position         0        OFF              off
            name         F Function_of _positions    1       MONO              mono
 Numeric values of                                   2      STERE              stereo
 current_position (C)                                3      O
                                                           RSTERE              reverse stereo
 Corresponding string values                         4     O LEFT              left only
 of function_of_positions (F)                        5       RIGHT             right only
      Description of the position

Figure 5-6. IV Definition Format
This is followed by a list of the IVs to be defined in the object. The majority of definitions are for the
value of the current_position and function_of_positions IV in multi-position switch and sensor objects.
Three columns define the IV values: the numeric value that the current_value (“C”) can assume, the
corresponding ASCII characters used to define the function_of_positions for that value, and a brief
explanation of the function of the position value. Note that the list of predefined IV values does not
preclude the use of additional values.

5.2.5.2 Using the current_value IV
The current_value “C” (or its equivalent such as current_position or current_level) is usually the
only required IV in each object. When the current value is represented by the current_position in
the multi_position switch or multi_position sensor, its value, and the corresponding
function_of_positions IV value, is given in detail whenever possible. Knowing the function of
each position is essential for product interoperability.
The list of values for the current_position is neither mandatory nor all inclusive. No product is
assumed to use or implement all values. Likewise, additional values may be used by a
manufacturer for product specific functions not listed. The position value used for additional
functions should be outside the range of the values listed.




                                                  -31-
5.2.6 Using the Context Control Object
The Context Control Object has been enhanced for HomePnP applications to assist in device
identification, configuration, and binding. All occurrences of the Context Control object in each
subsystem definition has a set of additional IVs (including “o”) that may be used for
configuration information about the context where the object is used.



01    Context Control Object                         (02) Context control

      The context control object for this context.

      IV    R/W Type Name                            Context Function

      o     R     d    object_list                   list of objects used in context

      z     R/W n      instance                      instance number of context

      f     R/W n      context_configured            If this node context is a status
                                                     provider

                                                     0= unconfigured (out-of-box)

                                                     1 = configured

                                                     If this node is a listener or a
                                                     requestor

                                                     0= unbound-out-of-box

                                                     1= bound

                                                     2= unbound-needs-manual-binding

                                                     3=         unbound-manual-binding-
                                                     enabled

      t     R     c    type                          type identifier of context

      n     R/W c      name_location                 ASCII name or location of context

      l     R     n    local_instance                Internal number of the context




                                               -32-
5.2.6.1 Context Control Object IV Use
The “z” IV is used to identify the network context instance, or number, of this context. When a
product is first installed “z” is 0 for the first context, “1” for the second context, etc. During
network configuration, the value of “z” may be changed based on the presence of other contexts
on the network of the same class. See section 3.X for an explanation of resource hailing and
subscription.
If the context is used as a status provider the “f” IV is used to indicate the context is configured
and has acquired all necessary instance numbers by resource hailing (or other methods). If
implemented and f = 0 no CAL reporting will occur from objects in this context. If f = 0, all
CAL reporting is enabled.
If the context is used as a listener or requestor and may require manual binding, the “f” IV is used
to indicate the manual binding state. This is described in section 3.8.3.5.
The “t” IV is used to identify a context type, typically used for a context that provides a resource
such as time, temperature, etc. The value of “t” is defined in the context tables (section 6) for
each context where it is used.
The “n” IV is a text string containing a name or location ASCII string input from some
initialization application (24 bytes max). The string typically contains a physical location in the
home such as „living room‟, or „master bedroom‟, or it may contain a zone name such as
„upstairs‟.
“l” (lower case L) is used to number instances of the same context in a product. The first
instance of a context is “1”, the second “2”, etc. this IV allows identification of a specific
function of a product with a specific instance of a context. This IV is typically used in devices
that may have more than one sensor or more than one switch.
None of these IVs are required.

5.2.7 Object State Vector Usage
Many contexts in each industry subsystem group make use of multi-byte character strings between
objects to encapsulate hierarchically organized context state information in one message. This section
defines the use of Keypad and List Memory objects for the exchange of these data „vectors‟. A vector is
an object IV value that consists of more than one byte. All bytes of the vector are transmitted together.
Since the multi-byte value typically represents more than one status value from a context, it is typically
referred to as a „state vector‟ (see Section 3). The content of the vectors are subsystem specific and
determined by industry working groups.

5.2.7.1 Use of the Keypad Object for State Vector Generation
When the Keypad Object is used for state vector generation, the object IVs are used as shown in the
following object table.



                                                  -33-
No.    Object name                                      (14) Keypad

       Description of object use in the context




       IV    R/W Type Name                              Context Function

       C     R     c     current_key                    Used to store the output state vector

       k     R/W b       new_key                        Not used

       P     R     c     previous_key                   Previous value of C

       R     R/W d       reporting_condition            C <delta> 0

       H     R/W d       report_header                  <context #><contx. class> <object>
                                                        setValue 'I' f5
       A     R/W d       report_address                 SA, HB or NA


The current value is used to store a character string representing the state vector values. The
reporting_condition is typically set to report any change in C. If the object uses loose coupling, the
report address is typically the System address, with the system HomePnP broadcast address (HB). If the
object uses tight coupling, the report address is a node (or group) address (NA).

5.2.7.2 Use of the List Memory Object for State Vector Reception
When the List Memory Object is used to receive state vectors, the object IVs are used as shown in the
following object table.

No.    Object name                                      (15) List Memory

       Description of the use of the object in the context.




       IV    R/W Type Name                              Context Function

       a     R     n     length_of_list                 Usually set to 1 (record)

       b     R     n     Length_of_item                 Maximum length of state vector

       C     R/W n       current_item                   Pointer to ‘l', always set to 0


                                                    -34-
       l     R/W c      item_list                     The received state vector



The only required IVs are “C” and “l” (lower case L). “C” is usually set to 0 to always point to the one
and only record in “l” (the received state vector). However, it is possible to implement a List Memory
object that stores several received vectors by increasing the length of the list and auto-incrementing C
(perhaps in a wrap-around loop) to point to the next record in the item_list.


5.2.8 Context Applications Information
Specific context application information may be given in each context group to provide examples to
better illustrate the use of the contexts. This information is industry group specific and may deal with
specific product operation found in the industry group or specific operating practices for the group.
Some contexts are custom designed to meet the requirements of other existing protocols or interface
requirements and require specific application use information.


6.      Contexts Groups

[This section has been omitted from this overview.]


7.      Context Tables

[This section has been omitted from this overview.]


8.      Appendix - Recommended Practices

[This section has been omitted from this overview.]




                                                 -35-