Lost in Translation: Where People Get DALI Wrong (2)

In the previous myth-busting episode on DALI I covered the polarity aspect of the DALI bus. That is: in theory it is polarity-free (it does not matter which cable goes where as far as the DALI line cables are concerned), and it practice the polarity matters (remember to connect DA+ to DA+ and DA- to DA-).

This week I'd like to talk about DALI application controllers. DALI in principle has the concept of "control gear" and "control devices and application controllers". Again, the name (especially the distinction between a "gear" and a "device" is not intuitive. So lets try that: a gear is a driver. A device is a sensor or an application controller. The technical difference is much clearer. Drivers never transmit any data on their own. Only in response to a query command. Devices do the opposite - they send data on their own. So an application controller can send a dimming command to a driver. Or an occupancy sensor can send data whenever it detects a person in the room.

Speaking of application controllers - DALI (the alliance) paints a picture "we standardize everything and test thoroughly". Which makes some people believe that DALI standardizes application controllers. But it does not. (with three exceptions). But generally the DALI standard dictates how a driver must behave when commanded. Or how a sensor must behave. DALI does not say what an application controller should be doing (it can, in principle, do anything it wants, as long as it follows some basic rules governing low level bus communications). But - for example - DALI does not standardize how a daylight harvesting controller should work. Nor how occupancy or vacancy controller should work.

This is a bug difference, compared to Bluetooth NLC. Bluetooth NLC standardizes the operation of light controllers (including occupancy / vacancy / daylighting). Bluetooth also standardizes the provisioning process, while DALI does not - again - it is all up to the system / application controller but it can basically do anything it wants and there is no standard behavior.

I decided to clearly underline this as at one of the official DALI events I heard from a speaker on stage that DALI controllers are standardized (he was comparing that to 0-10V controllers). No. They are not.

I mentioned three exceptions though. So they are Part 341, Part 342, and Part 351.

Part 341 is the DALI-Bluetooth NLC interface specification and it very precisely dictates the application controller behavior, aligning with the Bluetooth (the Bluetooth NLC Profile specification) side. This ensures that all devices that conform to the Bluetooth NLC Basic Lightness controller specification and the DALI Part 341 behave exactly the same.

Part 342 is the DALI-ZigBee interface specification and in principle does to ZigBee what Part 341 does to Bluetooth NLC.

Part 351 is a different animal, but historically this was the first DALI specification that standardized some application controller behaviors. It covers a use case that is mostly relevant to street lights: fixtures that have one or more drivers and may have one sensor - usually occupancy - looking down, and an another sensor - usually a photocell - looking up. The Part 351 describes what happens when the sensors are plugged in and how they can safely work together (the multi-master / collision avoidance scheme).

But except these three, DALI system / application controllers are as proprietary as 0-10V system / application controllers. The specifications do not mandate any features nor behaviors and each vendor implements their own.