03 Dec 2012

Implementing ZigBee Light Link for Lighting Control

Oyvind Strom, Sr. Director of Wireless Solutions, Atmel Corporation looks at the techniques for implementing Zigbee Light Link in lighting control applications

ZigBee profiles define application-level communication protocols that provide interoperability between devices and applications from different vendors.

Profiles are based on a number of specific target application areas such as smart energy, health care, telecom, and most recently in April 2012, for lighting.

To also ensure networking interoperability, ZigBee profiles must be implemented on top of ZigBee PRO compliant networking stacks to allow most networking characteristics to be determined by the underlying protocol which are similar for all application-based profiles.

The ZigBee PRO standard uses license-free 2.4GHz frequency band with a 250 kbps physical data rate and specifies important mechanisms for networking such as security, mesh routing, and network management. Figure 1 illustrates the family of ZigBee protocols and profiles.

ZigBee profile family tree

Figure 1 – ZigBee profile family tree

To achieve interoperability on the application level, ZigBee profiles rely on the concept of clusters. A cluster defines a standard interface to a common functionality, for example, time, on/off, level control, etc. It specifies how a particular functionality should be maintained on the node (server side) as well as the protocol commands required for other nodes to access this functionality remotely over the air (client side).

Zigbee library

The ZigBee Cluster Library (ZCL) provides definition information for all the ZigBee profiles. Each ZigBee profile specifies device types that operate within the application area. For example, the Smart Energy profile defines metering device, energy display, thermostat and others.

The Light Link profile defines access to device such as on/off sensor, dimmable light and light colour. For each device type there is a list of mandatory and optional clusters to support. And it is often the case that the same clusters are used in different ZigBee profiles, allowing devices to be interoperable across more than one application profile.

ZCL and ZigBee profiles.

Figure 2 Principles of ZCL and ZigBee profiles.

Industry lighting leaders such as Philips and Osram, together with strong support from ZigBee chip vendors, drove the design of the ZigBee LightLink (ZLL) profile. The ZLL profile specifies two main groups of devices: controllers (e.g. sensor, bridge, remote controller) and lighting devices (colour light, dimmable light. etc.).

An important part of the ZLL profile design is to ensure ease of installation and use of the devices without any prior technical knowledge. This is achieved by providing a thorough description of device commissioning procedure, extensive test coverage and the absence of any optional functionality that can lead to interoperability issues.

A ZLL network is formed and operated in a distributed manner. There is no need to have a central coordinator node that manages the network and communication. This makes the system easy to install and maintain as well as making it very robust, as there is no single point of failure.

Light manipulation

On the light manipulation side, the ZLL profile standardizes control of the on/off state, colour hue, saturation, brightness and colour temperature. It also allows configuring light parameters as a “scene” and recalling them, as well as organizing lighting devices into groups controlled simultaneously. This is achieved by using Color Control, Level Control, On/Off, Scenes and Groups clusters.

Light Link controlled devices are able to interoperate with Home Automation (HA) devices if they are joined to the same ZigBee network. Using this approach, ZLL lighting devices can be controlled both by ZLL controller devices as well as HA devices. Such communication is possible since HA and ZLL profile use the same clusters (although clusters used by ZLL may have additional attributes), and the connections between devices are established using the standard ZigBee mechanisms.

Adding devices

A new lighting device is added to a ZLL network via ‘touchlink’ commissioning. To initiate this procedure, a controller device and a lighting device are put close to each other (typically within 20 - 50 cm), and the user presses a button on a controller that instigates a command exchange. During this step, network parameters are transferred to the lighting device after which it becomes attached to the controller’s network. This operation is repeated for each new lighting device that has to be manipulated by the controller. Additional controllers can also be added to the current network by using the same touchlink process with the controller device already present in the network.

Usually ZLL controllers use group addressing by default. After touchlink a light is immediately added to a controller’s group. Group addressed commands coming from the controller reach all lights in the group. It is also possible for a user to select a specific light, which then can be controlled individually.

As a ZigBee end device, a controller sends all frames to the network via its parent router. A lighting device, as a router then forwards these frames to the destination nodes, if needed using other intermediate routers.

Route discovery procedure

