Receiving a dimming command is only the beginning of a reliable DALI installation. Recent connected-lighting work makes the case for collecting better information at the point of use, but engineering value appears only when the information survives the path from device to decision to actual luminaire behavior. That path needs a defined installation context, a named control owner, and a record of what each component is known to do.
This article uses the current product record as a practical starting point. KL70C-PDiiV1 lists DALI, PUSH, 1–10V and PWM interfaces, a 2–100% dimming range, 220–240Vac input and less than 0.5W standby. KL60C-DiiP lists DALI and PUSH with the same input range and dimming range. Their usable power still depends on the selected current and LED voltage. The selection method is deliberately conservative: use published parameters to constrain a design, and use documented integration information plus site testing to validate every behavior that is not explicitly stated.
The engineering method is discussed against real models. Diagrammed examples and conceptual connections name their operating boundaries. Confirm product parameters against the current model, variant, and applicable technical documentation.
Start with a controllable system boundary
Receiving a dimming command is only the beginning of a reliable DALI installation. A project should begin with the operational question rather than a feature name. Identify the people, equipment, light level, response time, and maintenance outcome that the space needs. This makes it possible to distinguish a useful requirement from a marketing label.
A DALI interface in a product table does not prove D4i data capability, wireless connectivity, tunable-white behavior, certification of a family variant, or compatibility with every controller. Treat this distinction as a design input. It prevents a system diagram from assigning responsibilities to a product before its actual interface, documented function, and configuration route have been verified.
Keep the evidence attached to the decision that it supports. Record the model and variant, physical location, configuration revision, wiring or network condition, date, observer, measured result, and any exception. When a result changes after a setting, installation, or firmware change, preserve both records. This gives the next engineer a way to distinguish a changed requirement from a changed system response.
Read the driver parameters at the chosen current
KL70C-PDiiV1 lists DALI, PUSH, 1–10V and PWM interfaces, a 2–100% dimming range, 220–240Vac input and less than 0.5W standby. KL60C-DiiP lists DALI and PUSH with the same input range and dimming range. Their usable power still depends on the selected current and LED voltage. Read each field together with its condition and unit. A current setting, voltage window, maximum mounting height, standby figure, or IP rating has meaning only in the context of the specific product variant and installed assembly.
Create a short “known / confirm / test” table for the project. Published data belongs in known; exact firmware, wiring, protocol, mounting construction, load, and operating condition belong in confirm or test until evidence moves them into the known column.
Keep the evidence attached to the decision that it supports. Record the model and variant, physical location, configuration revision, wiring or network condition, date, observer, measured result, and any exception. When a result changes after a setting, installation, or firmware change, preserve both records. This gives the next engineer a way to distinguish a changed requirement from a changed system response.
Work backward from the LED load
Calculate the LED load at the selected current, verify the full LED voltage range, validate one luminaire on a bench, then add a small addressed group before introducing sensors, switches, scenes, and upstream systems. Keep the first test deliberately small, with documented versions and a stable environment. A controlled pilot produces evidence that can be understood later; a full installation with several simultaneous changes often produces symptoms without a clear cause.
For every input, write the expected result and the owner of the decision. A sensor can report an observation, a controller can apply policy, and a driver or other actuator can execute a result. When two devices can issue conflicting decisions, define priority before the system reaches site.
Keep the evidence attached to the decision that it supports. Record the model and variant, physical location, configuration revision, wiring or network condition, date, observer, measured result, and any exception. When a result changes after a setting, installation, or firmware change, preserve both records. This gives the next engineer a way to distinguish a changed requirement from a changed system response.
Separate DALI, DALI-2, and D4i claims
Record full output, minimum output, off, power restoration, addressing, grouping, manual override, and communication-loss behavior. Repeat the exact process with a recoverable configuration backup. Run the scenarios in a fixed order and keep raw observations where possible: measured light, input power, device status, event time, configuration revision, and room condition. One convincing demonstration is not an acceptance method; repeatability is.
Fault behavior deserves the same attention as normal behavior. The system should state whether information is current, stale, missing, or invalid, then apply the approved fallback. A communications failure must not silently masquerade as a normal vacant or healthy state.
Keep the evidence attached to the decision that it supports. Record the model and variant, physical location, configuration revision, wiring or network condition, date, observer, measured result, and any exception. When a result changes after a setting, installation, or firmware change, preserve both records. This gives the next engineer a way to distinguish a changed requirement from a changed system response.
Commission in layers instead of all at once
Use results to refine the zone, operating policy, and maintenance plan rather than to force a single universal setting. Installation changes, furnished spaces, varying daylight, user behavior, and electrical conditions often matter more than a nominal figure quoted without its test boundary.
Where an external system is involved, preserve an explicit interface contract: device and firmware identification, signal or data meaning, addressing, timeout rule, safety boundary, and recovery behavior. That contract is what keeps a working pilot from becoming an opaque deployment.
Keep the evidence attached to the decision that it supports. Record the model and variant, physical location, configuration revision, wiring or network condition, date, observer, measured result, and any exception. When a result changes after a setting, installation, or firmware change, preserve both records. This gives the next engineer a way to distinguish a changed requirement from a changed system response.
Capture acceptance evidence that can be repeated
A field-ready design connects a known load to a known current setting, gives each control role a clear owner, and leaves a test record another engineer can reproduce. Handover should include drawings, configuration exports, parameter selections, tested scenarios, the original site conditions, and a short sequence a technician can repeat after replacement or refurbishment.
The purpose of the document is not to claim that technology eliminates engineering judgement. It is to make that judgement visible, testable, and easier to carry forward as the project, the building, and the installed product set evolve.
Keep the evidence attached to the decision that it supports. Record the model and variant, physical location, configuration revision, wiring or network condition, date, observer, measured result, and any exception. When a result changes after a setting, installation, or firmware change, preserve both records. This gives the next engineer a way to distinguish a changed requirement from a changed system response.
Products and key parameters
These fields come directly from the current product library. Open the product page to confirm complete parameters and the applicable product record.
Smart DriversKL70C-PDiiV1View full product parameters - Dimming interface
- Primary PUSH, secondary 1-10V, primary PWM, DALI
- Dimming range
- 2%-100%
- Input voltage
- 220-240Vac, 50Hz /60Hz
- Standby power consumption
- <0.5W
- Work efficiency
- 87% Max. @230Vac
- Output current/voltage/power
- 700mA / 9-66Vdc / 46.2W 800mA / 9-66Vdc / 52.8W850mA / 9-66Vdc / 56.1W 900mA / 9-66Vdc / 59.4W950mA / 9-66Vdc / 62.1W 1000mA / 9-66Vdc / 66W1050mA / 9-66Vdc / 69.3W 1150mA / 9-61Vdc / 70W1200mA / 9-58Vdc / 70W 1250mA / 9-56Vdc / 70W1300mA / 9-54Vdc / 70W 1400mA / 9-50Vdc / 70W
- Safety Standard
- EN61347-1, EN61347-2-13
Smart DriversKL60C-DiiPView full product parameters - Dimming interface
- Junior PUSH, DALI
- Dimming range
- 2%-100%
- Input voltage
- 220-240Vac, 50Hz /60Hz
- Standby power consumption
- <0.5W
- Work efficiency
- 86% Max. @230Vac
- Output current/voltage/power
- 350mA / 9-71Vdc / 24.8W 500mA / 9-71Vdc / 35.5W550mA / 9-71Vdc / 39W 650mA / 9-71Vdc / 46W700mA / 9-71Vdc / 49.7W 750mA / 9-71Vdc / 53.25W850mA / 9-70Vdc / 60W 900mA / 9-66Vdc / 60W1000mA / 9-60Vdc / 60W 1050mA / 9-57Vdc / 60W
- Safety Standard
- EN61347-1, EN61347-2-13
References and editorial note
Sources were reviewed on 2026-09-07. Recent industry sources and basic technical references are listed separately. The article is original engineering commentary grounded in the current product record, not a translation of the cited source. Any calculation or recommendation does not represent completed product interoperability testing.
