The standardization of the interfaces presented by each device to the control system is central to its design. It enables the control system to be programmed without reference to the characteristics of the individual devices. This standardization is achieved by creating a profile for each device type for each device manufacturer.
Even though they may comply with a ZigBee or Z-Wave standard, all devices have individual characteristics, not all of which are advertised in their specification. In particular, the way in which a device reports its current status, and the way in which it interacts with other devices, can differ from one device to another.
To avoid having to program the control system to cater for these devices differences, each device is profiled separately. This profiling enables a standardized interface to be presented to the control system for each device, regardless of the detailed behavior of the device.
Profiles are created by first gaining a thorough understanding of the device. In addition to complying with the manufacturer’s published specification, this entails testing the device at the lowest possible level over a wide range of conditions, and over an extended period of time.
The mechanism for communicating any ZigBee or Z-Wave device is by exchanging frames, which are simply data packets that conform to the appropriate standard.
Devices can communicate with other devices in several different ways:
A battery powered device may only send a report periodically, or when something changes, such as a door opening, or a temperature change. The control system must capture this data as and when it is sent.
Some devices respond to being interrogated by another device, most often the control system, and send a report back to the interrogating device.
Some devices have to be kept alive by another device, normally the control system. To do so, the control system must capture the data being sent by the device, as and when it is sent, and respond immediately to the device. Any failure to respond may result in the device disconnecting from the network, and having to be re-joined.
We have developed in-house tools to simplify and expedite this profiling. These tools have been used to create profiles for a wide range of different devices from several manufacturers.
Any profile that has been created for a particular type of device for a particular manufacturer are also likely to be applicable to other devices of a similar type from the same manufacturer. For example, a profile for a particular thermostatic radiator valve (TRV) from a particular manufacturer is likely to be equally applicable to other TRVs from the same manufacturer.
Existing profiles can also be used as the starting point for other devices from the same manufacturer, or other similar devices from other manufacturers, providing that they comply with the same ZigBee or Z-Wave standard.
In many respects, a device profile is similar to a device driver for a computer peripheral. The main difference is that device profiles are created as part of the control system, rather than being supplied by the device manufacturer.
This profiling anticipates a more general plug-and-play approach for the future of home automation devices. Just as the interfacing of peripherals to desktop computers, which used to be a complex and skilled task only a few decades ago, is now predominantly plug-and-play, home automation devices can be expected to mature in the same way.
Currently, both the ZigBee and Z-Wave specifications allow too much flexibility for the devices to conform to specific behaviors, so the required standardization can be achieved only through some form of device profiling.
The user is only aware of the existence of a profile when a device joins the network. Once the user has confirmed the type of device being joined, its profile is selected automatically. The profile then provides a hidden interface between the device and the control system.