CMS, Smart urban lighting
Judge a smart street lighting management platform on how much control it leaves with the city, and on whether each claim can be tested on real hardware before the contract is signed. Seven criteria decide that: whether the platform can manage controllers it did not manufacture, whether each part can be bought on its own, where the control logic sits when the connection drops, how the adaptive dimming actually decides, whether the system raises a fault by itself or waits for a complaint, who owns the data and where it is hosted, and what it takes to add a sensor later. Every vendor answers a questionnaire the same way, so those answers are worth little until a pilot separates them. Municipal lighting owners and the integrators who specify and deploy for them are choosing a control layer that will still be running after the luminaires beneath it have been replaced once, which is why the cost of a wrong answer arrives years after the signature.
What this choice actually decides
Public street and area lighting accounts for up to 40% of the electricity consumed by municipalities and roughly 1 to 3% of total electricity demand worldwide, according to the Clean Energy Ministerial. ACEEE puts street lighting at 25 to 50% of a municipal energy bill and usually the first or second largest local government energy use. In Europe the picture is the same: the Intelligent Energy Europe funded Streetlight-EPC programme puts street lighting at 30 to 50% of total electricity consumption for municipalities still running older, inefficient systems, with 30 to 70% savings generally possible on current technology.
The timescale is just as awkward. ACEEE puts LED replacement intervals at 7 to 10 years, against 2 to 3 years for the lamps they replaced. The management platform specified in this tender will therefore outlive the luminaires under it, the officials who signed for it, and usually the political cycle as well.
For an integrator the exposure is different but not smaller. These criteria protect the next bid as much as the current one: a platform that only manages its own maker’s hardware turns every follow-on phase into a single-supplier negotiation, and it is the integrator who sits in the room when the municipality asks why phase two costs what it costs.
Which companies actually supply these platforms in Europe, and how Signify, Schréder, Tvilight, inteliLIGHT, Luminext and Lusety differ on hardware, standards and partner model, is set out in the vendor landscape for municipal platform selection.
The seven criteria, and how to verify each one
Each criterion reduces to one question, two possible answers, and a test that settles which answer is true.
| Criterion | The question to ask | Warning sign | What a good answer looks like | How to verify it |
|---|---|---|---|---|
| Open standards | Can it manage a controller it did not manufacture? | Only its own maker’s devices work | Runs devices built to TALQ specifications from other makers, once integrated | Ask what integrating a named third-party device takes, who does it and what it costs |
| Bundled stack | Can each part be bought and used on its own? | Cabinet and luminaire controllers sold only as a pair | Each controller works on its own | Ask for one quote for feeder metering only, and one for per-pole dimming only |
| Connection resilience | Where does the control logic live? | The cloud decides day-to-day switching | Each luminaire holds its own schedule and rules | Cut the uplink for 24 hours during the pilot and watch the street at dusk |
| Adaptive method | How does it decide to dim? | Fixed zone patterns that need manual tuning | Per-luminaire response to real movement | Walk and drive the pilot street at night, including a crossing |
| Fault detection | Does the system raise the fault, or does a resident? | Faults appear only if someone opens a dashboard | Graded rule-based alerts with first-seen and time-to-resolve | Disconnect one controller and time how long until the alert arrives |
| Data ownership and operability | Who owns the data, where is it hosted, can you export it? | Vague answers, no export path | Named owner, stated hosting country, documented export | Export the full pilot dataset yourself, without asking the vendor |
| Extensibility | Can it take data from sensors it did not supply? | Closed to anything the vendor did not sell | Documented socket, protocol and integration path | Ask what connecting one named non-lighting sensor would take, who does it and what it costs |
How to verify the claims before you commit
A questionnaire mostly measures how well a vendor writes. Three stages of checking, in this order, and each one answers something the stage before it could not.
| Stage | Typical effort | What it settles | What it cannot settle |
|---|---|---|---|
| Desk check | An afternoon per vendor, before the shortlist | Documented standards support, hosting location, export formats, reference deployments | Whether any of it behaves on your poles |
| Pilot | 30 to 60 days on one or two complete feeders | Interoperability, resilience, dimming behaviour, alerting, export | What happens in year six |
| Contract clauses | Written before signature | Ownership and hosting, plus the questions no test can settle | Nothing technical, this is where the untestable goes |
The pilot is the stage most often cut for time, and it is the one that pays. Seven design choices decide whether it proves anything:
- Size it to at least one complete cabinet feeder. A scatter of poles leaves the cabinet controller out of scope, and the two sets of numbers can then never be reconciled against each other.
- Run it for at least 30 days, and 60 if the schedule allows, so you get one full metering month to compare against the utility invoice and one shift in the seasonal switching times.
- Agree in advance what integrating a named device from another maker would involve, who performs that work and what it costs, and scope it into the pilot if the vendor is willing. A written answer here tells you more than the whole compatibility section of the proposal.
- Break it deliberately. Pull the uplink for 24 hours, disconnect a controller, force a luminaire to draw power outside its schedule, and record what the platform did and when.
- Push a firmware update over the air during the pilot, because without over-the-air updating every future firmware release becomes a site visit to every pole.
- Export the complete dataset at the end yourself, in an open format, from the interface, without a vendor engineer preparing it for you.
- Let the city’s own operator run the daily work. If the system only behaves in the hands of the vendor’s engineer, you have bought a service contract, and the operating cost sits with the vendor for the life of the network.
Two honest limits. A pilot on 100 to 300 luminaires does not prove behaviour at 30,000, and a network that scales in a demo can still saturate an uplink in a dense district. It also says nothing about year six: whether the supplier still exists, whether this protocol version is still supported, whether the export still works during a termination. Those questions have no technical test, so put them to the vendor in writing before signature.
Can it manage a controller it did not manufacture?
This is the first filter, and three open standards make it possible. Zhaga Book 18, maintained by the Zhaga Consortium, is the physical socket between controller and luminaire; DALI-2 and its D4i part, maintained by the DALI Alliance, carry control commands between the controller and the light; and TALQ, maintained by the TALQ Consortium, is the data layer between the device and the management system. The three layers are pulled apart properly in the open standards guide; what matters here is the question to put to a vendor.
Ask what the platform does with a controller it did not manufacture: which standards it reads, what integrating a named device from another maker would involve, who does that work and what it costs. A certificate does not answer that on its own, because certification covers the interface and the two products still have to be connected before they run together. What the standards change is that the job becomes scoped and priceable. A vendor whose platform genuinely speaks an open data layer can describe the work and put a price on it; one that will only ever run its own hardware is closed in practice whatever the datasheet says. HORIZON is listed on the TALQ certified-products register as a certified central management system against specification 2.7.1, which shows which functions were tested; connecting a specific third-party device to it is still a scoped piece of work. In a tender, write the requirement as TALQ certification of the management system plus a scoped answer on third-party integration. The certificate is what a procurement officer can verify; the scoped answer is what shows the bidder can do the job.
Can each part be bought on its own?
The two device types do different jobs. A cabinet or segment controller sits in the lighting cabinet and switches and meters an entire feeder, the run of poles fed from that cabinet. A luminaire controller sits in the Zhaga socket on one pole and dims and meters that single light. A city with an aging cable network and no dimming ambition needs the first. A city retrofitting one high street for adaptive control needs the second. Most cities need a different mix per district.
That is why forced bundling costs money. When a platform sells only the pair, a municipality that wanted feeder-level metering on 40 cabinets buys a controller for every luminaire beneath them, and a municipality that wanted per-pole dimming on two streets pays for cabinet hardware it will never look at. Ask for two separate quotes, one for each device on its own. A vendor that cannot produce them has answered the question.
What happens when the connection drops?
A lighting network has to work on its worst day, so ask where the control logic lives. If the intelligence sits on the devices, each luminaire holds its own clock, schedule and rules, and keeps switching, dimming and responding to movement while the link to the platform is down. If the platform is in the loop for day-to-day switching, a lost connection becomes a dark street and a phone call to the mayor’s office. The platform should stay central for data, analysis and changing the plan, but a light should never need a live internet connection to turn on. Verifying this takes one evening: disconnect the uplink and go look at the street. The trade-offs either way are worked through in more detail here.
How does the adaptive control actually decide?
Adaptive control is where the large energy savings sit, so look past the word and ask about the method. Some systems group luminaires into zones and run each zone on a programmed pattern that has to be tuned by hand, which tends to react late or oddly at awkward geometry such as an intersection or a footpath joining a road. Others work from each luminaire’s own coordinates and the direction a person is actually moving, which needs less configuration and handles crossings without special programming. On suitable streets and paths, good adaptive control can cut lighting energy use by up to 80% on top of the LED saving. Test it by walking and driving the pilot street after dark, at a crossing, and watching how far ahead of you the light arrives. The coordinate versus zone comparison explains why the method decides how reliably the light arrives and how much tuning the network needs over its life, while street type decides the savings.
How does it tell you something is broken?
The buyer question is blunt: does the system raise the fault itself, or does the city still find out from a resident? A platform that detects faults generates rule-based alerts from the luminaire power supply’s own measurements. Power drawn when the schedule says off, a voltage reading outside its set limit, a device that has gone silent, each triggers an alert without anyone watching a screen. At the cabinet, a segment controller adds feeder-level consumption, so an anomaly across a whole street shows up even when no single luminaire looks wrong.
Detection alone is not enough to run a crew on. Alerts have to be graded by severity, so that a pole-level electrical fault and a briefly unreachable device do not arrive as the same message, and each alert has to carry a first-seen timestamp and a time-to-resolve, because those two fields turn maintenance performance into a number the city can hold a contractor to. Ask to see the alert list from a live deployment, exported, with the timestamps intact. Then disconnect a controller during the pilot and time the gap until the alert lands. The mechanism is described in full in the predictive maintenance guide.
Who runs it, and who owns the data?
Someone has to operate this every day, so establish first whether a city employee can group luminaires, adjust a schedule, move a device’s location and add a user without a support ticket, and what each user role is allowed to change. Then pin down ownership in the contract, where it is enforceable. Two things belong in writing:
- A named owner of the operational data, stated as the municipality, in the contract body and not in an annex.
- The hosting location, named to the country and the legal jurisdiction, along with who else can reach the data there.
Both are cheap to get before signature and close to impossible afterwards, and both are questions a vendor can answer in a sentence if the answer is clean.
Can it carry the rest of the smart city?
The lighting grid is the cheapest host a city already owns. Poles stand every few tens of metres at street-lighting height, in exactly the places where traffic counters, air quality monitors and environmental sensors need to be, and they carry power whether the light is on or off, so a sensor mounted there needs neither new cabling nor a battery someone has to change.
Two integration paths do the work, and they suit different projects. A device can carry its own SIM and report straight to the server, which fits an isolated sensor away from any lighting run. Or it can sit on the Zhaga socket and communicate over DALI, where up to 64 devices can share one node, which is the cheaper path wherever the device is on a pole that already has a controller. Lusety builds its controllers and the HORIZON platform around both routes, to Zhaga Book 18 and DALI-2 including D4i, and is an associate member of the TALQ Consortium. Ask any vendor which of the two paths a sensor you name would take, what that sensor must comply with to connect, and what the integration work involves. A vague answer here means the lighting project will stay a lighting project. How the network extends beyond lighting is set out in the connectivity architecture guide.
Frequently asked questions
What is the most important thing when choosing a street lighting platform?
Whether it keeps the city in control, and whether that can be verified on real hardware. Openness, independence from a single supplier and resilience when the connection drops matter more over the life of the network than any single feature.
How do I know if a platform will lock me in?
Ask which open standards it implements and ask for the evidence in writing: the TALQ capability list for the data interface, Zhaga Book 18 for the socket, DALI-2 with D4i for control. Then ask what connecting a controller from another manufacturer would involve, who does that work and what it costs. A platform that can only ever run hardware from its own maker is a closed system, and that last question is where it shows.
How do I check that a platform is really built to open standards?
Ask for the management platform’s capability list on the TALQ certified-products register, because that is what shows which functions were actually tested. Then ask what connecting a device from another manufacturer would take, who does that work and what it costs. A vendor built to the standards can describe it.
Will the system tell us a light has failed, or will residents tell us first?
The answer only means something once you have tested it. A platform with rule-based fault detection raises an alert from the luminaire’s own electrical measurements, graded by severity and timestamped, before a complaint arrives. Disconnect a controller during the pilot and time how long the alert takes.
Should the lights work without an internet connection?
Yes. In a well-designed system the control logic sits on the devices, so the lights keep running on their own schedule even when the connection to the platform is down. Cutting the uplink for 24 hours during a pilot is how you confirm it.
Does the platform save energy on its own?
The platform enables adaptive control, which is where the larger savings come from. On low-traffic streets and paths that can reach up to 80% on top of the efficiency gain from LED, though busy roads save less.
Who owns the data a lighting platform collects?
That depends on the vendor and the contract, so a city should settle it before signing. Get the owner named as the municipality and the hosting country stated, both in the contract body, which is harder to amend later than an annex.
Conclusions: buy control
The platform that wins a demo is not always the one a city should buy, because a dashboard can always be made to look good and a lock-in cannot be undone. What protects a municipality over the life of the network is openness proved on real hardware, parts that can be bought separately, lights that keep working when the link fails, dimming that behaves at a crossing, faults that announce themselves, and data the city owns outright. Every one of those has a test attached to it, and the tests cost far less than the phase two negotiation they prevent. Run them before signature, while you still have leverage.
Learn more
If you are choosing a smart street lighting platform and want help working through these criteria, or designing the pilot that tests them, 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.