After what seemed to some of us an eternity, the finish line was recently crossed in the CEBus-standard-development marathon. Those who set off at the sound of the starting gun years ago never imagined it would take so much effort and dedication to arrive at this point. Nor could they have imagined the wide range of personalities that would be making contributions, both great and small, necessary to reach the desired goal. On March 10th , the Consumer Electronic Manufacturers Association (CEMA), a sector of the Electronics Industries Association (EIA), announced the publication of the first 12 standards in the ANSI/EIA-600 series; thus establishing the CEBus specification as an official ANSI standard. Interested parties can now order the EIA-600 series (CEBus Specification) through Global Engineering Documents, 800-854-7179 or .

One of the hallmarks of the CEBus Standard is the Common Application Language (CAL) defined in EIA 600.81. This document presents the language and an object-oriented model of interoperability between diverse and otherwise unrelated products that constitute the home environment. A generic version of CAL is being developed so that products designed for other protocol stacks can place this protocol-independent CAL element within the application layer of their new and existing products and thereby expand the product’s features and functionality.

AirVac Pers 2400a
Having been immersed in development and implementation of CAL for the past 4 years, it seemed a natural step for me to collect my experiences together and see if I could successfully boil them down to a sort of ‘CAL primer’ for those of you who are new to this language. As I present this introduction to using CAL to provide interoperability between products in the home, allow me to first establish in your thoughts an initial mental picture of a home network that we will reference throughout the remainder of this article. The best place to start is your home and a set of products you currently own. For simplicity, we will limit this product set to any device that connects to the 120 VAC outlets in the home for power. By doing so, we can then agree to accept these devices as being interconnected by the house wiring tied to the single electric service provided to your home. We will enhance the products in our mental picture with the CEBus protocol so that we can assume that they all can send and receive CAL commands. Now that you have this home network defined, take a moment to realize that your iron, security system, garage-door opener, front porch light, ceiling fan, television and master bedroom alarm clock radio can now freely pass information back and forth amongst themselves. Part of our challenge is to identify what (if anything) one of these devices might want to ‘say’ to the others and why the others would care to ‘listen’.

The CAL model utilizes an object-oriented approach to interoperability. Devices in the home network utilize one or more of these objects to provide an interface to their internal operations. A partial list of the classes defined in the CAL specification include those listed in Table 1 below. These object classes represent only a subset of the primary set of object classes defined in the CAL specification. If a function or feature cannot be mapped well to one of the object classes already defined, the developer of a product can elect to define a special class. The CAL specification has set aside a specific range of class identifiers for this purpose. In most cases the existing classes are sufficient

It is not necessary (nor appropriate in many cases) to expose all feature/functions of a product to the home network. Exposing internal product functionality to other devices on the home network essentially makes the exposed feature a public resource. This can be very desirable when the resource provided is informative such as the current ambient temperature. There is minimal liability in providing an interface to information. However, quality engineering would consider the fact that other products might depend heavily on our information and we would certainly want to safeguard its integrity. The home network would be more forgiving of a fail-safe muted node than one that remained active while spewing out bogus information.

Special care must be taken when control functions are made public through CAL object mapping. When these public control interfaces are provided to our internal operations, we introduce a certain level of vulnerability to the legitimacy of control commands sent our direction. As the home network develops into a conglomerate of nodes, each having been developed according to possibly-disparate design philosophies of engineering divisions from dissimilar industries, consumer satisfaction will hinge on the designer’s ability to anticipate and properly handle both errant and legitimate control commands. This is where solid system engineering becomes important. Having realized this, the CEBus Industry Council (CIC) decided to establish a home network system design specification and hence the development of CIC’s Home Plug and Play (HomePnP) specification (see for more information on CIC and the HomePnP specification).

Table 1
Object Class Name

Example Uses
Node Control Required in every CEBus product to enable other devices on home network to determine fundamental operating characteristics
Context Control Provides summary of what objects exist in a device that correspond to a particular context (this term will be defined later)
Binary Switch Models the operation of a single-pole, single-throw switch
Binary Sensor Models the operation of an on/off sensor
Multi-state Switch Models operation of a 1-pole, N-state switch such as that used to control a variable-speed fan
Multi-state Sensor Senses a fixed number of states in an environment
Analog Control Models a control allowing a range of values at a defined resolution
Analog Sensor Models a physical quantity sensor such as temperature
Dialer Models a touch-tone or pulse dialer
Keypad Models an ASCII character generator function
Clock Models a clock used in tracking the time of day

