If a smart lighting vendor tells me they do DALI drivers, Zigbee sensors, and compliance documentation — all in-house — I get more worried than I do when their quote is high. The first time that thought hit me was during a supplier audit, watching a company spend three slides on their "full-stack lighting platform." Six weeks later, their sensor orders were quietly being fulfilled by a third-party OEM whose spec sheet we'd never seen.
I'm the quality and brand compliance manager at a lighting manufacturer — our customers are mostly system integrators and project specifiers. I review every SKU before it reaches anyone: spec cross-check, sample testing, compliance file verification. Roughly 200 items pass through my desk annually. Between 2024 and 2025, I rejected about one in three first deliveries, for everything from color temperature drift to DALI interface mismatches.
Bottom line: I check a supplier's boundaries before I check their catalog.
1. A DALI driver and an LED driver are not the same product — even when vendors pretend otherwise
The basic difference: an LED driver converts AC to DC. A DALI driver does that plus speaks a specific protocol, follows a specific dimming curve, and handles a specific addressing scheme. Being good at general LED drivers doesn't automatically make you good at DALI.
In 2023 we received a batch of 2,400 drivers advertised as "DALI-2 compatible dimming." The spec required a 1% dimming floor and an IEC 62386-207 curve. We sampled eight units, and four of them went visibly non-linear once they were on the rig — more than 30% output deviation at the 10% dimming position. Normal tolerance is under 5%. The vendor called it "within industry standards" (which, honestly, felt like a stretch). We rejected the batch, they redid it at their cost, and now every contract includes dimming curve test requirements.
From the outside, a vendor who says they "do all drivers" looks simpler. The reality is you end up with a team that handles base LED conversion well and guesses at the DALI side. We started benchmarking against Tridonic DALI driver spec sheets for dimming curve baselines — not as a label preference, but because their curve data is documented to a depth that saves real argument time. Same logic for the standard Tridonic LED driver: if the driver is a system-critical component and not a consumable, specification transparency is the dividing line.
2. Motion sensor OEM work and Zigbee distribution are two separate businesses
Most vendors that claim "we build our own sensors" are, at the project level, buying them from someone else. That's not automatically a deal-breaker. What is a problem is pretending it's an internal capability — because when something breaks, you're no longer dealing with one engineering team, you're dealing with three companies trading emails.
In 2024 we had an office retrofit where the recommended "integrated package" sent the motion sensor OEM work through two subcontract layers. It landed with a factory we couldn't even get radio frequency test data from. The specified sensitivity was 10 meters. On the actual corridor it was under 5. Zigbee joining latency bounced between 400 and 900 milliseconds (ugh). It took the integrator two weeks to figure out the sensor firmware version didn't match the distributed stack.
We changed our process after that. When reviewing a Zigbee distributor chain, my first question is "who's the motion sensor OEM." If the answer is vague, I treat that as a red flag. The good distributors tell you the name and share whatever test reports exist. The ones that hedge tend to have more surprises downstream.
3. Compliance isn't a department that signs off — it's a specialty of its own
Here's the counterintuitive part. Smart lighting compliance requirements aren't just a set of certificates you scan at the end: EN 61347-1 and -2-13 decide whether the driver can ship, EN 55015 decides whether it passes EMC, and DALI-2 certification determines which layer of the stack you can sign off on. Any one of those going sideways stalls a project.
The broader a vendor's claim, the more likely compliance gets thin — because each market and application has its own moving standard, and a "we handle everything" team can't track all of them at once. We flipped our review: we audit compliance documentation by specialty. The driver maker has to stand behind the DALI-2 certification. The sensor OEM owns radio frequency and motion detection specs. The channel has to trace which production line each batch came from.
For what it's worth, FTC advertising guidance (ftc.gov) requires that performance claims — things like "40% energy savings" — be substantiated. We now require suppliers to give testing conditions and source data in the spec sheet, not just a conclusion. That one filter eliminates significant numbers of the "we do everything" crowd.
"But isn't one-stop easier?"
That's the pushback I hear most, and I get it. Fewer contacts, fewer contracts, fewer arguments. It saves the small stuff in procurement. It costs you the big stuff in execution.
When something actually goes wrong, the classic one-stop response goes like this: the driver side points at the DALI master's commissioning logs, the sensor side points at the Zigbee stack's firmware from the distribution channel, the compliance side says the standard reads that way. You're holding three conflicting explanations and end up coordinating three parties you've never met. Convenience up front, cost on the back end.
So my position hasn't moved: I trust a specialist who knows their limits, not a generalist promising everything. The vendor who says "this isn't our strength — here's who does it better" tends to be more reliable in the areas they do claim. I haven't met many of them (that's the whole problem), but every one has renewed at a very high rate.
Bottom line: you're not looking for someone to build all of it. You're looking for someone who knows when to stop and call the right specialist.
