Smart urban lighting, Sustainability
Adaptive street lighting dims a street while it is empty and lifts the light when someone moves through it. How a system decides that comes down to one of two methods. Zone-based control groups luminaires and runs each group on a pattern somebody programmed. Coordinate-based control gives every luminaire its own GPS position and lets the direction and speed of actual movement decide which lights lift and in what order. That choice decides two things: how reliably the light is there when a person arrives, and how much setup and re-tuning the network needs over its life, at intersections and irregular layouts most of all. It does not decide energy savings. Street type decides those, and coordinate-based control reaches the same savings with less tuning. Lusety builds its controllers and the HORIZON platform on the coordinate method. Municipalities and smart-city system integrators are choosing between these two methods every time they compare adaptive systems.
What makes street lighting “adaptive”?
An LED retrofit cuts energy because the lamp draws less. Adaptive control adds a second saving on top, because the light no longer runs at full output all night. Each luminaire carries a motion sensor, which is why adaptive lighting is also called motion-based or sensor-based lighting. Those sensors run around the clock, since power stays on at the luminaire even when the light itself is dimmed or off, so nothing has to be woken up first. When the street is empty the light drops, and when someone approaches it returns to full. The saving is all the hours a street would otherwise burn full power for nobody. Everything after that depends on the light actually arriving. A luminaire that lifts a second late, or not at all, leaves residents worse served than a plain timer that simply keeps the street lit, and that reliability is set by the control method underneath.
Two ways to control it: zones or coordinates
The first method is grouping. Luminaires are organised into zones and each zone runs a programmed behaviour, so someone has to define the groups, tune each pattern, and add a case for every layout that does not fit one. The second method is coordinate-based. Each luminaire is commissioned with its own coordinates, and behaviour is derived from those plus what the sensors detect, so there are no per-street dimming scenarios to author. Grouping is what most systems in the field run on, and on the streets it suits it runs perfectly well. Lusety built its adaptive control on coordinates instead, and the difference shows up fastest wherever a street stops being a straight line.
How coordinate-based control actually works
Each luminaire is commissioned with its GPS coordinates, so the system holds the real geometry of the street. The sensors watch continuously. When one of them registers movement, the direction and the speed of that movement determine which neighbouring luminaires lift and in what sequence, so someone cycling gets light further ahead, and sooner, than someone walking the same path. That handoff travels between controllers over a low-power RF mesh, each unit relaying through its neighbours to reach range, and the mesh is self-healing, so a dropped node gets routed around, so the lights behind it stay on.
The controller acts on rules it already holds, without waiting for the platform, which is why the cloud is never in the loop for a single light coming up. That on-device autonomy is what makes the coordinate response work at all, and it is covered in more depth in our piece on edge versus cloud control in street lighting. HORIZON works a layer above it: creating scenarios, interpreting what comes back from the network, and aggregating energy per street and across the whole installation.
Zone-based and coordinate-based, side by side
| What you compare | Zone-based (grouping) | Coordinate-based |
|---|---|---|
| Scenarios programmed by hand | One per group, plus a separate case for every irregular layout: intersections, crossings, junctions, dead ends | None. Behaviour is derived from coordinates plus detected movement |
| Commissioning input per luminaire | Group membership and the tuned pattern for that group | Its GPS coordinates |
| Cost of a layout change (pole added or moved) | Re-tune the affected group and any scenario that depends on it | Register one coordinate |
| Who can make that change | Whoever holds and understands the scenario configuration | A trained operator with the right role in HORIZON |
| Behaviour where movement comes from several directions | Has to be programmed case by case | Follows the direction and speed of the movement itself |
| Failure mode when a case is missed | Lights react late or not at all, and nothing reports it | Fewer hand-built scenarios, so fewer silent failure paths |
| Energy savings potential | The same, but only once every case is tuned | The same, reached with less tuning |
Why grouping struggles where streets meet
A grouping system can only do what its scenarios cover, and the hard cases are the ones that refuse to sit in a neat group. An intersection is the obvious example: movement arrives from several directions and leaves in several more, so the system has to be told what to do about each combination. Miss one and the light is late or absent exactly where a pedestrian is stepping into traffic.
What makes this compound is that the gap is silent. A case nobody wrote produces no error message: the light is simply late or absent, and the system reports nothing, because from its point of view no rule was broken. The fault surfaces as a resident complaint weeks later, if at all. That is the specific thing to test during a pilot, and it is tested at the junctions, because on the straight sections any method looks the same.
Where the savings actually come from
Savings track how much of the night a street spends empty, not which control method runs it. Parks, cycle paths and pedestrian paths are the strongest case, where adaptive control can cut lighting energy by up to 80% on top of the gain from LED, because they sit unused for hours at a time. Quiet residential streets save well for the same reason. An arterial road carrying traffic all night saves the least, because it genuinely has to stay lit. Any answer to “how much will we save” therefore starts with a question about the street. What the control method changes is how much tuning it takes to reach that number, and how quietly a mistuned case can give it back.
Setting up and changing a coordinate-based network
Commissioning a luminaire in HORIZON means registering its controller and confirming the coordinates and the street it belongs to. There is no group to place it in and no pattern to write for it. That is the whole reason the setup effort is lower.
When a pole is added, the new controller arrives with its own coordinates and starts taking part in the handoff with its neighbours. None of those neighbours needs re-tuning, because none of them was carrying a hand-written pattern that a new pole would invalidate. When a pole is moved or taken out, the same holds, and the mesh routes around the gap. HORIZON uses role-based access, so this work sits with a city’s own trained operator or with an integrator’s commissioning team, and an administrator controls which roles may change what.
The one thing that has to be right is the coordinate. A luminaire registered in the wrong place behaves as though it were in the wrong place, so positions are worth verifying at commissioning, before a resident complains.
What this means for a smart-city system integrator
For an integrator, the number that hurts is commissioning labour per site, because it repeats on every project and never scales. A method with no per-scenario programming moves most of that work into a coordinate registration, and it changes what gets handed over: there is no scenario library for the city to inherit and slowly let drift out of date.
Hardware choice stays open too. Lusety’s controllers are built to Zhaga Book 18, the socket standard between outdoor luminaires and sensing or communication modules, and to DALI-2 including D4i from the DALI Alliance, the protocol between the controller and the luminaire’s driver. The coordinate logic therefore does not require proprietary luminaires. HORIZON is TALQ certified as a central management system, listed on the TALQ Consortium register against specification 2.7.1, and Lusety is an associate member. HORIZON can manage third-party controllers built to those specifications once the integration between them has been carried out. The wider criteria for comparing systems are set out in our guide to how to choose a street lighting platform.
Which approach should you choose?
Four questions settle it for most sites.
Does the geometry get complicated? Crossings, junctions, meeting paths and open squares are where grouping needs the most hand-tuning, and where a missed case is most visible to the people using the street. A single uniform street with one traffic pattern is the easy case.
How much will the layout change after handover? A finished street that will stay as it is favours whichever method is cheapest to install. A district still being built, extended or rerouted turns every change into another configuration job under grouping.
Who owns the configuration once the installer leaves? If nobody on the city’s side will keep scenarios tuned, keeping the number of them near zero is worth more than it looks on day one.
How much of the night is the street empty? This is the savings question, and neither method changes the answer.
Zone-based control is a defensible choice on a simple, uniform street with no crossings and a layout nobody expects to touch. It saves the same energy there, and the extra capability of a coordinate-based system would sit unused. It gets expensive once the geometry is complicated or the site keeps changing, which describes most residential districts, park networks and mixed pedestrian areas.
Frequently asked questions
What is motion-based street lighting?
Motion-based street lighting, also called sensor-based lighting, keeps a street dimmed while it is empty and lifts each luminaire to full output when its sensor detects someone approaching. It is the same thing as adaptive lighting. The sensors run whenever power is on, which at a street luminaire is all the time.
How does adaptive street lighting decide when to dim?
It dims when nothing is moving and raises the light when someone approaches. In a coordinate-based system, each luminaire’s own position plus the direction and speed of the detected movement determine which lights lift and in what order, with no fixed group schedule involved.
What is the difference between zone-based and coordinate-based control?
Zone-based control groups luminaires and runs each group on a programmed pattern that has to be tuned, including a separate case for every irregular layout. Coordinate-based control gives each luminaire its coordinates and works from actual movement, with no per-scenario programming.
What is the difference between zone-based and sensor-based street lighting?
Sensor-based and adaptive lighting are the same thing: every luminaire senses movement and dims when there is none. Zone-based versus coordinate-based is a separate question about what the system does with that sensing, whether it triggers a pre-programmed group pattern or a response calculated from each luminaire’s position. A system can be sensor-based and zone-based at the same time.
How much energy can adaptive lighting save?
It depends on the street. The control method changes how much tuning it takes to get there. On low-traffic streets and paths it can save up to 80% on top of the efficiency gain from LED, because those streets sit empty for much of the night. Busy roads that must stay lit save the least.
Why does adaptive lighting sometimes fail at intersections?
Intersections carry movement from several directions, which a zone-based system has to be programmed to handle case by case. If one case was never tuned, lights there can react late or not at all. Coordinate-based control derives the response from position and movement, so an intersection needs no separate scenario.
Is adaptive lighting better than a simple timer?
Only when it reacts reliably. A light that comes up late serves people worse than a timed light that was already on, which is why the control method deserves as much scrutiny as the feature itself.
Conclusions: the method decides the result
The control method decides how reliably the light is there when somebody arrives, and how much setup and re-tuning the network costs across its life. Zone-based grouping depends on somebody having programmed the right scenario for every layout, and it is the missed case, usually a crossing, that shows up as a late or absent light. Coordinate-based control derives the same behaviour from position and movement, so it reaches the same energy savings with less tuning and leaves fewer places for a silent misconfiguration to hide. The savings themselves are set by the street and how much of the night it spends empty. Choose the method on reliability and lifetime setup cost, size the savings from the street type, and the two questions stop getting mixed up with each other.
Learn more
If you are weighing up adaptive street lighting and want to understand how the control method affects reliability and setup cost, we are happy to talk it through.
Email us: info@lusety.com
Call us: +370 649 91222
About Lusety
Lusety is a smart urban lighting company based in Kaunas, Lithuania. It builds street lighting controllers and the HORIZON cloud platform that lets cities and integrators manage lighting networks centrally. The system is built to open standards, including Zhaga Book 18 and DALI-2, and HORIZON is TALQ certified as a central management system, so integrating another maker’s devices stays a scoped piece of work, and cities keep control of their own infrastructure.