A Case for DALI- Steve Mesh Talks Cross-Vendor Interoperability

March 4, 2024

Guest post by Steve Mesh

Digital Addressable Lighting Interface (DALI) Drivers as tools for interoperability and increase functionality across vendors in the lighting industry

In the lighting controls industry, are we at an inflection point where vendors are starting to embrace the idea of cross-vendor interoperability? Historically, the lighting industry has approached interoperability via for being proprietary technologies.

There are examples of interoperability, but these often involve using devices that are already recognized as being part of a specific “ecosystem.” As an example, 10 years ago, a manufacturer made an exclusively wireless networked lighting control (NLC) system using Zigbee as the communication protocol. This manufacturer didn’t make any wired occupancy sensors or photosensors. Therefore, to deploy this as a luminaire-level lighting control (LLLC) system, they offered an integral fixture controller that had ports for low-voltage wires. That allowed you to connect another vendor’s sensors to the system when used on an LLLC basis.

At the time, this manufacturer offered neither a wireless receptacle nor a wireless thermostat. However, they listed a specific wireless receptacle as well as a specific wireless thermostat from other vendors in their catalog that they knew would work with their system. As previously stated, these were specific work-arounds that allowed some measure of interoperability, using equipment that they verified would work with their system. It wasn’t based on the use of an open standard protocol.

Regarding open standard protocols, in North America, the lighting industry has not widely embraced standard digital protocols for controls. Instead, most of the market has embraced the use of analog methodology, primarily 0-10V dimming control. This has effectively placed some substantial restrictions on the benefits that NLC systems can provide.

Two big ones come to mind:

1. Interoperability
2. Increased functionality

Interoperability

For this discussion, interoperability means that components offered by different manufacturers can work together because they use a standard protocol. That should read: “components from different manufacturers can potentially work together” in the same networked system. Why “potentially”? Well, because you still must select components that are designed to provide the functionality you require in a given deployment.

For example, you might select a Digital Addressable Lighting Interface (DALI) application controller that is designed with very basic functionality, offered by Manufacturer A. Let’s say this application controller doesn’t have options to tell luminaires to dim based on photosensor input. You might select multi-sensors that have both occupancy detection as well as photosensor functionality, offered by Manufacturer B. However, the lights will never dim based on available daylight! The onus is on the specifier to ensure that they have selected the equipment and software that will provide the functionality they need. That’s always true—whether the components all use the same open standard protocol or not.

Given that proviso, you may find an application controller offered by a different manufacturer (Manufacturer C or D) that does tell luminaires to dim based on photosensor input. You may still prefer the multi-sensors offered by Manufacturer B because of specific attributes. Maybe they combine microwave as well as acoustic sensing. Maybe the price point is acceptable for your project whereas multi-sensors from another manufacturer may break the budget.

The fact that you can potentially mix and match products from different vendors is based on them all using the same protocol—in this case DALI. With many NLC systems currently available in the North American market, the majority of control outside of 0-10V is proprietary. This is what inhibits—or more typically prohibits—true multivendor interoperability. Additionally, as we’ll explore later, there isn’t even a requirement for the 0-10V dimming signals to perform in a specific way.

Interoperability for controls in the lighting industry can also mean that information from the NLC system can be easily shared with other systems, software, third-party providers, and so on. A great example of this is to link signals from the NLC system to an HVAC system. You might, for example, share messages that the occupancy sensors in each space changed to a vacant state. This in turn could command the HVAC system to increase the temperature setpoint by several degrees. This is a relatively new use case, and anecdotal reports are that people are still spending a fair amount of time working out the kinks in such a scenario.

We’ll explore this in greater depth in a future article. You should be aware that certain protocols already exist that are designed to facilitate this kind of interoperability, notably BACnet, ModBus, LONworks and KNX.

Another example of the benefit of true interoperability is using the NLC system to enable non-lighting Internet of Things (IoT) functions. We’ll explore this in greater detail below.

Increased functionality

As a baseline, what functionality do we get when using LED drivers with 0-10V analog dimming? We get luminaires that dim. You can also switch the fixtures On and Off when you connect a relay NLC controller upstream of the driver, that you command to turn the light On/Off. Of course, that also requires an expense in addition to the cost of the LED driver itself. Many NLC manufacturers combine the relay and dimming functionality into a single unit.

As previously mentioned, there is no standardization about how 0-10V analog signals dim LEDs. With drivers that adhere to an open standard like DALI, however, the correlation between control signals and dimming levels is predefined. Therefore, you could use DALI drivers from different manufacturers in the same control zone, and you should get the same light output in all fixtures at any commanded dimmed level.

Alternatively, what functionality do we get when using an open standard such as DALI—especially when DALI drivers are used in an NLC system? There are many. DALI drivers have a built-in On/Off function. Therefore, you don’t need separate controllers containing relays to tell the drivers to turn On or Off. So, if you’re pricing a system using analog (0-10V) LED drivers versus a system using digital (e.g., DALI) drivers, it’s not appropriate to compare the cost of the drivers alone. The true cost comparison is between the 0-10V drivers plus the NLC system’s controllers versus the DALI drivers with no additional controller required.

