There have been several MCU announcements recently regarding ZigBee-enabled MCUs. What caught my attention about them is how specific these products are. They do more than provide ZigBee connectivity, they address specific application profile standards that the ZigBee organization has been developing.
Here are the recent product announcements (in order of release) that caught my attention:
NXP indicated that it had achieved product certification for a ZigBee Light Link color scene remote control and an extended color light.
Atmel claims a first in achieving ZigBee Light Link Certification status as a "golden unit" reference implementation.
Texas Instruments claims the first demonstration of a ZigBee Light Link "golden unit" design at the Computex show in Taipei.
Freescale introduced its Kinetis KW20 MCU family for ZigBee Smart Energy v 2.0, with alpha sample availability set for Q2.
Other, similar, products are undoubtedly available and more are likely to come. What struck me about them, however, is that they target specific application profiles.
The ZigBee 2007 specification describes how the building blocks of a self-organizing mesh network built atop the IEEE 802.15.4 wireless standard should operate. The specification calls for two implementation options, or Feature Sets: ZigBee and ZigBee Pro. The two implementations interoperate, differing mostly in the network size they support. A second ZigBee specification, RF4CE, describes the implementation of a simpler, point-to-point network consisting of paired controllers and targets.
The ZigBee 2007 specification, however, only describes how devices communicate. What they communicate was originally left to the developer. That leaves plenty of room for innovation, but makes interoperability difficult. Just because two devices are ZigBee compliant doesn't mean they speak the same language. Thus, people wanting to create a system using ZigBee had to build everything themselves.
The ZigBee Standards seek to change that situation by providing an application-driven set of commands and responses that a device in that application might want to use. By creating a common language for an application, the standards can help the industry to create interoperable products so that end users can mix and match devices from different vendors when building a network.
A number of such standards (also called profiles) are now defined, with some on their second version. The ZigBee standards include:
ZigBee Building Automation (efficient commercial spaces)
ZigBee Remote Control (advanced remote controls)
ZigBee Smart Energy (home energy savings)
ZigBee Health Care (health and fitness monitoring)
ZigBee Home Automation (smart homes)
ZigBee Input Device (easy-to-use touchpads, mice, keyboards, wands)
ZigBee Light Link (LED lighting control)
ZigBee Retail Services (smarter shopping)
ZigBee Telecom Services (value-added services)
ZigBee Network Devices (assist and expand ZigBee networks)
The presence of all these standards, and the release of designs specifically targeting them, mean that developers today need to look beyond the ZigBee label when evaluating MCU design options. Support for the specific profile desired will need to be an essential part of the evaluation, as well.
What's your opinion of all these profiles? Do they help simplify design, or fragment the vendor's ZigBee offerings into overly-specific devices?