COMMERCIAL LIGHTING SUPPLY / TECHNICAL LIBRARY
Lighting Controls Sequence of Operations: Design & Commissioning Guide
Technical guidance for commercial lighting specification, product selection, and project planning.
Why Lighting Control Behavior Matters More Than Individual Devices
A meeting room goes dark during a presentation. The sensor works when someone walks through the door, the wall station responds, and the daylight sensor reports a plausible value. Each component can function while the room still behaves incorrectly. The unresolved issue is the relationship between inputs: what should happen after someone manually turns the lights off, how long that choice persists, and which event is allowed to change it.
A lighting sequence of operation turns those questions into requirements that can be programmed and tested. Write it before comparing commercial lighting controls, then keep it with the project records as equipment and settings change. The sequence should reflect the building’s actual use, selected equipment and applicable requirements—not a generic programming preset.
Turn Lighting Design Intent Into Clear Operating Rules
“Provide comfortable lighting with occupancy and daylight control” expresses an intention. It leaves the programmer to decide whether arrival turns the lights on, whether sunlight prevents turn-on, whether a manual scene survives a vacancy event, and what happens after a power interruption.
The Minnesota Luminaire-Level Lighting Control Initiative’s sequence guidance describes the sequence as the technical development of the control intent narrative. It recommends preparing the document early and shows that prose, condition-and-response tables, and diagrams can work together. Establish an author, an owner decision-maker, and a party responsible for verifying each requirement. Responsibility does not become clear merely because a controls vendor is involved.
Record the project’s applicable energy-code edition, jurisdiction, occupancy, alteration scope, and any exceptions in a separate design-basis section. Have the responsible designer establish required functions and limits. A manufacturer’s programming menu describes available behavior; it does not establish which choices are permitted for this project. Emergency and other specially designated lighting require their own reviewed treatment.
Define Control Zones, Devices and Responsibilities
Start with a marked plan. A room name alone is insufficient when its perimeter row, interior row, presentation lights, and emergency-designated luminaires have different responses. Give each group an identifier that appears consistently on the drawing, equipment schedule, programming interface, and test report.
| Record | What the project team must resolve |
|---|---|
| Controlled output | Which luminaires or circuits belong to the group, including any exclusions? |
| Input ownership | Which sensor, station, schedule, or external command can affect it? |
| User action | What can occupants change, and how can they restore the normal state? |
| Timing | Which event starts, resets, cancels, or completes each timer? |
| Persistence | Which settings survive vacancy, schedule changes, communications loss, or power restoration? |
| Acceptance evidence | Which observation, setting export, or measurement proves the response? |
Distinguish a device address from the zone’s permanent name. Replacement hardware may receive a different address while the room and its requirements remain the same. Retain the relationship between the two in the final records.
Specify Occupancy and Vacancy Behavior Precisely
Do not treat “occupancy sensor” as a complete operating instruction. In Lutron Application Note 536, the glossary distinguishes automatic-on occupancy operation from manual-on vacancy operation. It also describes ambient-light-dependent turn-on and a setting governing manual-off behavior while people remain present. Those are capabilities of the documented product family, not promises about every sensor.
When evaluating occupancy sensing equipment, translate the requested behavior into specific supported functions. Detection technology and coverage remain separate questions; a comparison of PIR and microwave sensing helps frame the field trial without deciding the sequence for the owner.
Document How the System Responds to Each Event
Consider a meeting room with manual scene selection, occupancy sensing and daylight control. The following example shows how to document the intended response to common events. Timeouts, illumination targets and permitted operating modes must be established for the specific project.
| Event or condition | Proposed response to resolve | Acceptance question |
|---|---|---|
| First arrival into a vacant room | Remain off until the user requests lighting, if this operating mode is selected and permitted. | Does entry alone leave the controlled group off? |
| User selects a presentation scene | Apply the scene to its named groups; identify whether daylight adjustment remains active. | Do only the intended groups change, and can the user return to normal? |
| User turns the room off while occupied | Define whether continued motion may relight it and what resets that choice. | Does a second person’s arrival cause an unwanted restart? |
| Last detected activity ends | Start the approved vacancy timer; state what activity resets it and what happens at expiry. | Does observed behavior match the documented timer and reset conditions? |
| Daylight changes during occupancy | Adjust only the assigned daylight group within its approved operating range. | Does the interior group remain independent, and is the response stable? |
| Scheduled unoccupied period begins | Apply the approved after-hours behavior and define any permitted local override. | Does the override expire or reset as intended? |
| Power or communications returns | Use the documented recovery state for this system and project. | Are groups, time schedules, and retained settings correct afterward? |
Next, test combinations. A single-input table can conceal conflicts. What happens when a scheduled transition occurs during a manually selected scene? Does a daylight command raise a group that the user explicitly switched off? Does a temporary override survive midnight? Resolve these cases in writing rather than allowing the last received command to become an accidental design rule.
For each collision, state the winning behavior, its duration, and the event that restores normal operation. Confirm that the proposed priority can actually be implemented. Do not invent a universal priority hierarchy: product architecture, project requirements, and life-safety design matter.
Confirm That the Selected Controls Can Deliver the Sequence
Send the same event table to each controls supplier. Ask for a supported response, a limitation, or a proposed alternative for every row. “Daylight capable” is not a sufficient answer to a request for independent perimeter-row dimming with a particular manual-override interaction.
Compare daylight control devices against the intended sensing arrangement and calibration method. Reserve detailed calibration procedures for daylight zone acceptance. Likewise, a desired dimmed state is not evidence that a driver and controller are electrically compatible; carry that question into the driver-and-control compatibility review.
Require the quotation to distinguish hardware supply, startup, programming, functional testing, owner training, and subsequent adjustment. These are different deliverables. As a manufacturer-specific example, Acuity’s commissioning walkthrough service description, revised June 9, 2020, includes demonstration against project requirements, a field report, and updated sequence and programming database where applicable. That document illustrates a defined service scope; it is not proof that those services accompany another system or a current quotation.
Commission Every Required Response—and Its Exceptions
“Controls operate correctly” cannot distinguish a successful installation from an unresolved complaint. Use one test record per requirement: zone, initial state, stimulus, expected result, observed result, relevant elapsed time, settings version, tester, date, and disposition. State any measurement method and tolerance before testing where a quantitative acceptance criterion is needed.
For a manual-off test, record that the room was occupied, lighting was on, the user pressed off, and additional activity was introduced. Observe whether the lighting stayed off for the intended condition. If it relights, record the failure without immediately changing several settings. Identify the cause, revise the controlled configuration, and repeat the failed test plus affected interactions.
Coordinate safe testing with qualified personnel. Occupants should not be asked to interrupt electrical supplies or manipulate emergency equipment. Simulated conditions, scheduled access, and any specialist testing belong in the commissioning plan.
Functional acceptance also does not establish a savings percentage. A compliant response can operate for more or fewer hours than assumed in a financial estimate. Keep baseline and post-installation energy evaluation separate from proof that the required control events work.
Keep the Final Sequence Useful After Installation
At handover, reconcile the approved sequence, zone plan, final settings, unresolved exceptions, test results, and recovery instructions. Identify who may change schedules and who maintains access credentials. Preserve an editable backup where the system supports one, with a readable copy of the operating rules that does not depend on logging into a particular application.
When the owner later changes a room’s use, revise the sequence and retest affected behavior. A well-defined sequence makes commercial lighting controls easier to specify, commission and maintain. When every event has an expected response—and every response can be tested—facility teams gain a system that behaves predictably through everyday use, schedule changes and future renovations.