What other benefits are there with DALI drivers? They can report a wide variety of information, such as: energy use, run time, fault detection and diagnosis, and more. Additionally, if you use color-changing luminaires, you can select DALI drivers that provide precise color and precise light level control that is part of the DALI driver. Remember that you need to select the equipment that provides the functionality you need—not only in terms of the drivers but also the application controllers. Each offering will have its price point depending on the features you require.

Originally, DALI was only used in wired networks. In recent years, there has been an explosion of wireless NLC systems on the market. As a result, DALI has evolved to work in wireless systems as well. There are even ways to use DALI in a hybrid system—where some components use a wired connection and others are connected wirelessly.

In recent years, the DALI Alliance introduced DALI-2. This was a major enhancement to the original DALI protocol. Among other benefits provided by the new DALI-2 standard protocol, a robust testing methodology was developed to certify products that comply with the DALI-2 standard. Once a manufacturer’s product has been shown to comply through testing, then it is listed on the DALI Alliance’s Product Database. This is similar to the DLC’s Qualified Products List (QPL) for Networked Lighting Controls. In the DALI Product Database, you can filter for various features and attributes.

Another relatively recent introduction was D4i. This is a standard based on the DALI-2 protocol. It’s designed so that D4i components will work in fixture-integrated situations. Among other things, it integrally provides power to the DALI bus.

As a result, you don’t have to add a separate power supply to power things like integral sensors, unless you have tons of sensors that would exceed the relatively low power required for let’s say an occupancy sensor and photosensor. If you need greater power for equipment like adding a video camera to a streetlight, you can add separate auxiliary power supplies in the luminaire. For the typical lighting functions such as occupancy sensors and photosensors, however, the power from the built-in supply to the DALI bus should be sufficient.

Luminaires with D4i control components can be directly connected to wireless nodes. For example, some manufacturers already make Bluetooth transceivers so that you can create a wireless network that transmits information to and from fixtures. In some cases, those are designed to be connected to a Zhaga-compliant socket such as a twist-lock receptacle.

Internally, a D4i LED driver still uses the DALI-2 protocol and has all the functionality mentioned above. It just transmits that information back and forth over the wireless network established by the Bluetooth devices. Once the information from the DALI D4i driver or the integral sensors is broadcast through the wireless node, it will share that information using whatever protocol and coding was established by the control system vendor. In that sense, this isn’t a virtual DALI network. But there is a way to establish one, as follows.

DALI+ is a standard that allows you to create virtual DALI networks regardless of the method of communication. Historically, wired DALI subnets (called universes) have been limited to a maximum of 64 luminaires plus 64 peripheral devices such as sensors, switches, etc. Recall that a wired DALI network typically uses 18/2 wiring (a pair of 18-gauge wires) to create the DALI bus.

In any wired network, there will always be some degree of voltage drop. DALI+ allows you to create virtual DALI networks either by using wireless protocols (Bluetooth, Zigbee, etc.) or even wired methodology (IP-based communication, Ethernet cable, etc.). This means that you could have DALI networks that span multiple buildings, even if they are located on opposite sides of the world.

As previously mentioned, using DALI+ also lets you create hybrid systems. For example, in new construction, it’s relatively easy as well as relatively cost-effective to use wired networks since the plenum is open during construction. That makes it easy to pull wires (note that the electricians have to pull power wires through the plenum anyway).

What would you do, even in the same new construction project, if all the partitions were glass and there was nowhere else to mount switches and dimmers? If you used devices that were battery-powered and used the DALI+ protocol, they could be mounted to the glass partitions and interface with the same DALI+ network that the wired components are connected to. In a retrofit project, DALI+ might facilitate using a wired network for luminaires but using wireless receptacles for plug-load control, as long as they used the same DALI+ protocol.

Internet of Things

As mentioned earlier, one aspect of increased functionality is the ability of digital protocols to enable greater IoT operation. In the case of the new DALI offerings, sharing most types of data isn’t very different than sharing information about the luminaire.

For example, you can easily transmit the dimmed level or energy use to the network. If the luminaires have occupancy sensors and photosensors, that means that you have an LLLC system. Transmitting information about ambient light levels or whether the space is occupied versus vacant is also very easy to do.

What else might you want to incorporate into the same interior luminaire? Some of the possibilities might include any or all the following: temperature sensors, CO sensors, or CO2 sensors. What about exterior luminaires such as streetlights or parking lot lights? You can potentially include things like acoustic sensors, air quality sensors, anemometers, rain gauges, or gunshot detection sensors. Some manufacturers already incorporate some of these into their offerings.

Note that we’ve specifically left video off the list for either interior or exterior luminaires. Why? Broadcasting video from a camera requires streaming the signal. This is very different than sending data packets such as information from a luminaire or sensor.

For example, communicating to the system whether a luminaire is On or Off requires a very small amount of data transmission. So does communicating the ambient light level as detected by a photosensor, or whether an occupancy sensor detects that a space is occupied or vacant. Streaming video requires a much greater amount of data transmission. Transmitting the data gathered by the types of sensors listed above only requires sending packets as opposed to streaming massive amounts of bytes.

Plans are for future posts to tackle related subjects such as Bluetooth-NLC, HVAC/NLC integration, and integration with automated shading systems. Stay tuned!

More information available here