Edge vs Cloud in Smart Street Lighting: Where Should the Control Logic Live?

• CMS, Smart urban lighting

Where a streetlight keeps its control logic decides what happens on the network’s worst day. In an edge design, each controller holds an internal clock plus the schedule and rules it was given, so it switches on, dims, and reacts to movement by itself, and it carries on doing so when the link to the platform drops. In a cloud-dependent design, more of that decision-making sits on a server, so a lost connection can leave lights that stop adapting or stop switching correctly. The difference matters most to the people who answer for the network when it fails: municipalities running the lighting and the smart-city integrators who deploy it. The cloud still has a real job in an edge system, but it is not in the loop for a single light to come on. Lusety builds that split into its controllers and the HORIZON cloud platform: the platform sets the plan and reads the results, and the devices carry it out.

What edge control and cloud-dependent control mean here

Edge control in street lighting means the decisions live on the luminaire controller itself, which stores the schedule, runs its own clock, and reacts to motion without asking a server first. It is also called decentralized control, or distributed control, because no single machine is making the decisions.

Cloud-dependent control keeps more of that logic on a central platform. The device waits for an instruction that was calculated somewhere else, so its behaviour is only as available as the link that carries the instruction.

Almost every real deployment uses both layers, so the question worth asking is how much each layer carries. One test settles it quickly: if the uplink goes down for an hour, does the street still light correctly? Everything else is detail.

Edge-based and cloud-dependent control, side by side

The fifth row is the one that goes against edge designs. Pushing a change really is cheaper when the logic sits in one place. The rest of the table is why street lighting still tends to justify paying that price.

What runs on the controller and what runs in HORIZON

The controller does not invent a schedule. It follows the one it was given and needs no permission to run it. The motion sensors stay awake around the clock, because power remains at the luminaire even when the light itself is off, so there is no wake-up delay on the first person who walks past at 03:00.

New rules and new firmware reach the device over the air. That shapes how a network ages: most capability changes on a deployed fleet are software-side and arrive as an update, while a new hardware capability still needs new hardware in the socket. Three physical facts sit under all of this:

• The controller plugs into the luminaire through a socket defined by Zhaga Book 18, the European standard for that connector. NEMA is the older equivalent used in the United States.
• Inside the luminaire, control runs over DALI-2 and its D4i part, the protocol the controller uses to talk to the driver.
• Up to 64 devices can share one controller across that wired DALI-2 and Zhaga bus. It is a limit on the wired side of a single node, and it says nothing about how many poles the radio network relays for.

D4i is also why the numbers are trustworthy. Energy and fault measurements come from the luminaire’s own driver, the power supply inside the fixture. Lusety’s controller does no separate metering of its own. At cabinet level, the Light Keeper segment controller measures consumption for the network it feeds. Lusety builds to Zhaga Book 18, DALI-2, and D4i without holding device-level certification against those standards, while HORIZON itself is TALQ certified as a central management system. That distinction is worth holding onto when you read anyone’s datasheet.

The four questions an outage really raises

On the street during a short outage, little changes. Each controller is already running its stored rules, so the visible behaviour continues. The interesting questions start when the outage is long, and they are the ones buyers rarely put to a vendor.

How long can a controller run on its own?

The schedule does not expire because the uplink did. A Lusety controller keeps running its stored rules with no platform in the loop, and the practical limit is whether the stored plan still matches reality. That turns the question into the next two.

Does the internal clock drift?

Every real-time clock drifts, and a device that has been out of contact for weeks can be running the correct schedule slightly late. Drift specifications are rarely published anywhere in this category, Lusety included. Ask for the figure in writing, and ask whether the controller re-syncs its time when it reconnects, because a schedule is only as accurate as the clock underneath it.

What does a stored schedule do as sunset moves?

