CMS, Smart urban lighting
A smart street lighting system spots a failing light by watching how each luminaire behaves electrically and comparing that against how it is supposed to behave. In Lusety’s system those measurements travel from the luminaire’s power supply to the controller over DALI-2, and from the controller to HORIZON, the cloud platform where every alert is raised, graded by severity and tracked until someone closes it. A rule fires as soon as the two pictures stop matching: a light drawing power when its schedule says it should be off, or a voltage reading outside the limit set for that pole. Nobody has to notice anything for the alert to exist. The mechanism is condition-based monitoring: the system watches live measurements and flags a deviation the moment it appears. The market sells it under the predictive-maintenance label, and the per-luminaire alert record it builds is the material any real failure forecasting would have to work from.
Reactive, condition-based, predictive: what the three words mean
The terms get used interchangeably in tenders, which makes offers hard to compare. They describe three different points at which a city learns that something is wrong.
Reactive maintenance is fixing a light after it has already failed and someone has reported it. The trigger is a human observation: a resident’s call, a councillor’s email, or a patrol that happens to drive down the street. Nothing in the infrastructure raises its hand.
Condition-based maintenance is acting on live measurements from the equipment itself. The system reads the current electrical state of each luminaire, compares it against defined limits and schedules, and raises an alert the moment a reading falls outside them. It reports the current state of the equipment.
Predictive maintenance is forecasting a failure before it occurs, by tracking how a component degrades over time and estimating when it will cross the point of failure. It needs a long per-device measurement history and a model of how that component ages, on top of everything condition-based monitoring already does.
Rule-based alerting in HORIZON is condition-based by design: it reports measured state and leaves forecasting alone, with no machine learning guessing at failures. The measurement layer has to exist first. A vendor promising failure forecasts without a per-luminaire measurement record is selling a forecast it has no data to make.
How does a smart lighting system know a light is failing?
Traditional street lighting maintenance is reactive. A light goes out, someone notices, someone reports it, and eventually a crew is sent to find and fix it. A connected system changes the starting point. Because every controller reports data continuously, the system already holds the state of each luminaire, so it can catch a fault the moment the numbers stop making sense. A set of rules interprets the incoming measurements and decides when something is behaving in a way it should not. When a rule is triggered, HORIZON creates the alert automatically and puts it in front of whoever manages the network.
How does the measurement reach the system?
Lusety controllers read the electrical values from the luminaire’s power supply, the driver, over DALI-2 and its D4i extension, the control protocol defined by the DALI Alliance. D4i is the part of DALI-2 that covers data reporting from the driver, which is what turns a dimming protocol into a diagnostic channel. The three standards underneath all of this are pulled apart in our guide to open standards in street lighting.
The physical route is the Zhaga socket on top of the luminaire, the standardised connector defined in Zhaga Book 18. The Lusety controller screws into that socket, talks to the driver over DALI-2, and sends the result onward. Lusety products are built to Zhaga Book 18 and DALI-2 without holding device-level certification against those two standards, which matters when a tender asks for evidence. HORIZON itself is TALQ certified as a central management system, listed on the consortium’s certified-products register against specification 2.7.1, and Lusety is an associate member of the TALQ Consortium.
That dependency cuts both ways in practice. A luminaire without a Zhaga socket and a DALI-2 driver needs external cabled connections instead, which is why retrofit surveys matter more than most procurement teams expect. And the diagnostics are only ever as good as what the driver reports, so the driver specification deserves as much attention in a tender as the controller does.
What does the system actually measure?
The readings below are the ones most rules are built on, and what a driver can report is defined by the D4i data set: Part 251 for luminaire data, Part 252 for energy data, Part 253 for diagnostics. Each exposes a different class of fault, which is what lets a rule decide that something is wrong. Because mains power stays present at the pole even when the lights are off, the controller and any attached sensors keep running and reporting around the clock, including the hours the lights are off.
| Measurement | What it reveals | Example fault it exposes |
|---|---|---|
| Voltage at the luminaire | The electrical condition at that specific pole | A pole-level electrical fault when a reading falls outside its set range |
| Power draw against the schedule | Whether the luminaire is following its on, off, and dimming profile | A light stuck on when its profile says off, or dimming that has failed |
| Communication status | Whether the device is still reachable on the network | Connectivity or node loss when a device goes silent |
| Feeder-level consumption (Light Keeper) | Energy use across a whole feeder | Abnormal consumption across a street segment |
Light Keeper is Lusety’s cabinet-level controller. It sits at the feeder, so it sees the total behaviour of a street segment, which is a different question from what any single luminaire is doing. On voltage, where the driver supports it, a limit can be set so the controller acts locally when a reading crosses it, including cutting power to the luminaire without waiting for an instruction from the cloud.
Which faults show up, and how
The examples below are the ones that come up most often. HORIZON works on rules, and the list is open: a rule can be written for any condition the system can measure, so the set can be extended to what a city wants to watch. Severity is set in the rule itself, so the levels shown are typical values.
| Fault | How it surfaces | Measurement it comes from | Typical level |
|---|---|---|---|
| Luminaire drawing power when its profile says off | Consumption continues past the scheduled off point, so the light is still lit | Power draw against the schedule | Warning |
| Lost connection to the cloud platform | The device stops reporting and its silence is treated as the signal | Communication status | Information |
| Voltage outside its set limit | A reading crosses the limit configured for that pole; where the driver supports it, the controller can cut power locally at the same time | Voltage at the luminaire | Critical |
| Dimming no longer following the profile | Power draw stays flat when the profile calls for a change of level | Power draw against the schedule | Warning |
| Abnormal consumption across a feeder | Total energy use for the segment departs from its expected pattern | Feeder-level consumption measured by Light Keeper | Warning |
A cracked lens or a luminaire someone has painted over will not raise anything, because neither changes the electrical picture. Condition-based monitoring covers what the driver can report, and inspection still covers the rest.
How are alerts prioritised and handled?
Not every alert deserves a truck at 2 a.m., so HORIZON grades each one by severity.
| Level | What it means | Example | Expected response |
|---|---|---|---|
| Critical | A fault that risks safety or a wider outage | Voltage outside its set range at a pole | Dispatch a crew promptly |
| Warning | A device acting against its profile, but not dangerous | Dimming that is no longer following the profile | Fold into a planned visit |
| Information | A state change worth recording | A device that has briefly lost communication | Log and monitor, act if it persists |
Each alert carries context: when it first appeared, what the measurements were at that moment, who saw it first, and how long it took to resolve. A crew can assign it, add comments, and change its status as they work through it. That history matters as much as the alert itself, because it turns maintenance from a series of one-off call-outs into a record the network’s operators can review. Which faults recur and which areas are worst both become answerable questions, and so does how quickly the team actually responds.
What happens if the connection drops?
The controller holds its own clock and its own rules, and it executes them without asking the cloud. Switching, dimming levels and motion response all run on the device, so a communications failure does not darken a street. An outage costs you visibility and control while the lighting keeps running, and the device resumes reporting when the link returns. The split between what runs locally and what runs centrally is worth understanding before you buy, and we go into it further in our note on edge versus cloud control.
The same architecture makes some fixes remote. Rule and parameter changes, and firmware updates, arrive over the air, so a misconfigured schedule or an alert threshold set too tight can be corrected without sending anyone to the pole. A genuinely new hardware capability still needs a physical change; most other adjustments do not.
What does this change for a city’s maintenance crew?
The practical shift is from searching to acting. Instead of patrolling to find dark lights or waiting for residents to call, the crew starts the day with a graded, located list of faults. For the municipalities and smart-city integrators that run these networks, dispatch can be planned around confirmed faults.
The honest version of the benefit is narrower than most vendor claims in this category, including some you will see quoted with confident percentages. Nobody can tell you in advance how many kilometres of pointless driving a system will save you, because that depends on your network and on how your crew currently works. What the platform does is record first-seen and time-to-resolve on every alert, so a city can measure its own dispatch baseline in the first months and compare against it afterwards. That gives you a figure measured on your own network. If you are still comparing platforms, the ability to export that alert history is worth checking alongside the criteria in our guide to choosing a street lighting management platform.
People and vans are still required. The system points them at the right pole.
Frequently asked questions
How does a smart streetlight detect a fault?
The system reads electrical measurements from each luminaire’s power supply and runs them against rules for how the light should behave. When a reading does not match the rule, such as power drawn while the light should be off, it raises an alert automatically.
Is this predictive maintenance or condition-based maintenance?
Condition-based. The system compares live measurements against defined limits and schedules and flags deviations as they occur. Predictive maintenance forecasts a failure before it happens from degradation trends, which requires a long per-device measurement history on top of this layer.
What does the system measure to find faults?
Mainly voltage and power draw from the luminaire’s power supply, plus whether the device is still communicating. Light Keeper, the cabinet-level controller, also measures consumption across a whole feeder for a segment-wide view.
How does the data get from the luminaire to the controller?
Over DALI-2 and its D4i extension, through the Zhaga Book 18 socket the controller plugs into. The driver reports its electrical readings on that link, and the controller passes them on to the HORIZON platform.
Can it tell the difference between an urgent fault and a minor one?
Yes. Alerts are graded into levels such as critical, warning, and information, so a crew can act on the urgent ones first and leave the minor ones for a planned visit.
What information does an alert carry?
Each alert records its severity level, a timestamp for when it first appeared, the measurements captured at that moment, who saw it first, and how long it took to resolve. Crews can also assign it, add comments, and update its status as they work through it.
Does the city find out before residents complain?
Often, yes. Because power stays on at the pole even when the lights are off, monitoring runs around the clock on live data, so many faults surface as they happen, before anyone reports a dark street.
What happens if a luminaire loses connection?
Two things. The loss of communication is itself treated as a signal and can raise an alert, and the controller keeps running its schedule and dimming rules locally, so the street stays lit while the link is down.
Does it replace the maintenance crew?
No. It surfaces each fault with its location and severity, so the crew spends its time fixing faults it can already locate. The people and vehicles are still needed.
Conclusions: the record is the asset
Fault detection is the visible part of this. The part that compounds is what piles up behind it. Every alert lands with a timestamp, the measurements that triggered it, and a resolution time, and after a year that is a per-luminaire history of how the network actually behaves. It shows which streets eat the maintenance budget and whose equipment ages badly, and it is the material any real failure forecasting would need to work from. The lights still need fixing by people. What changes is that the city stops depending on someone noticing.
Learn more
If you want to move your street lighting maintenance from reactive to data-led, 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, including the Light Keeper cabinet controller, and the HORIZON cloud platform that lets cities and integrators manage lighting networks centrally. Its products are 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.