DALI (IEC 62386) is resistant to interference because it tolerates a great deal: it runs at 1200 baud over a two-wire, polarity-independent bus with wide voltage thresholds. That same tolerance makes diagnosis harder — the bus usually keeps working despite an existing fault, so the symptom shows up a long way from the cause.
Some problems are a violation of one of four parameters: the idle voltage of ~16 V, the current limit of 250 mA, the 64 short addresses per line, and the permitted 2 V difference between devices. The rest are faults that none of those parameters describes — a wrong connection to the 230 V installation, a device defective in a way you cannot see, or a luminaire doing something nobody expects of it. Below are nine faults, ordered from the ones you measure to the ones you configure.
1. No voltage on the bus
A DALI bus needs a bus power supply providing ~16 V, independent of the mains feeding the luminaires themselves. At first-fix stage it is often not installed yet, and on a live site its protective device may have tripped. The control gear is then perfectly healthy, it simply has no medium to communicate over.
More often, though, the bus supply is not a separate device but integrated into a controller port. The typical picture of the fault then looks different: one port loses its bus power, the whole segment connected to it goes quiet, and the neighbouring ports of the same controller carry on working. A supply like that cannot be repaired on site.
How do you spot it? 0 V instead of ~16 V between the DALI conductors.
How do you separate the blame? That is the real question, because a dead port and a short further down the installation give an identical reading:
- Measure the voltage at the controller terminals with the bus disconnected. Zero volts with nothing connected means the port is dead.
- If the voltage returns once the bus is disconnected, the port is healthy and the fault sits in the installation — go to fault 2.
- Move the bus cable to a free port. If the fault follows the cable, the installation is to blame; if it stays with the port, the controller is.
At first-fix stage before the electrical cabinets are powered, the fastest verification is applying power from a portable bus analyser — in Pilo One, the built-in 16 V / 230 mA supply switches on directly from the app, letting you test control gear without waiting for mains power.
Before you connect a replacement controller, prove the pair is clean. Connecting new hardware to a bus that still carries a short or a foreign voltage costs you another port — sometimes within minutes.
2. A short on the bus — cable or device
A short between the DALI conductors loads the bus supply and kills communication across the whole line. The classic causes are mechanical: a pinched cable, two conductors under one terminal, a loose strand, a harness trapped inside a luminaire during mounting.
Just as often, though, the short is caused by a single device. A failed input stage in a driver, a sensor or a wall panel shorts the DA+/DA− pair and silences the whole segment just as effectively as a crushed cable. The symptom is indistinguishable from a cabling short until you start dividing the line. There is also a softer, harder variant: a device that does not short the pair outright but loads and disturbs it — one bad unit among several dozen can destabilise an entire line that way.
Polarity is a separate matter and is rarely the cause in practice. The standard requires the control interface to be polarity insensitive, with one exception: devices with an integrated bus power supply are allowed to be polarity sensitive and remain compliant (IEC 62386-101, cl. 5.1).
How do you spot it? With the bus supply connected, a line voltage close to 0 V.
How do you diagnose it? Halve the line and disconnect the sections one after another until the voltage returns to ~16 V (with Pilo One, live voltage readings on your phone instantly show which segment clears the short). The cable is not the only candidate — every device on the line is on the suspect list, so when splitting into segments gets you nowhere, unplug devices one at a time.
Do not take a short-circuit warning from the controller at face value. There are firmware versions that report a short on a healthy bus and cut its voltage, and others that report the wrong port. Confirm with a meter before you start hunting for something that is not there.
3. Wrong connection to mains or to earth
A DALI bus is classified as a FELV circuit (IEC 62386-101, cl. 4.9.2): it has basic insulation from the 230 V mains, but it does not meet SELV requirements and is not safe to touch. Because DALI control wires frequently share a 5-core cable (L, N, PE, DA, DA), miswiring in junction boxes and luminaires is one of the most common field issues. It boils down to three distinct scenarios:
1. Bridged to PE (Earth). A DALI receiver measures the differential voltage between DA+ and DA−. With a single bridge from a DALI line to the PE bar, the potential difference remains ~16 V, so the installation passes the does-it-light-up test despite the fault. The result is ground noise and sporadic frame errors. The danger escalates dramatically when a second earth contact occurs elsewhere on the line: thin DALI wires close an earth loop carrying stray equalizing currents, creating a genuine fire hazard — something the standard explicitly warns against (IEC 62386-101, cl. 4.10).
2. Connected to Neutral (N). The bus power supply provides galvanic isolation, so the system does not burn out immediately. However, the neutral conductor injects operating currents and high-frequency switching harmonics from all LED drivers on the circuit directly into the DALI pair. The symptom is erratic bus behaviour: ballasts drop commands, respond sluggishly, or glitch unpredictably. Furthermore, the bus loses its isolation: if a neutral break occurs or load is unbalanced across phases, the DALI bus is exposed to 230 V or up to 400 V phase-to-phase.
3. Live Phase L (230 V AC) on a DALI terminal. DALI transceiver inputs operate up to ~22.5 V. Connecting 230 V AC immediately blows optocouplers and input stages across all connected control gear and burns out the controller or gateway port. Live mains voltage appears across the entire bus and metal fixtures, creating an immediate electric shock hazard.
How do you diagnose it? A functional light-up test will not catch this class of faults. Before connecting a controller or powering the bus supply:
- Measure AC and DC voltage across the DALI pair and between each conductor and PE/N (Pilo One checks for AC presence before powering the bus, and its Link Quality Indicator reveals edge distortion and noise caused by earth leaks). Any presence of AC voltage indicates a wiring cross-connection.
- Check continuity and insulation resistance of DALI conductors to PE and N with the power off. On a healthy installation, both DALI lines show an open circuit (no continuity) to PE and N.
- Caution with insulation testers (Megger 500 V): Leading manufacturers (including Helvar, Tridonic, and Osram) strictly prohibit high-voltage insulation tests with DALI devices connected — 500 V DC tests must only be run on isolated, disconnected cabling.
Prove the pair is clean before connecting replacement hardware. Plugging a new controller or driver into a line that still carries live phase L will destroy it in fractions of a second.
4. Bus overload
Every device has a defined bus current draw. IEC 62386-101 distinguishes current consumption when not transmitting (I_BUS; table 10) from maximum current consumption, which for bus-powered devices has to be stated in the documentation and must not be exceeded even at start-up. An externally powered device — control gear with its own mains supply, for instance — draws at most 2.0 mA from the bus; a bus-powered device draws whatever it declares.
An overload is exceeding that current budget: the sum of all device draws must not exceed the bus supply's guaranteed supply current, and the combined current of the bus supplies must not exceed 250 mA. The standard gives a simplified calculation: 2 mA × the number of externally powered devices, plus the sum of the currents of bus-powered devices, ≤ guaranteed supply current / 1.2, where the 1.2 is roughly 20% headroom for dynamic behaviour. Once you exceed it, the bus voltage sags below the logic-high threshold and frames that were clean at the supply arrive corrupted at the end of the line.
The 2 V condition is often read as a drop relative to the supply, but the standard states it differently: the voltage at the interface of any device must not differ by more than 2.0 V from the voltage at the interface of every other device on the bus (cl. 4.8.2). The reference point is the worst pair of devices, not the supply.
The threshold for "how much voltage is enough" is equally hard. A receiver only recognises a high level from 9.5 V upwards, with an upper limit of 22.5 V (table 8). A voltage measured at a particular device below 9.5 V means that device is not receiving reliably — whatever the meter reads back at the supply.
The current budget nobody calculates
It is worth saying plainly: on most sites the calculation above is a fiction. Nobody adds up the current draws at design stage, nobody records the resulting figure for a segment, and nobody measures the voltage under load at the end of the line during handover. Current overload is therefore a fault that gets suspected rather than established — because both the starting number and the confirming measurement are missing. Physical layer diagnostics in Pilo One let you verify this on site: measuring voltage under load and Manchester bit-timing quality (LQI) at the far end of the run, without needing an oscilloscope.
Two things can be counted without a meter: the number of addresses and the number of sensors on a line. Those limits do get exceeded in practice, when an installer daisy-chains whatever is physically nearest instead of keeping to the split in the design. The symptom is characteristic: commissioning cannot be completed, devices appear and disappear, the system finds only some of the luminaires.
A practical rule: do not run up to the limit of 64 addresses. Headroom costs one more port at design stage; the lack of it costs rewiring on site, usually at the contractor's expense.
Topology and line length
The standard permits a star, linear or mixed topology, but explicitly forbids a ring (cl. 4.8.1). It also requires both bus conductors to run in the same cable or conduit, next to each other, to prevent unintended coupling to other signals. That same clause is the argument against splitting the pair between different multicore cables — the subject of fault 3 above.
The widely repeated "300 m maximum" is only conditionally true. The standard derives the length from the voltage drop and tabulates it by cross-section and temperature in table A.1:
| Cross-section (copper) | 25 °C | 75 °C |
|---|---|---|
| 0.5 mm² | 112 m | 93 m |
| 0.75 mm² | 168 m | 140 m |
| 1.0 mm² | 224 m | 187 m |
| 1.5 mm² | 300 m | 281 m |
Beyond 300 m the standard does not recommend running the bus at all, whatever the cross-section. The temperature column is worth a second look: the same line that stays within budget in winter can fall outside it in summer, in a hot roof space or in a conduit alongside power cables. That is one explanation for faults that "appear for no reason".
5. A luminaire feeding the bus
This fault is the inverse of the first one: there is no shortage of power, there is too much of it, from two sources at once.
Some drivers have an integrated bus power supply, intended for small installations without a separate controller. It should be isolated from the line by a jumper or a switch — and sometimes it is not, either because it left the factory that way or because somebody moved it during earlier configuration. Once installed, such a luminaire puts its own ~16 V onto the bus in parallel with the supply in the controller.
The result does not look like a power problem. The luminaires cannot be addressed or commissioned, the controller cannot arbitrate the bus, and the measured voltage is wrong in a way that is hard to attribute to anything specific. So people go looking for shorts, overloads and failed drivers — everything except the actual cause.
How do you spot it? Disconnect the bus supply in the controller (or disable bus power in the Pilo One app) and measure the DALI pair. If voltage is still there, some device on the line is supplying it. That is the only measurement that settles this fault, and also the one nobody performs by reflex — because the assumption is that with the supply disconnected the line must be dead.
How do you fix it? Halve the line until the voltage drops to zero and find the offending units that way. It is often a handful of luminaires out of several dozen, all from the same delivery. After that it is a matter of reconfiguring or replacing them so that their internal supply is isolated from the bus.
This is where the exception in cl. 5.1, mentioned under fault 2, comes back: precisely this class of device, with an integrated bus supply, is allowed by the standard to be polarity sensitive.
6. A device that lights up but never answers
The luminaire switches on and lights, often at full output, but on the bus it does not exist. The commissioning tool finds no device at that point, addressed commands do nothing, and sometimes it only responds to broadcast.
The mechanism is simpler than it looks: the DALI interface stage itself has failed while the converter and the LED output carry on working. The luminaire lights because nothing has told it to stop — with communication gone, it stays at the last known level, or at the failure level, which is usually 100%. A completely different situation, with very different commercial consequences, looks identical: an on/off or HF version delivered instead of the DALI version that was ordered. Before anyone starts hunting for a fault, it is worth confirming that what was ordered and what was delivered are the same thing.
How do you spot it? The luminaire lights with correct mains voltage but answers no query, on any line it is connected to.
How do you diagnose it — and this is the most important paragraph in the article. Measure the bus voltage at that particular, non-working luminaire, not at the controller, and issue diagnostic queries (for example with a quick scan from Pilo One). That single step separates two scenarios that look identical at first glance:
- below 9.5 V at the luminaire → the cause is the power or wiring of that segment, and replacing the device changes nothing;
- voltage correct and the device still silent on addressed and broadcast queries → failed DALI interface, device to be replaced.
This matters most when several luminaires fail to answer at once. A report of "eight units cannot see the bus" is almost never eight independent failures — it is one power fault or one broken connection common to all eight. Replacing eight drivers costs eight times what one measurement costs, and does not remove the cause.
7. Addresses: duplicates, losses and absences
Three different faults with a similar symptom — a device that does not respond individually, or the wrong thing responds.
Duplicate short addresses. Two control gears share the same address (0–63). The most common cause is not an addressing mistake but working with equipment that has been used before: control gear moved between sites, bus sections repatched, devices reused after running somewhere else and keeping the address assigned back then. Connected to a new line, they bring their old address with them and collide with a device already using it — the replies of both overlap on the backward channel and the bus cannot tell the senders apart. How to spot it: an address that two luminaires respond to, plus collisions on the backward channel. How to fix it: scan the line (in Pilo One conflicting units are identified by their unique serial number and GTIN), change one device's address to a free one with a single tap, and confirm its location by blinking the luminaire.
A device losing its address. It was commissioned correctly and then drops out of the scene and group configuration, reverting to uncontrolled behaviour. The cause is a fault in the device's non-volatile memory. Spotting it is simple though time-consuming: re-address it, cycle the power, check whether the address is gone. If it disappears repeatedly, the device is a replacement case — this is not a configuration problem and no amount of re-addressing will fix it.
A device that was never addressed. Installed after the commissioning visit, in a room that happened to be locked, or on a circuit that was switched off that day. Physically present, electrically fine, non-existent in the system. It gets reported as defective when all it needs is commissioning. Before opening a warranty claim, check the device against the commissioning matrix.
Worth mentioning separately: repatching buses after commissioning. When the contractor moves branches between ports after the luminaires have been identified and named, the database stops matching the building — room names point at the wrong luminaires, whole buses disappear, and the addressing work has to be done again.
8. Control gear that does not comply with the standard
DALI-2 certification is far more restrictive today than in the first version of DALI, but manufacturers still largely carry it out themselves. That leaves room for non-compliance — increasingly rare, but still encountered. The market is flooded with new devices, most of them of very good quality and fully compliant; there are, however, individual products that formally declare DALI-2 while breaking its requirements in practice, and they can cost many hours of diagnosis.
The worst offenders are control gear that looks correct at first glance — it addresses, answers queries, responds to brightness changes — but has logic errors in its protocol implementation: it ignores some control commands, or responds to them differently from what the standard specifies. There are also devices that corrupt frames on the bus, breaking communication that is not even theirs.
A separate and common problem is the absence of unique serial numbers. DALI-2 requires every device to have its own identifier (a serial number together with a GTIN), and application controllers rely on it to rebuild the structure of the system. When a device loses its short address, the controller tries to restore the assignments using that identifier — but if two units of the same model carry an identical serial number, it cannot tell them apart, and the whole system structure can fall apart.
A related source of trouble is mixing device generations and part numbers within one installation. Each works on its own; together they can behave unpredictably.
How do you spot it? A fault explained neither by voltage measurements nor by addressing, which disappears once one device is swapped out. How do you diagnose it? Isolate the suspect device and check its behaviour on its own (capturing raw frames in Pilo One's Dali Monitor verifies settling times and catches timing violations); verifying the identifier against the DALI Alliance database confirms whether the device really is certified and whether its declared parameters match reality.
9. Bus flooding and spurious triggers
An input device reporting too often — a light sensor sending a reading every 1 s, for instance — saturates the bus bandwidth and delays control commands. It can also produce what look like luminaires changing state on their own.
How do you spot it? Delayed response to commands, and traffic dominated by the cyclic reports of a single device. How do you diagnose it? Log the traffic over time and identify the sender. In Pilo One, the traffic monitor visualises bandwidth usage in real time and highlights the flooding sensor address, while the Pilo Agent analyses instance settings (tReport, tDeadtime, hysteresis) and applies optimal parameters without digging through registers.
How do you fix it? Lengthen the reporting interval and enable hysteresis.
The order to work through them
Faults cascade, so you check them starting from the lowest layer:
- Bus voltage (~16 V at idle) — power. At zero, separate the blame: dead port or fault in the installation.
- Voltage close to 0 V — a short, in the cable or in a device.
- Voltage present with the controller's supply disconnected — a luminaire is feeding the bus.
- Conductor insulation against PE, N and L, plus any AC present — wrong connection to mains or earth (it can keep working despite the fault).
- Voltage under load at the furthest device (≥ 9.5 V) — overload, cross-section or length.
- Voltage at the specific non-working luminaire — separates a segment fault from a failed interface in the device.
- Uniqueness and persistence of addresses — duplicates, lost addresses, devices never commissioned.
- One sender's share of the traffic — bus flooding.
- When none of the layers above explains the symptoms — suspect a non-compliant device and check it separately.
Each step narrows the scope for the next one; checking in a different order leads to "fixing" a symptom whose cause sits one layer below.
The pattern repeats: the repair is usually short, and the cost is locating the fault. The most expensive mistake in this work is replacing a device before measuring anything — it costs the hardware, the visit and the time, and it does not remove a cause that was sitting in the segment. Every symptom above — apart from the insulation measurement, which needs a meter — can be read straight off the bus with a single analyser. That is the approach we built Pilo One on.