Here the two on-device schedule models separate. A fixed list of clock times goes stale as the season shifts. An astronomical schedule recalculates sunset locally from the date and the luminaire’s coordinates, so it stays in step through an outage of any length. The gap is not trivial: around the equinoxes, sunset moves by roughly two minutes a day at Baltic latitudes near 55 degrees north, and about one minute a day at the latitude of Athens, so a fixed list is a quarter of an hour out of step within a week or two at the northern end. Lusety’s controllers already work from each luminaire’s own coordinates for adaptive response, which is the same input an astronomical calculation needs, but confirm with any vendor which of the two models its offline schedule uses.

What happens to a change that was pushed while a node was unreachable?

The change queues in the platform. HORIZON holds it and applies it once the controller is reachable again, and the controller meanwhile knows nothing about it and keeps running what it already has. Monitoring resumes on reconnect as well. What you should not assume is that the device buffered the measurements it took during the gap and backfills them afterwards. Ask explicitly whether historical data from the outage window is recovered or simply missing, on any system, because “it catches up” gets said far more often than it gets specified.

Where the single points of failure sit

Controllers talk to each other over a low-power RF mesh, where each one can relay through its neighbours and the network routes around a node that drops off, so a dead controller does not isolate the lights behind it. That local layer and the uplink to the cloud are two separate jobs, and the connectivity architecture that handles them deserves its own read.

The uplink itself is LTE cellular. It can sit in each device, or a gateway controller can aggregate a group of luminaires onto one modem so many poles share a single connection. Aggregation does concentrate a dependency, and it is fair to say so: if the gateway goes, that group stops reporting. With edge control, that scenario costs you visibility while the street stays lit. In a cloud-dependent design, the same gateway failure is a lighting failure.

What edge control means for integrators

For an integrator, the edge split changes what a deployment has to guarantee, because the field keeps running whether or not the central link is healthy. There are two ways to bring lighting under HORIZON. The first is to deploy Lusety’s own controllers, which run the edge logic natively. The second is to connect third-party controllers, which HORIZON can manage where they are certified by the TALQ Consortium, the body that defines how devices and management systems exchange data.

That second path is the vendor-independence argument in practice, and it comes with a caveat that matters. TALQ has a mandatory minimum set of items plus optional parts, so two certified products can still fail to overlap on the specific thing you need. Integration work does not disappear either: connecting a third-party controller still takes tweaking and support, even though nothing about it is off limits. Before signing, check three things.

• Which optional TALQ parts each side implements, beyond the fact that both hold a certificate.
• Which exact data points you need to read and write, confirmed as covered on both sides.
• Who does the integration work, and who pays for it when the two products disagree.

In a tender, the safe wording is to require systems built to TALQ specifications and then name the data points you need, because a certificate on its own is not the whole answer. The open standards behind that stack are worth reading up on before you write the requirement.

What edge control costs, and when cloud-heavy is the better bet

Edge control has real costs, and they land on whoever operates the fleet.

• Firmware becomes an estate to maintain. Every device holds logic, so every device needs a version, an update path, and someone tracking which is on what.
• Rules have to be distributed to every device. A rollout that half completes leaves a fleet in two states, and the street will look consistent while the data quietly is not.
• Changing behaviour everywhere at once is slower. Central logic is one edit; distributed logic is a campaign.

Cloud-heavy designs buy the mirror image of that. Optimisation across a large fleet, or across several cities, is easier when the reasoning happens in one place and can see everything. Device hardware can be simpler and cheaper when it does not have to hold and run logic. Model and algorithm updates land centrally without anyone touching a pole. Schréder describes its EXEDRA management system as cloud-native and built on Microsoft Azure, so this is a considered choice by a serious vendor and worth taking seriously.

The honest framing is a choice about which failure you would rather have. A cloud-heavy design fails visibly, on the street, at night, in front of residents. An edge design fails quietly, inside the fleet, as nodes that missed an update run stale rules while the lights look fine. For street lighting, where the service is a public safety one and the visible failure is the expensive one, the balance leans towards the edge. For a system where nobody notices a bad hour, it might not.

