Guest post by Steve Mesh
According to Wikipedia, a communication protocol is a “system of rules that allow two or more entities of a communications system to transmit information via any kind of variation of a physical quantity.”
That’s a mouthful! What does that mean in terms of networked lighting control (NLC) systems?
Most people in our industry think of a protocol as a “language” spoken by the various components in a lighting control system. Typically, this would describe things like ZigBee, DALI, etc. These are examples of protocols that are used in a digital network. However, there are also analog signals that are used in the vast majority of lighting control systems on the market. Like which? Specifically … 0-10V is used to send an analog signal to a dimmable driver or ballast to indicate the desired dimming level.
The vast majority of LED drivers on the market use 0-10V to accomplish this task. Since these drivers are not “digital” devices themselves, they are typically paired with “controllers” that contain relays to turn the driver’s power on and off, and also send the 0-10V signal over a pair of low-voltage wires to the LED driver. Although the controller is a digital component (using a specific protocol to talk with the lighting control system), the dimming signal itself is still an analog signal.
What this clearly demonstrates is that more than one protocol is often used in any given lighting control system at the same time. Let’s consider as an example a wireless NLC system. It may use 1) a proprietary protocol to connect the server in an IT room with wireless gateways in the controlled space, 2) ZigBee or some other established protocol to connect the wireless gateways with luminaires, sensors and switches, and 3) 0-10V analog signals to connect the luminaire controllers to the LED dimmable drivers in each fixture.
If you read any building trade magazine, it appears as though we are hurtling into the age of IoT for building systems. As a result, the NLC system that you specify for a space or building may also have to interface with a variety of other systems, APIs (application program interfaces) or software. Each of these may have their own protocol.
For example, many building management systems (BMS) can interface with specific systems (such as NLCs) by talking “BACnet.” Another example is automated demand response (ADR). This allows a system like an NLC to receive a signal from an off-site demand response server, which in turn dims or turns off lights to reduce electrical demand. As you might have expected, there is already a specific protocol for communications between the ADR “server” and an NLC that you have installed in your building. In fact, there are already new versions of the protocol, so you would need to check if your NLC spoke ADR 1.0, ADR 2.0a or ADR 2.0b. The software in the NLC system has to be written to speak a specific “language.” If not, then it can’t communicate with the “OpenADR server.” This may be true of other types of interfaces as well, so you really have to ask these questions up-front before shelling out money for a system that might not do what you need it to do.
It may seem kind of funny that the vast majority of LED fixtures used throughout North America have analog 0-10V dimming drivers. Worldwide, there is a much greater prevalence of digital drivers – for example, DALI (Digital Addressible Lighting Interface) drivers. Unfortunately, DALI has had a much harder time catching on here in the U.S. Since DALI drivers are digital devices, they contain unique addresses so you can identify a specific fixture just by its driver. Additionally, the DALI protocol has specific commands to turn a driver on and off, and also to dim it to very specific levels (based on a scale of 0-255). As such, a system that talks DALI can potentially save you money since you don’t need to install additional “controllers” in each luminaire. The controller’s functions are already incorporated in each DALI driver.
The 0-10V signal is also a bit loosy-goosey. There is no universally accepted definition for how components should behave based on seeing a specific voltage within the 0-10V range. Typically, 10V means “full output,” and 0V means “minimum output.” However, there are in fact certain fluorescent ballasts that turn off when a 0V signal is sent through the low-voltage dimming wires. Anyhow, what does it mean when a signal of let’s say 5V is sent through these wires to the driver or ballast? Go to 50% light output? Go to 50% energy input (which may not provide 50% light output)? Or will it go to a different level because there is essentially no “spec” for the behavior? These are questions that typically don’t exist when you use a digital protocol (such as DALI), because these behaviors are predefined and guaranteed to work based on the industry-accepted definition of that protocol.
What’s the bottom line with protocols? Ironically, it’s probably something you don’t have to worry about. A system will use whatever protocol or protocols it needs to in order to operate properly. The end user typically doesn’t need to be able to speak (or program) in these languages (Zigbee, DALI, etc.) because that work has already been done by the manufacturer. What you interface with (the UI <user interface>) has presumably been created to be read in plain English. However, after what we’ve already discussed, you may prefer using a system that uses fewer components (so potentially not a 0-10V system). Therefore, it will have to rely on some other protocol (for example, DALI). Or you may simply want a system that has a tight, predefined set of behaviors based on precise language and expectations (again, that suggests a digital protocol).
Since this will affect the drivers in each fixture, these decisions are potentially a big deal. If you want to learn more about specific protocols used in the lighting industry, you may want to purchase a copy of IES TM-23-17, Lighting Control Protocols (available at www.ies.org).
Excellent article, Steve. Thank you.
I’ll only comment on DALI. The idea of Network Lighting Controls makes a lot of sense, but like any computer-driven network, DALI and its close relatives, like Lutron Ecosystem, requires much more of the system supplier than other lighting controls. The DALI ballasts of the 1990’s were OK, but the control systems were not. The original DALI idea of a simple network had a conceptual flaw that was solved by variations like Ecosystem. To make original DALI work, it requires TWO networks – one for inputs and one for outputs – a schema now used in most systems. In short, the protocol worked fine, but it takes a significant investment and a lot of time to use it to make a product. This should serve as a warning for those who think lighting controls are easy and any high tech app writer can easily design a lighting controls product.
Jim … great comment!!! It is a fantastic point you made that a protocol’s tight spec and clearly defined behavior (such as DALI) does not in and of itself guarantee that a specific NLC will be “user friendly”. As I suggested in the post, a tight spec for a digital protocol such as DALI is simply a tool available for a manufacturer to use. For example, it’s possible to know exactly what dimming level the fixtures should achieve based on a specific input, because that’s predefined in the DALI spec. In and of itself, that in no way guarantees that the system and its UI (user interface) will be particularly user friendly or not.