If the path to the final destination is unknown on some of the nodes then a route discovery procedure is automatically initiated within the stack and best suitable path will be used to deliver the message. From the application level only address of the target node shall be specified. Path discovery and maintenance (if conditions change or some routers are removed) is handled automatically inside ZigBee stack.

When considering incorporating ZigBee Light Link into a new product, engineers not familiar with ZigBee are recommended to use a reference design available from many microcontroller suppliers. For example, Atmel’s RF4CE-EK evaluation kit uses a solution based on their ATmega128RFA1 wireless SoC device using a ZigBee PRO stack called BitCloud.

Within the kit, a reference application called ‘ZLLDemo’ contains certified implementations of a color light and a colour scene controller. The remote control board (RCB) from the kit for a colour scene controller should be assembled with the Key Remote Control board. The color light’s application comes in two variants: for a sole RCB board, in which case a LED on a board serve as light, and for an RCB board assembled with the Key Remote Control board with the LCD.

BitCloud ZigBee Light Link demo with light control

Figure 3 - BitCloud ZigBee Light Link demo with light control

Performing a touchlink between a controller and the light device forms a network. During the touchlink the light unit identifies itself to ensure the user that the controller has selected the right device. Depending on the light device configuration the identification is done either by flashing the LCD screen or blinking with the on-board LED. The controller than can be used to add other lights or controllers to the network via the same touchlink procedure.

Once lights are commissioned to the network, the lights can be manipulated using numerous buttons present on the remote controller. Commands for on or off, brightness and colour change as well as scenes setup and recall are available for user. They can be sent to the lights as groupcast or unicast. It is possible to configure different groups that each remote can control.

Also nodes save current networking and application parameters into EEPROM and, in case of reset or power cycle, restore their network state and do not need to be re-commissioned into the network again.

For engineers, the benefit of using a reference application is that the Light Link networking code responsible for touchlink commissioning and commands exchange is certified and doesn’t require any further modifications. Engineers can focus on the specific requirements of their applications such as LED driver control according to received ZLL commands, and managing events for command transmissions on the controller side (buttons, timers, serial interfaces, etc.).

Page 1 of 1

About the author

Dr. Øyvind Strøm is Senior Director of Wireless Solutions at Atmel and he is also one of the two inventors of the 32-bit AVR microcontroller architecture and he has been the lead designer of Atmel’s 32-bit AVR design team. He has published more than 40 technical articles and he holds one United States patent in addition to having numerous patents pending.

Dr. Strøm is an expert in computer architecture and low power design. He holds a M.Sc. (1995) degree in electrical engineering from Delft University of Technology, The Netherlands. He received his doctorate in 2000 in electrical engineering from the Norwegian University of Science and Technology with the thesis, “Microprocessor for Executing Byte Compiled Java Code”.

Atmel Corporation is a worldwide leader in the design and manufacture of microcontrollers, capacitive touch solutions, advanced logic, mixed-signal, non-volatile memory and radio frequency (RF) components. Leveraging one of the industry's broadest intellectual property (IP) technology portfolios, Atmel is able to provide the electronics industry with complete system solutions focused on industrial, consumer, communications, computing and automotive markets

Most popular articles in Wireless technology

  • IoT Device Management: Why You Need it and How it Works
  • Implementing ZigBee Light Link for Lighting Control
  • Designing for the IoT: Overcoming the antenna challenge
  • Thread: Wireless Networking for the IoT Age
  • Wi-Fi Spectrum Needs and the role of Wi-Fi assurance
  • Share this page

    Want more like this? Register for our newsletter

    2019 Electronic Component Market Supply Forecast  Ian Poole | Electronics Notes
    2019 Electronic Component Market Supply Forecast
    Electronic supply has a major impact on manufacturers and as a result it is an aspect of the industry that many are keen to forecast and prepare for and changes in the industry.

    Radio-Electronics.com is operated and owned by Adrio Communications Ltd and edited by Ian Poole. All information is © Adrio Communications Ltd and may not be copied except for individual personal use. This includes copying material in whatever form into website pages. While every effort is made to ensure the accuracy of the information on Radio-Electronics.com, no liability is accepted for any consequences of using it. This site uses cookies. By using this site, these terms including the use of cookies are accepted. More explanation can be found in our Privacy Policy