Why My Lighting Specs Kept Failing: Three DALI Driver Mistakes and the Pre-Quote Checklist That Finally Fixed Them

The order that looked fine on paper

In February 2021, I signed off on a spec for 340 LED drivers for a mid-size office retrofit. Six floors, DALI-2 dimming, occupancy sensors in the corridors, daylight harvesting near the perimeter windows. Every line item on my spreadsheet checked out. Voltage: matched. Wattage: matched. Protocol: DALI. Lead time: 4 weeks. Cost: $4,280 (which, honestly, was $600 under the competing quote).

Commissioning started nine days late. By the time the integrator finished, we'd replaced 62 drivers, rewritten the sensor grouping three times, and the client had escalated to my director. Final damage: roughly $9,100 in rework, replacements, and weekend labor — plus a relationship that took two years to repair.

The kicker? I still had the original spec sheet. Nothing was wrong with it. That's what I want to unpack here, because for a long time I thought the problem was me — picking the wrong brand, missing a detail. It wasn't. The problem was that I was specifying components when the project needed a system.

What everyone thinks the problem is

If you ask most contractors why lighting specs fail, you get the same answers: the driver was defective, the sensor didn't talk to the driver, the electrician wired it wrong. And sometimes that's true. In my first year (that was 2019), I made the classic rookie mistake of trusting a datasheet's "DALI compatible" line without checking which DALI version. Cost me a $600 redo on a small retail job and about a week of sleep.

But the three big failures — 2021, 2022, and last spring — weren't that. They were subtler, and they're the reason I now keep a printed checklist taped inside my spec binder.

The deeper problem: compatibility lives at the system level, not the part level

Here's what I eventually understood, and it took three failures to see it: a DALI driver and a DALI sensor can both be perfectly compliant with IEC 62386 and still fail to behave the way the project needs them to.

Why? Because compliance guarantees protocol, not behavior. Two drivers from different manufacturers can both carry the DALI-2 mark and still diverge on things like:

• How they handle fade times at low dim levels (the 2021 job — 62 drivers were "working" but visibly stepped instead of fading below 8%).
• Whether they persist last-state memory after a power cycle (the 2022 job — corridors went dark on every utility blip because the driver defaulted to 0%).
• Sensor grouping and broadcast versus addressed commands (last spring — occupancy sensors kept every fixture on in the zone because the driver was interpreting group commands differently than the sensor's default mount).

The manufacturers aren't lying. They're each compliant. The gap is in the integration spec — the layer that nobody writes because everyone assumes it's covered.

I'm not 100% sure this is universal, but I've since talked to two system integrators who confirmed they see the same pattern: the datasheets match, the commissioning doesn't.

What it actually costs to get this wrong

Let me be concrete, because "rework is expensive" is the kind of throwaway line that never changes behavior.

The 2021 failure: $9,100 total. Breakdown was $3,400 in driver swaps (some were physically fine but needed firmware behavior the spec hadn't asked for), $2,900 in extended commissioning labor, and the rest in expedited shipping and the client-side cost of pushing their move-in date.

The 2022 failure: roughly $3,800, mostly labor, because we caught the power-cycle issue during a blackout test rather than after handover. Lucky. But the client still watched us swap 40 drivers on a Saturday.

The 2024 failure (last spring): $2,200 and — this is the one that stings — a lost follow-on contract. The client told us later the reason they went elsewhere wasn't the money. It was that they'd stopped trusting our specs.

Add it up: about $15,000 across three jobs, plus the lost work. On projects where our margin was already thin.

And that's before you count the hidden costs of replacing drivers from a lighting controls supplier that wasn't the original — because matching behavior across two vendors mid-project is its own small nightmare. Ask me how I know.

The mistake wasn't the brand. It was the process.

For a while I went back and forth between two theories. Theory A: we needed to standardize on one manufacturer for everything — drivers, sensors, controls — and never mix again. Theory B: we needed to get better at writing integration specs regardless of who we bought from.

I leaned toward Theory A. It's simpler and it feels safer. And working with a single line — say, going all-in on Tridonic for drivers, sensors, and switches — does remove a lot of the guesswork, because the manufacturers design their product families to interoperate. That's real.

But final answer: Theory B, with a dose of A. Because even within one product family, you still have to specify behaviors, not just part numbers. A DALI driver from any serious supplier will have configurable options — fade curves, power-on levels, memory behavior, group handling. If you don't write those into the spec, the default config is whatever the factory set, and the factory didn't know your corridors have windows.

Even after deciding that, I kept second-guessing for a couple of months. What if I was over-engineering it? What if clients just wanted the cheapest box that lit up? Then we ran the checklist on a small pilot and caught four issues before the quote went out. That settled it.

The 11-point pre-quote checklist

This is short on purpose. The analysis above is the point — the checklist is just the residue.

1. Protocol version, not just protocol name. DALI, DALI-2, D4i are not interchangeable. Write the version.
2. Fade behavior at the low end. Specify the dim curve and the minimum output level the project expects.
3. Power-on state. Memory, fixed level, or off — pick one, per zone.
4. Group vs. address behavior. Confirm how sensors broadcast versus how drivers interpret.
5. Sensor sensitivity and hold time defaults. Don't let the factory decide.
6. Daylight harvesting thresholds. Written down, in lux, per orientation.
7. Driver-sensor pairing tested at spec stage. Not at commissioning. Get samples if the project justifies it.
8. Warranty terms across mixed brands. If two suppliers touch the same zone, who owns the failure?
9. Programming tool availability. Can your integrator actually configure this driver's behavior, or is it locked to a proprietary toolchain?
10. Replacement lead time for the exact SKU. Not the family — the SKU.
11. Total landed cost, including optional features. See below.

A quick word on pricing, because this is where projects quietly bleed

I've learned to ask "what's not included" before "what's the price." The 2021 quote looked $600 cheaper than the alternative. Then programming labor, firmware updates, and two extra site visits added roughly $4,000. The cheaper quote wasn't cheaper.

For LED drivers, the publicly listed unit price is rarely the real number. Programming, configuration, and integration support typically add 15–40% to the line-item cost of a project (based on my own project records from 2021–2024; your numbers will vary by scale). The vendor who lists those costs upfront — even when the total looks higher — usually ends up costing less by handover.

This isn't a knock on any specific supplier. It's a knock on the habit of comparing unit prices on components that were never really components-only purchases.

Where this lands

My specs are longer now. They take about 20% more time to write. On the last four projects (roughly $180K in combined driver and controls spend), the checklist caught issues on three of them before the PO went out. No rework. No escalations.

I haven't run this at scale long enough to promise it works everywhere — I learned most of these lessons between 2019 and 2024, and the standards and product landscape keep moving. Verify current DALI-2 and D4i requirements with the DALI Alliance before locking a spec; verify driver features with the manufacturer's current datasheet, not last year's PDF.

But the core lesson holds. The specs that fail aren't the ones with the wrong part number. They're the ones that never wrote down what the part was supposed to do. Get that on paper, and the rest gets boring — which, for a spec, is exactly the goal.

Prices and costs cited are from my own project records, 2019–2024, and are for illustration only. Verify current rates and standards before budgeting or specifying.