Key takeaways
- Give every zone, scene, sensor and controlled load a stable reference.
- Describe observable behavior rather than relying on labels such as smart, automatic or dimmable.
- Record normal operation, manual override, occupied and unoccupied states, startup and recovery behavior.
- Keep desired behavior separate from model-specific compatibility and supplier-confirmed settings.
- Link every change to an owner, revision, test step and acceptance record.
1. What should a commercial LED lighting control schedule include?
A commercial LED lighting control schedule should define each zone, the equipment it controls, the required action for every input, the expected output state, timing and transition behavior, manual overrides, recovery after power loss, and the evidence needed for acceptance. Freeze the schedule revision before programming, then use the same zone and scene references during commissioning.
The schedule should be readable by the consultant approving the design, the contractor wiring the system, the programmer configuring it and the facilities team receiving it.
| Schedule field | What to record | Approval boundary |
|---|---|---|
| Zone identity | Unique reference, location and served lighting | Match drawings, labels and commissioning sheets |
| Controlled equipment | Luminaire, LED strip run, track section, driver or interface reference | Exact model and revision remain product-specific |
| Input and action | Defined trigger, on/off state, level, scene or sequence | Use observable language |
| Timing and override | Delay, fade, hold, timeout and permitted manual action | Values require project approval |
| Recovery | Expected state after power or communication interruption | Verify with the approved equipment chain |
| Acceptance evidence | Witness, screenshot, photograph, setting record or measured result | Separate observations from measured data |
2. Build one controlled identity for every zone
Use the same zone references across drawings, schedules, labels, controller configuration and test sheets. A name such as Lobby lights may be too broad if separate strip runs, spotlights, track modules or other circuits behave differently.
For each zone, identify the connected load, driver or power supply, controller or interface, input devices and the responsible circuit or feed. Record approved substitutions and revisions. A successful programming demonstration has limited value if it cannot be traced to the installed equipment.
- Unique zone and scene references
- Connected lighting and driver identity
- Controller, interface and input-device reference
- Drawing, schedule and revision links
3. Describe scenes as observable results
Scene names such as Welcome, Cleaning or After Hours do not define behavior by themselves. For every scene, list the participating zones, required state or level, transition behavior, permitted user adjustments and the condition that ends or replaces the scene.
Do not invent a dimming percentage, fade time or low-level performance. These are project requirements that must be checked against the exact driver, controller, load and configuration.
| Scene question | Record |
|---|---|
| What starts it? | Named keypad action, approved schedule or defined system command |
| Which zones respond? | Exact zone references, including excluded zones |
| What should users observe? | On/off state, approved level or sequence for each zone |
| Can it be changed locally? | Permitted controls and limits |
| What ends it? | Another scene, timeout, schedule or authorised override |
4. Define sensor, override and priority behavior
For presence, absence, daylight or other sensors, record the detection area, affected zones, trigger condition, delay, output behavior, manual interaction and reset route. Note who approves sensor position and who can change settings after handover.
State which command has priority when a schedule, sensor, keypad or building system requests a different state. If the project has not approved that priority, mark it pending instead of allowing the programmer to infer it.
- Detection area and affected zones
- Trigger, delay and return behavior
- Manual override and reset route
- Command priority and approval owner
5. Record startup, interruption and recovery states
Define what the user should observe at initial energisation, after a normal shutdown, after power restoration and after a communication interruption where relevant. Include any manual action needed to restore normal operation and identify settings that must be retained in the handover package.
Recovery behavior is configuration-specific. Confirm it with the supplier or controls specialist for the exact equipment chain; do not assume that every driver, controller or gateway returns to the same state.
6. Control changes before and during programming
Freeze an approved schedule revision before programming starts. When a zone, scene, sensor rule, timing value, interface or equipment reference changes, record the old requirement, proposed change, reason, affected drawings or tests, approver and release date.
Use statuses such as draft, pending, approved, programmed, tested, failed, corrected and accepted. A verbal request or a successful demonstration in one room should not silently change the approved behavior elsewhere.
7. Turn the schedule into a commissioning record
During commissioning, test each approved input and expected output against the same zone and scene references. Record observed results separately from measured values and supplier confirmations. Log defects with an owner, due date, retest result and closure evidence.
Before handover, retain the approved schedule, final settings, zone and scene list, controller or interface references, open defects, authorised overrides and the person responsible for future changes.
- Stable zone, scene and device references
- Input, output, timing and transition requirements
- Override, sensor priority and recovery rules
- Revision, programming and acceptance owners
- Test result, defect owner and closure evidence
- Final settings and future change responsibility
Frequently asked questions
Questions buyers ask
Is a control narrative the same as a control schedule?
Not always. A narrative explains the overall intent, while a schedule maps specific zones and inputs to required behavior. Projects often need both so the design intent can be programmed and tested without ambiguity.
Should the lighting supplier define all control settings?
No single party should infer unapproved project behavior. The design team or authorised project owner defines the required outcome, while suppliers and controls specialists confirm model-specific capability, interfaces and settings for the proposed equipment.
When should the control schedule be frozen?
Freeze an approved revision before programming. Continue to record controlled changes during installation and commissioning, then issue a final accepted revision with the handover package.
What should be tested during commissioning?
Test every approved input, zone, scene, sensor rule, override and relevant recovery condition. Record the expected result, observed result, evidence, exception owner and retest status.
Does a dimmable driver guarantee control-system compatibility?
No. Compatibility depends on the exact driver, controller or interface, wiring, load, protocol or control method, configuration and required behavior. Confirm the complete proposed chain.
Talk to the product team
Planning an OEM or commercial lighting order?
Send your application, specification and destination market. We will help narrow the product and sample options.
Discuss on WhatsApp