Within the home network we have established above for this discussion, there exist many examples of CAL object classes. But before we identify some of these objects, we should broaden our understanding of CAL objects by defining two important attributes they all possess: Instance Variables and Methods. Instance Variables (IVs) contain control or status information about a particular CAL object. This information is limited to a few very strict types. These include Boolean, numeric, character-string and data. Each of these types was established to allow for optimized exchange of information. Boolean IVs can only be set to TRUE or FALSE. As the name implies, numeric IVs are intended for storage of numbers. The character-string type provides for storage of text and the data type covers storage of other information as a single-dimensioned array of one or more elements; each element containing the same number of one or more bytes.

Access to the information contained in IVs is accomplished through a set of methods specific to that object. The common methods contained in most objects include: setOn, setOff, setValue, getValue, setArray and getArray. Not all methods make sense for each IV type. For instance, a setOn method is intended for manipulating Boolean IVs and is undefined for an IV of the character-string type.

It may help you better understand the concept of CAL objects if you consider that most CAL objects contain at least one required IV: current_value. For most practical purposes it does not make sense to have an object without this particular IV. CAL commands passed between devices on the home network either manipulate or query the contents of IVs within CAL objects via methods to perform operations necessary to interoperate amongst themselves.

Mapping CAL Objects to Features

Now that we have a basic working knowledge of CAL objects, we will identify some of the objects that exist in our previously-defined home network. Since this network only exists in our imagination, we can take the liberty of ‘playing manufacturer’ and dictate what and how features of our products are presented on the network. Lets begin by discussing our garage door opener. It has a single speed motor and a set of limit switches connected so that it knows if the door is fully opened or closed. Table 2 summarizes how we will expose its set of features to the home network.

Note that the binary control object provided as an interface to the drive motor has been designated as a reporting object limited to read-only access. At first glance, a read-only control interface seems like a conflict of terms. However, our intention is to provide information to the home network concerning activation of this motor by the standard remote controls we keep in our automobiles. To limit liability, we decided that control of the drive motor would not be accessible to other devices on the network; hence the read-only attribute. The ‘reporting’ designation introduces a new concept. We can only touch on this for now, with hope of expounding on this powerful aspect of CAL objects in a future article. When enabled to report, CAL objects can transmit a message to one or more objects on the network whenever the information represented by the current_value IV of the reporting object changes by a specified amount. In our case, any change will generate a report. Reporting objects must include three additional IVs which provide storage for the reporting condition, destination address and the particular message to be sent as a report. Through these IVs, other devices can ‘subscribe’ to the information provided by the reporting object.

Table 2: Garage door opener feature mapping to CAL objects


CAL Object Class
Fully-closed limit switch Binary sensor
Fully-open limit switch Binary sensor
Over-head light Analog control
Drive motor Binary control (reporting object, read-only access)

We will design our master bedroom radio/alarm-clock such that it exposes some its features according to table 3.

Table 3: Radio/alarm-clock feature mapping to CAL objects


CAL Object Class
Off/On/Alarm/Buzzer mode Multi-state switch
Time of day clock

These first two examples provide a small taste of how we can use CAL objects in simple devices to expose their functionality to the network. What we need now is a grasp on how to use this capability to enhance the overall operation of products in our home as part of a truly homogenous network of interoperating devices. In the next issue we will develop some scenarios of object interaction and we will introduce the concept of industry-based Contexts. These are cornerstones for building a network of objects that are tightly bound to each other based on accepted industry-standard features and/or functionality. We will also demonstrate how the alarm clock, garage door opener and security system are now able to enhance the functionality of the other.

Updated Biography Mar/03 – Brian Baker is a software engineer at Raytheon Missile Systems located in Tucson Arizona. He was a contributing member of multiple committees and working groups of the CEBus Industry Council while employed at Smart Corporation previous to his joining Raytheon. His background includes development of home automation subsystems and over 15 years of embedded systems development in the defense industry. He was a core member of the developers of the Home Plug and Play specification. Brian can be reached at