AI lighting control: where manual logic breaks
Classic automation relies on schedules and relays: a panel turns a group on at the start of a shift and turns it off on a timer, while a motion sensor only extends the timer.
AI lighting control solves a different problem — not "turn on by the clock," but keep light where people need it right now and not waste it on empty zones.
Occupancy sensor is a poor source of truth. False sensor triggers are caused by airflow from supply ventilation, heat from equipment, movement behind a glass partition — and the group stays on for the entire hold timer even though no one is in the room.
The opposite error occurs just as often: a person sits motionless at a monitor, the sensor does not see them, and it turns off the light in an occupied office.
Schedule vs. occupancy is the main conflict. During peak hours, adjacent zones are unevenly occupied: somewhere it is fully seated with dimmed light, while nearby an entire group is on in an empty meeting room.
Manual scenarios do not fix this — they have to be rewritten after every furniture rearrangement, while AI lighting logic relies on the current occupancy picture, not on a fixed list of groups and hours.
There is enough signal for this: lighting control based on daylight, occupancy, and workplace utilization sensors is consolidated into a single model that learns from actual zone usage and gradually eliminates both overlighting and dark spots. Below we break down how this is addressed.
What adaptive lighting logic changes at a site
It is convenient to measure the effect of adaptive logic by four values: the share of lighting in the site's total consumption, the number of false activations per day, the response time to occupancy changes, and the share of activations in the "light not in the right place and not at the right time" class. These are exactly the metrics we capture before and after implementation.
Zones that respond to people, not time
Lighting is divided not by floors and panels, but by usage scenarios: corridor, meeting room, warehouse section, group of workstations. Each zone gets its own occupancy sensor and daylight threshold — light turns on where a person is, not where the loop boundary runs.
The key check is false activations. While one pass raised the lighting of an entire wing, the count ran into dozens per day; after zoning, 2–4 luminaires respond with a 5–10 minute hold and threshold hysteresis.
Response to occupancy fits within seconds instead of a half-hour timer, and "light not in the right place and not at the right time" failures become isolated.
Smooth brightness control instead of abrupt switching
A sudden jump to full brightness from darkness is both uncomfortable for the eyes and wasteful. The dimming curve brings the level up to working brightness in 1–2 seconds, and when a person leaves, it first lowers it to standby 10–20% and only then turns it off.
Near windows, brightness is dimmed based on the daylight sensor, so during the day the zone by the glass runs at minimum.
Lighting savings without losing comfort come not from switching off, but from refusing to light empty zones: consumption drops by a third or more with the same illuminance at workstations.
Operating modes: local logic, cloud, hybrid
The choice here is not about the algorithm's "smartness," but about where the decision is made and what happens to the site when the channel is lost.
Local lighting logic lives on a controller in the panel, cloud lighting analytics calculates models from aggregated telemetry, and a hybrid control scheme divides responsibility loops between them. Below is when each option is appropriate and what you pay for it.
| Option | When it fits | Limitations |
|---|---|---|
| Local logic | A single site with a stable set of scenarios: parking, warehouse, workshop, stairwells | The model does not see context between sites; changing scenarios requires a visit or distributing configuration to each controller |
| External analytics loop | Many similar sites, need site comparison, anomaly detection, operations reporting | Response depends on the channel; if communication breaks, scenarios freeze in their last state |
| Mixed scheme | A distributed network where some points are critical and some are optimized | More complex configuration: you need to explicitly separate which rules stay on site and which come from outside |
When a site must operate without external communication
Autonomous operation when communication is lost is a mandatory requirement for underground parking garages, escape routes, refrigeration and production areas.
The controller stores scenarios and thresholds in its own memory, continues polling occupancy and daylight sensors, and switches lighting groups without the external loop.
Telemetry in this case is written to a local queue and uploaded after the channel is restored, so a data gap does not turn into a reporting gap.
What goes to the external loop and what stays on site
The decision to "turn on the light" stays at the site — it requires a predictable response and cannot depend on the network.
What goes to the external loop are site-level aggregates, anomaly detection, comparison of consumption profiles, and recalculation of recommended scenarios.
This separation provides network manageability without the risk that an external service or channel will "bring down" the light: the critical loop is isolated, and optimization arrives at the site as a configuration update and is applied only after validation.
How implementation proceeds: from point audit to handover
Implementation is divided into stages with a verifiable result after each step. The order is not rearranged: threshold setup makes sense only after zones and groups are fixed.
Audit of existing infrastructure
First we measure what is already installed: motion and daylight sensors, panels, power lines, actual loads by group. A lighting system audit shows where points produce false activations and where there is not enough data for the model.
- Measurement and audit of points — which sensors work, how groups are wired, which panels are available for control.
- Zone and group scheme — mapping each group to a scenario: corridor, stairwell, parking, warehouse, and the logic of transitions between them.
- Sensor threshold setup — activation levels, off delays, sensitivity for the actual lighting background.
Testing on real people flow
Thresholds derived from documentation almost always require adjustment: on live flow you can see false activations and "dark windows" when the light goes off before a person has left the zone.
- Lighting commissioning — running scenarios during peak hours and in shoulder seasons, adjusting delays based on real routes.
- Live flow testing — a 24-hour run across all groups, comparing activation logs with staff rounds.
- Personnel training — procedure for manual mode and rollback to standard control.
- Handover — documentation, access, responsibility boundaries, support period.
At the output, the customer receives a system where the algorithm can be disabled with one command without loss of lighting.
What the customer retains after implementation
We hand over the system not as an archive of files, but as a working kit that the operations service can use to handle most tasks on its own.
All documents are tied to a specific site and updated when the configuration changes — otherwise, six months later no one will remember why the scenario on the third-floor corridor triggers exactly that way.
- Group and address map — which luminaire is tied to which panel, line, and address, and which sensor zone controls it. Without it, replacing one device turns into trying one option after another at the site.
- Scenario matrix — scenario, trigger condition (motion, daylight level, schedule), target brightness, and timeouts. Operations edits the values themselves, without calling a commissioning engineer.
- Lighting as-built documentation — zone, panel, route, and labeling diagrams brought in line with the actual installation, not the original design.
- Operations procedure — actions when a sensor or line fails, switching a zone to manual mode, returning automation, escalation procedure.
- Instructions for the operations service — step-by-step and brief: where to view status, how to switch modes, how to submit a request.
- Inspection protocol — which zones, scenarios, and failure classes were tested at handover, with results and dates of repeat runs.
Access rights and operations roles procedure
Roles are fixed explicitly: the dispatcher sees status and switches scenarios, the operations engineer edits sensor setpoints and zone boundaries, and full access to the configuration remains with one or two people.
Every change goes into a log with author and time, and the reference configuration is stored as a separate copy — rollback to it takes minutes, not a night-long incident investigation.
Case study: office floor and warehouse on one logic
The site is an administrative floor and a dry storage warehouse under one roof. Lighting there was already controlled, but by two independent loops: in the office — zone switches, in the warehouse — a panel with manual groups that the duty operator switched before shifts.
We brought everything into one addressing bus DALI: every luminaire and sensor has an address and its own zone, and scenarios are described once and inherited by both loops.
Before implementation, the picture was predictably poor. Light in meeting rooms and the far rack rows burned almost 14 hours a day — regardless of whether anyone was there.
Insufficient illumination in aisles was confirmed by regular complaints, and duty personnel manually switched groups before and after each shift.
What the before-and-after measurement showed
| Metric | Before | After |
|---|---|---|
| Burn hours in empty zones | 62% of the day | 8% of the day |
| Complaints about insufficient light | 9 per month | 1 per month |
| Manual interventions by duty operator | more than 40 per month | emergency mode only |
The key was not the presence of sensors, but the transition rule: a zone without motion goes to a low power level rather than switching off — people stopped complaining that it "went dark right next to them." Daylight sensors cut the upper level near window lines during the day, so the "glare" issue went away too. New rack rows are added to the same logic, without rewriting scenarios.
How is a schedule different from a sensor-based scenario?
A schedule is a deterministic loop: group switching is tied to the calendar and astronomical time, the result is reproducible and does not depend on sensor state.
The price for this is blindness to reality: the light stays on in an empty hall and does not turn on when a shift runs past schedule.
Occupancy-based scenarios work from events: motion and daylight sensors form an occupancy zone, and the hold time prevents the light from going out while a person sits motionless.
The activation threshold and hold time are set separately for the corridor, meeting room, and warehouse — otherwise we get either flickering or a lit empty aisle.
In practice, the loops do not compete but nest: the schedule sets the base mode and serves as the safe state when communication with sensors is lost, while sensors refine the picture within permitted windows.
The DALI luminaire addressing standard allows manual override to be limited to one group rather than the entire floor.
Manual control priority is designed explicitly: a command from the operator or wall switch overrides automation for a specified interval, after which control returns to the scenario. Thus, the emergency exit remains lit regardless of what the automation decided.
Technical questions asked before kickoff
The operations service asks questions earlier than designers: not about algorithms, but about how the system behaves in a real building. Below are four concerns that come up in site meetings before kickoff.
What happens to lighting if external communication is lost?
Control logic lives on the local controller: the schedule, sensor response, and standby scenes continue to work without the channel.
External communication is needed for analytics and model updates — after it is restored, accumulated events synchronize, and no discrepancies remain in the log.
Will existing motion sensors have to be replaced?
Not necessarily. First comes an inventory: what is installed, what output signal it provides, and whether the coverage zones fall into the required loops. A discrete output is connected through an interface module; bus communication is direct if the equipment supports DALI. Replacement is needed only where the sensor does not provide the required zone resolution.
How do you cut out false activations?
The decision is made based on a combination of factors: motion, daylight level, hold time, and zone mapping. The off delay and threshold hysteresis remove activations from airflow, glare, and reflections. The share of false activations is recorded at acceptance as a measurable indicator.
Who is responsible for setup after handover?
Thresholds and scenes remain in the site configuration, not in our system — the operations service can change them themselves.
We hand over diagrams, a change procedure, and train personnel; post-handover support operates as a separate mode with an agreed response window when the logic needs to be adjusted based on actual operation.
Let's discuss your task and come back with a plan
To discuss the task substantively and ensure the lighting project estimate does not turn into a "market average," we need a minimum of inputs. We will gather them in one conversation — without long correspondence and week-long clarification cycles.
- Layout of rooms or zones: where the luminaires are, how lines are wired, and whether control groups already exist.
- Type of sensors — occupancy, daylight, motion — and via which interface they provide readings.
- Current control loop: panels, relays, gateways, what is already available remotely, and what will need to be added.
- Scenarios needed in practice: working hours, standby mode, zones with increased light level requirements.
- Installation and permit constraints: night work windows, restricted zones, who provides access to the site.
- What we consider the result: share of automatic activations, absence of false activations, and a consumption report per shift.
In response, we provide an integration diagram with connection points, a staged implementation plan with a verifiable result at each stage, and a scope of work with responsibility boundaries.
We separately spell out what remains on the side of the installation organization and what we cover — so that control logic does not hang between contractors.
Describe the task in two or three paragraphs — we will come back with an estimate and a plan.