The security question worth putting in the tender

Edge control places decision-making on thousands of unattended devices standing in public space, which is a security question as much as a resilience one. Encryption in transit and at rest, key management, signed firmware for over-the-air updates, and readiness for the European Union’s NIS2 cybersecurity directive are all fair things to require from any vendor in writing. Put them in the technical requirements, because a confident answer in a meeting and a documented answer in a specification are not the same thing.

What the cloud layer is for once the lights run themselves

Once the platform is out of the second-to-second loop, it can do the work that needs a central view. HORIZON creates rule-based alerts automatically and presents them by level, as critical, warning, or information, each carrying when it was first seen and how long it took to resolve.

One example shows why that work belongs in the cloud. A rule can flag a luminaire drawing power when its profile says it should be off. The controller cannot catch that on its own, because it is doing exactly what it was told; the contradiction only appears when the measurement from the driver is compared against the plan, and that comparison lives centrally. The same logic drives predictive maintenance in street lighting, where a pattern across many luminaires says more than any single device knows. Edge control does not shrink the cloud’s job. It moves the cloud out of the operating path and into the place where the network is planned and read.

Frequently asked questions

Does smart street lighting keep working without an internet connection?

In an edge-based system, yes. Each controller stores its schedule and rules locally, so it keeps switching, dimming, and responding to movement while the link to the platform is down. What pauses is the central-side work: measurements stop flowing up, and no change can be delivered until the link returns.

What is the difference between edge and cloud control?

Edge control puts the decision-making on the devices, so they operate on their own. Cloud control keeps more of it on a central server. Most systems use both layers, and the thing that matters is how much the devices can do without the platform.

What is decentralized control in smart lighting?

Decentralized control, also called distributed or edge control, means each luminaire controller holds its own schedule, clock, and rules and acts on them locally. No central server has to be reachable for a light to switch on, dim, or respond to movement.

How long can a streetlight controller run without the platform?

There is no expiry on a stored schedule, so the controller keeps running it. The practical limit is accuracy: over a long outage, clock drift and a shifting sunset matter more than the length of the outage itself.

Does the controller’s internal clock drift during a long outage?

Every real-time clock drifts to some degree. Drift figures are rarely published in this category, so ask any vendor for the specification and for confirmation that the device re-syncs its time on reconnect.

Does a stored schedule still match sunset weeks later?

It depends on the schedule model. A fixed list of clock times drifts against sunset as the season moves, by roughly two minutes a day around the equinoxes at Baltic latitudes. A schedule that calculates sunset on the device from its coordinates and the date stays in step regardless of how long the outage lasts.

What happens to a change pushed while a node was unreachable?

It queues in the platform. HORIZON holds the change and applies it when the controller is reachable again, and the controller runs its existing rules in the meantime. Monitoring resumes on reconnect.

Does edge control remove single points of failure?

It removes the largest one. When lights do not depend on a single server or gateway to operate, no single failure takes down the whole network, and the self-healing low-power RF mesh routes around a dead node so it cannot isolate the lights behind it.

Conclusions: keep the intelligence at the edge, and know what it costs

In smart street lighting, the safest place for the control logic is on the devices. A controller that carries its clock, schedule, and rules on board keeps the street working through a lost connection or a dead node, and it leaves the platform free for analysis, aggregation, and planning across the network. That resilience is not free: firmware has to be maintained across a fleet, rules have to be distributed, and changing behaviour everywhere at once is slower than editing one central configuration. A cloud-heavy design buys back exactly those things, and for some systems that is the right trade. Street lighting is not usually one of them, because it fails as a dark street, while the others fail as a delayed report. Decide which failure you can defend, then ask for the outage answers in writing before the contract is signed.

Learn more

If reliability is a priority for your street lighting network and you want to understand how edge control affects it, 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.