Compatibility. With the original DALI there were problems of compatibility between devices from different vendors. With DALI-2 multi-vendor compatibility is assured through a process of independent testing and verification. No device can carry the DALI-2 logo if it has not completed, and passed, the necessary compatibility testing.
Switches, sensors and touch panels can be directly connected to a DALI-2 bus. This was not possible with the original release of DALI. This means that implementation is now simpler and less costly than before.
Increased functionality. Subject to your choice of devices, a DALI-2 system can monitor energy consumption and running hours, and can control circadian lighting, amongst many other new features.
D4i enables sensors to be connected directly to a driver. D4i is an optional extension of DALI-2. It lowers the cost and complexity of adding sensors to an installation.
Future-proof and more sustainable. DALI-2 has an architecture that enables operational data to be stored, and analytical capabilities to be added later. This means that a relatively simple implementation can evolve and grow over time.
That was just a brief summary of the main differences between DALI and DALI-2. If you would like to know more it will help if you know the background to DALI and its evolution.
In brief, DALI is a communication protocol designed to be used in a lighting control system. DALI stands for Digital Addressable Lighting Interface; it is an open protocol (so it does not belong to any single lighting company) and it is defined in an international standard. DALI communication takes place over a low-voltage two wire communication network. Connected devices will typically be DALI LED drivers, DALI sensors, a DALI bus power supply and a DALI application controller.
If you would like to know more about DALI itself, here is some further reading: "What is Dali?"
The original version of DALI was launched in the late 1990s. Till then, the most widely used commercial lighting control protocols were:
1-10V (analogue). This was widely used for simple dimming control, but it had significant drawbacks:
It was never defined as a standard, so was implemented with slight differences by different control gear manufacturers. The result of this was that mixing control gear from different manufacturers in the same scheme was inclined to give some very inconsistent results.
Being analogue, scene definition and control was difficult and very hard to replicate accurately.
Digital Serial Interface (DSI), launched by Tridonic in 1992. DSI was patented by Tridonic, so other manufacturers were keen to develop an alternative with more functionality than both 1-10V and DSI.
DMX – but this was never widely in commercial applications. It was designed, and is still used, for entertainment, decorative and architectural purposes.
From the outset, DALI had substantial advantages over the technologies that had preceded it:
1. It was digital, (unlike 1-10V). This meant that specific dim levels, for example, could be consistently implemented across multiple light fittings over a wide area.
2. It was addressable, (unlike 1-10V and DSI). This meant that groups, sub-groups and scenes could be formed.
3. It was defined in a standard (IEC 60929), which meant that there was a substantial degree of interoperability between manufacturers. In one scheme, at least in the early days, lighting control gear of several different brands could be expected to work in the same way.
As time passed the shortcomings of DALI became apparent. These mostly stemmed from the fact that DALI used a low data rate (12 kbps) and a small (16 bit) data frame. These choices were made in the 1990s to ensure that DALI could be installed by electricians using unshielded cables, but the result was a simplistic system by the standards of the 2020s with two glaring deficiencies:
DALI was a “single master” system - there could be only one device that generated DALI commands and that was the application controller. Drivers merely responded to a command and the only exception was a DALI emergency module which could place a signal on the DALI bus, but only after it had been polled by the application controller.
DALI did not allow switches or sensors to be directly linked to the bus. Apart from the application controller, only Hf fluorescent gear, emergency modules, dimmers and drivers could be directly connected to the DALI bus. Lighting control manufacturers had to use a separate controls bus (typically RS485) to connect their switches and sensors to the application controller, which would then generate the necessary signals on the DALI bus to switch the lights on/off or brighter/dimmer.
In an effort to overcome these drawbacks several manufacturers deviated from the standard. Helvar (for example) developed a range of sensors that could be connected directly to a DALI bus, but they could only operate reliably in an all-Helvar environment.
To prevent further vendor-specific variants of DALI being developed, and to overcome DALI’s deficiencies, the lighting industry combined to develop what became DALI-2.
Here is the more detailed answer:
1. Compatibility. In order to carry the DALI-2 logo (which is owned by the Digital Illumination Interface Alliance – DiiA – also known as the DALI Alliance) a device must undergo independent testing and verification of the test results to prove its adherence to the new standard - IEC 62386. The previous DALI standard was IEC 60929.
he DALI-2 logo. This cannot be used on any product unless it has undergone and passed independent testing to IEC 62386, required by the logo owners.
Independent testing and verification was not a requirement before DALI-2, and this led to compatibility issues between devices from different manufacturers.
2. Control / input devices. DALI-2 allows control devices, such as switches, touch panels, occupancy sensors and light level sensors to be connected directly to the DALI bus. The functionality required of each such device for connection to a DALI-2 bus is defined in IEC 62386 (parts 301 – 304). Before DALI-2 these devices could not be directly connected to the DALI bus; instead, they were usually connected to the application controller by a separate control bus, adding to cost and complexity.
This change is possible because DALI-2 now supports multi-master operation. In (the original) DALI, only the application controller (of which there could only be one) could place a signal on the bus. The exception to this was a DALI emergency module, and it could only place a signal on the bus if it was first polled by the controller.
Now, with DALI-2 which has collision detection functionality, multiple devices can place signals onto the same bus.
Here’s a detail you might find interesting:
In DALI, and now DALI-2, there is a limit on the number of addresses (and therefore devices) that can be accommodated on a single bus. Of course, adding switches and sensors directly to the bus, as you can do with DALI-2, consumes the available addresses, so the designers of DALI-2 introduced two changes to prevent the available addresses being used up too quickly:
i. Separate address limits were set for:
a. Control gear (eg drivers) – 64 addresses, plus
b. Control devices (eg switches & sensors) – 64 addresses.
ii. The concept of the “instance” was introduced. A control panel with 8 buttons might be expected to use 8 of the available 64 addresses, but instead it can use one address and 8 “instances”. Similarly, a lighting control sensor with a PIR and a light-level sensor could be one address with two instances. DALI-2 allows one device to have up to 32 instances.
3. Increased functionality. With DALI-2 a number of new concepts are introduced which substantially increase the flexibility and functionality of the system:
a.Multiple device types. DALI-2 recognises multiple device types (DTs). The term “device type” is often used to describe a specific piece of hardware, but more accurately, “device type” defines a specific set of features. Here are some examples:
i.DT1 (IEC 62386 part 202) describes the functionality required of a DALI-2 self contained emergency module.
ii.DT6 (IEC 62386 part 207) describes the functionality required of an LED driver with a single address and a single output (the most common type of LED driver)
iii.DT8 (IEC 62386 part 209) describes the functionality required of an LED driver with a single address and two or more outputs, as used for colour control.
iv.DT16 (IEC 62386 part 217) describes the functionality for thermal protection.
v.DT20 (IEC 62386 part 221) describes the functionality of load shedding.
Because the functionality of each part of IEC 62386 does not contradict or overlap any other part, a single driver could embody either DT6, or DT8 or both, plus either, both or neither of DT16 and DT20. It is for each manufacturer to choose what functionality they offer in each of their products.
In total, some 20 device types and IEC parts have been defined, creating the potential for a rich and evolving DALI-2 environment of diverse but compatible devices.
b.DiiA extensions to IEC 62386. The DiiA has defined device types (or feature sets) that build on IEC 62386 and which are expected to become part of IEC 62386 in due course. These include the following, which are designed to be included in an LED driver at the manufacturer’s discretion:
i.DT50 – Luminaire data, such as the luminaire type and location.
ii.DT51 – Energy data, including active and apparent energy and power consumption.
iii.DT52 – Diagnostics & maintenance data.
4. D4i. This is an optional extension to DALI-2. It is an interface that provides a low-cost way to connect, for example, a D4i sensor to a D4i driver. Any D4i device must be both DALI-2 and D4i certified, so that sensors and drivers from different manufacturers can be used together seamlessly. In summary, a D4i interface performs two main functions:
a. It is a power supply. A D4i driver can power a D4i sensor. This is economical, because the sensor can derive the low voltage it requires direct from the driver, rather than having its own 230V connection and transformer.
b. It is a data exchange interface. Occupancy and light-level data (for example) from a D4i sensor can be placed on the DALI-2 bus via the D4i driver. In addition, any D4i driver must implement DT50, DT51 and DT52 (see above). This creates the potential for peripheral devices to be connected to drivers which then store data that can be interrogated at a later data for multiple purposes. For this reason, D4i is often described as an enabler of the internet-of-things (IoT).
The D4i logo. This cannot be used on any product unless it has undergone and passed the testing required by the DiiA.
D4i simplifies and lowers the cost of adding small devices to a DALI-2 installation, especially in the form of sensors integrated in luminaires.
5. Future-proof & sustainable. DALI-2 and D4i are now so functionally rich and diverse that they constitute an ecosystem of hardware and software. This means that as the needs of a building’s occupants evolve, new capabilities can be added. For example, if DT51 is implemented from the outset, then energy analytics can be added later. If DT52 is implemented, when the light fittings are due for an upgrade (fashions change and the building’s use might be changing too) the drivers can perhaps be re-used, rather than being discarded.
DALI-2 was designed to be backward compatible with older DALI devices. Therefore, older DALI drivers will work in a newer DALI-2 installation, but only within the limits of their original functionality.
