Practical answer
Start with scene behavior, device ownership and interface boundaries
DMX512 is commonly considered where rapid channel-level scene data and show-style effects are required; DALI is commonly considered for addressable lighting devices, groups, scenes and status within a defined application system. Neither label specifies the full system. Freeze who owns the controller, gateways, network, addressing, emergency interfaces, time schedules, sensors, failure states and commissioning files before selecting compatible products.
Decision matrix
| Site condition | Specification response | Approval evidence |
|---|---|---|
| Dynamic facade sequences | Define channel count, refresh behavior, universes, repeaters, isolation and show ownership | DMX topology, patch, scene file, fail-state test and handover backup |
| Addressable architectural groups | Define DALI device types, bus limits, groups, scenes, gateways and diagnostics | DALI topology, address schedule, compatibility evidence and commissioning export |
| Mixed building and show control | Create a gateway responsibility matrix and prohibit ambiguous duplicated commands | Interface control document, cause-and-effect test and owner sign-off |
Selection and verification workflow
- Write every required scene, sensor, schedule, override and failure behavior.
- Assign ownership for controllers, buses, gateways, networks and field devices.
- Freeze topology, capacity, addressing, isolation and cable requirements.
- Bench-test representative drivers, controllers and gateways using the offered firmware.
- Commission, back up, label and hand over editable files with access credentials.
Limits and responsibility boundaries
- Protocol compatibility does not prove smooth dimming, color behavior or system interoperability.
- Emergency and life-safety interfaces require the appointed specialists and applicable rules.
- A proprietary gateway can create long-term access, licensing and replacement constraints.
Evidence to request before approval
Treat a catalogue statement as a screening input, not final proof. Every supporting file should identify the same offered model, construction, optic, driver, finish and control configuration, with revision and test-scope details that the appointed team can review.
- Current protocol compliance or compatibility evidence for each offered device.
- System topology, channel or address schedule and capacity calculation.
- Gateway interface matrix and cause-and-effect schedule.
- Representative bench-test record including low-level and fail-state behavior.
- Commissioning export, editable scene files, backups, passwords and operator handover plan.
RFQ input checklist
Comparable quotations need one controlled input schedule. Give every bidder the same geometry, environment, document scope, exclusions, acceptance route and commercial assumptions before price is compared.
- Country, city, project stage, application zones, quantities and target approval date.
- Exact mounting, voltage, CCT, optic, output, control protocol and environmental exposure.
- Required drawings, photometric files, material declarations, reports and certificate scope.
- Sample or mock-up method, acceptance owners, deviations, revision control and sign-off record.
- Packing, spares, delivery window, warranty responsibility and commissioning expectations.