Sensor selection is not a procurement decision. It is a design decision, and it happens before procurement

Smart street lighting is one of the most tangible and widely deployed smart city transformations available to municipalities today. The technology is mature, the economic case is well-established, and the operational benefits, adaptive dimming, remote fault detection, predictive maintenance, reduced energy consumption, are documented across hundreds of real deployments in cities of every size.
And yet poorly designed smart lighting systems are common. Systems where sensors produce data that nobody acts on. Systems where motion detection triggers lighting changes that do not reflect actual pedestrian behaviour. Systems where sensor choices locked the municipality into a proprietary platform that became expensive and difficult to maintain. Systems where the sensing architecture was specified by the technology vendor rather than derived from the operational objectives of the city.
Sensor selection in smart street lighting is not a technical detail to be resolved during procurement. It is a strategic design decision that determines whether the system will perform as intended over its operational life, or whether it will deliver a fraction of its projected value. This article examines the key sensor categories, their respective trade-offs, and the feasibility questions that should drive the selection process before any vendor is engaged.
The first design decision: what do you need the lighting network to do?
Every sensor selection decision is downstream of a more fundamental question: what operational objectives is the lighting system expected to serve? The answer to that question determines which sensors are necessary, which are optional, and which would add cost without adding value.
A lighting network designed primarily to reduce energy consumption through adaptive dimming has a straightforward sensing requirement: ambient light sensors to detect available natural light, and motion or presence detectors to trigger intensity increases when pedestrians or vehicles are present. This is the most common configuration and the one with the clearest economic case.
A lighting network that is also expected to contribute to public safety, detecting unusual events, supporting surveillance, monitoring crowd density in sensitive zones, requires a substantially more complex sensing architecture, with acoustic sensors, computer vision systems, and integration with municipal safety platforms.
A lighting network conceived as a multifunctional urban infrastructure node, hosting environmental sensors, traffic counters, connectivity antennas, and other services alongside the luminaire, requires a design approach that accounts for power supply, data transmission, and structural load across a much wider set of devices.
The feasibility implication is straightforward but frequently ignored: a system designed to serve one objective that is subsequently expected to serve three is rarely capable of doing so without significant additional investment. The scope of the sensing architecture needs to be defined before specification begins, not discovered after deployment.
Ambient light sensors: the baseline for any adaptive system
The most fundamental sensor in any smart lighting architecture is the ambient light sensor, which measures surrounding illumination levels and allows the system to adjust artificial output according to real environmental conditions rather than fixed schedules.
Fixed astronomical clocks and time-based schedules remain useful as a baseline control layer, but they cannot account for cloudy winter afternoons, heavy rainfall, fog, or the dramatic variation in natural light availability between a narrow street canyon and an open boulevard. A photometric sensor that measures lux levels in real time gives the lighting management platform the information it needs to activate, dim, and adjust lighting in response to actual conditions rather than abstract time parameters.
The variation in natural light conditions across a single city can be substantial. In dense historic centres with narrow streets and tall buildings, a common typology in Southern European cities, available daylight differs significantly from one street to the next depending on orientation, building height, and urban morphology. A citywide fixed schedule cannot reflect this variation. Localised ambient light sensors can.
Feasibility consideration: Ambient light sensors are low-cost, low-complexity, and high-value. They should be a standard component of any adaptive lighting deployment. The design question is calibration and placement, sensors that are poorly positioned (subject to direct light from the luminaire itself, for instance) will produce distorted readings that trigger incorrect system responses. Calibration protocols and placement specifications need to be defined in the project design, not left to the installer.
Motion and presence detection: the primary driver of adaptive dimming
Motion and presence detectors are the sensors that make adaptive dimming operationally meaningful. They allow the system to maintain reduced illumination during periods of low activity and increase brightness when pedestrians, cyclists, or vehicles are detected, typically triggering a configurable response that returns to the reduced level after a set delay.
Several technologies are used for this purpose, each with different performance characteristics in outdoor urban environments:
Passive infrared (PIR) sensors detect heat emitted by moving bodies, humans and animals, and are well suited to pedestrian environments: residential streets, walking paths, parks, and low-speed zones. They are low-cost and energy-efficient, but their detection range and reliability can be affected by extreme weather conditions and complex movement patterns.
Microwave radar sensors detect movement through Doppler shift and offer more reliable performance in outdoor environments, particularly for vehicle detection and longer-range sensing. They are less affected by weather and can detect movement speed and direction, enabling more refined system responses, a vehicle moving at 50 km/h may trigger a different lighting response than a pedestrian at walking pace.
Computer vision systems, cameras with onboard image processing, provide the most sophisticated detection capability, distinguishing between pedestrian types, counting flows, and identifying specific events. They are also the most expensive, the most data-intensive, and the most sensitive from a privacy and regulatory perspective. Their use in street lighting requires explicit legal framework assessment in the specific national and municipal context.
Feasibility consideration: The appropriate motion detection technology depends on the characteristics of the deployment environment and the operational response required. Specifying microwave radar across an entire residential district when PIR would suffice inflates cost without adding operational value. Specifying PIR on a high-speed arterial road where vehicle detection and speed-differentiated response is required produces a system that does not perform as designed. The match between technology and context needs to be established in the design phase, not resolved through trial and error after installation.
The energy saving potential from well-designed adaptive dimming is significant: reductions of 50–70% in electricity consumption compared to static full-intensity operation are achievable in residential and low-traffic environments. The realised saving depends critically on whether the motion detection logic accurately reflects actual pedestrian and vehicle patterns in the specific streets where it is deployed.
Traffic flow sensors: when lighting must respond to road conditions
In major urban corridors, arterial roads, and peri-urban access routes, lighting systems increasingly need to respond not just to isolated movement but to broader traffic conditions, sustained vehicle flows, peak-hour patterns, and the operational windows of specific user groups such as freight vehicles or shift workers.
Inductive loops, radar-based counters, magnetic vehicle detectors, and vision systems can be integrated with lighting control platforms to provide this level of traffic intelligence. The system can then maintain sustained full illumination during peak traffic periods and shift to adaptive dimming during low-activity windows, rather than responding only to isolated vehicle detection events.
A logistics district with significant freight movement between 3:00 and 6:00 am is a clear example of where traffic-responsive lighting delivers value that simple motion detection cannot: the system anticipates the operational window and manages the lighting transition efficiently, rather than flickering in response to individual vehicle passes.
Feasibility consideration: Traffic flow sensors add cost and integration complexity. Their inclusion in a lighting system is justified when the traffic pattern is sufficiently variable and predictable to enable meaningful energy optimisation, and when the lighting management platform can actually use the traffic data to generate differentiated responses. In simpler deployments where traffic conditions do not vary significantly, the marginal value of traffic flow sensors over motion detectors may not justify the additional investment.
Environmental sensors: the multifunctional pole opportunity
One of the most significant developments in smart street lighting is the evolution of the lighting pole from a single-purpose infrastructure asset into a multifunctional urban data collection point. Environmental sensors, measuring temperature, humidity, rainfall, wind speed, fog, air quality, and noise, can be integrated into the lighting pole infrastructure, using the existing power supply, communication link, and maintenance access that the lighting network provides.
This multifunctionality significantly improves the return on investment of the lighting asset: the cost of deploying and maintaining the pole, the power connection, and the communication infrastructure is shared across multiple services rather than attributed entirely to the lighting function.
Specific applications have clear operational value. Fog detection sensors on peri-urban roads and tunnel approaches can trigger automatic lighting intensity increases when visibility deteriorates, improving road safety in conditions where static lighting schedules would maintain reduced nighttime intensity regardless of visibility conditions. Rainfall sensors can activate enhanced lighting at pedestrian crossings under wet conditions, where visual contrast between vehicle headlights and the crossing surface is reduced.
Feasibility consideration: The multifunctional pole model is attractive in principle but requires careful design to be viable in practice. Each additional sensor type adds to the power budget of the pole, the data volume transmitted through the communication link, the complexity of the management platform, and the maintenance requirements of the asset. A pole that hosts a luminaire, an ambient light sensor, a motion detector, an air quality monitor, a noise sensor, and a Wi-Fi access point is a significantly more complex asset to maintain than a pole hosting a luminaire and a motion detector. The operational model for the additional services, who manages the data, who funds the maintenance, which municipal department is responsible, needs to be defined before the sensors are specified. Multifunctional infrastructure that is nobody’s clear operational responsibility tends to degrade quickly.
Maintenance and asset health sensors: the case for predictive operations
Conventional street lighting maintenance is reactive: bulbs fail, citizens report faults, maintenance crews are dispatched. The cycle from failure to repair typically takes days, and the total cost includes both the repair itself and the service interruption period.
Smart lighting systems offer an alternative through asset health monitoring, current sensors, voltage monitors, temperature probes, vibration sensors, and component diagnostics that allow the management platform to monitor the condition of luminaires, drivers, poles, and communication modules continuously.
The operational value is significant. A luminaire that begins consuming measurably more energy than its normal operational profile may be experiencing driver degradation before complete failure. A pole that registers abnormal vibration patterns may have a structural issue that visual inspection would not detect. An automated alert from the asset monitoring system enables a planned maintenance intervention before the failure occurs, which is faster, less expensive, and less disruptive than reactive repair.
Feasibility consideration: Asset health sensors transform the operational model of the lighting network from reactive to predictive, but only if the maintenance organisation is structured to act on predictive alerts. A system that generates alerts that are not acted upon, because the maintenance team does not have the workflow, the staffing, or the scheduling flexibility to respond proactively, delivers no benefit from its predictive capability. The maintenance model needs to be designed alongside the sensor architecture, not after it.
Communication and interoperability: the constraint that shapes every other decision
Sensor selection cannot be separated from the communication architecture of the broader lighting control system. Sensors must be interoperable with the protocols and platforms used in the rest of the network, DALI for luminaire control, Zhaga for standardised node interfaces, LoRaWAN or NB-IoT for data transmission, and open APIs for platform integration.
The interoperability question is particularly critical in large-scale deployments involving multiple vendors, phased rollouts over several years, or integration with existing city systems. A sensor that performs well technically but communicates through a proprietary protocol that is not supported by the city’s lighting management platform creates a long-term operational problem: the sensor data cannot be used, or can only be accessed through a secondary integration that adds cost and complexity.
Feasibility consideration: Specifying sensors against open, standardised communication protocols, rather than accepting whatever protocol a preferred vendor supports, is one of the most important long-term value decisions in a smart lighting procurement. It preserves the municipality’s ability to change platform providers, add sensors from different manufacturers, and integrate the lighting data with other city systems without being locked into a single vendor’s ecosystem. This specification decision belongs in the feasibility and design phase, before the procurement process begins.
A practical example: smart lighting in a metropolitan park
A metropolitan park provides a useful illustration of how multiple sensor types interact in a single deployment. The design challenge is distinct from a street environment: the space is used predominantly at specific times of day, by pedestrians at low speeds, in a setting where excessive lighting has significant environmental impact, affecting nocturnal wildlife, reducing astronomical visibility, and creating light pollution for nearby residential areas.
In this context, an appropriate sensor architecture might include ambient light sensors for dusk and dawn activation, PIR sensors along walking paths to trigger brightness increases when visitors are detected, acoustic sensors in more isolated zones to identify unusual nighttime events, and environmental sensors feeding park management and urban climate monitoring systems.
The result is a system that provides low baseline illumination for energy efficiency and environmental compatibility, increases brightness precisely where and when visitors are present, and contributes data to city systems beyond the lighting function itself, all without over-illuminating a space where excessive light has measurable negative consequences.
The key point is that this architecture is derived from the specific operational characteristics of a park environment. It is not the same architecture that would be appropriate for an arterial road, a historic city centre, a logistics district, or a residential neighbourhood. The sensor selection is always context-specific.
The feasibility checklist for smart lighting sensor selection
Before specifying any sensor technology for a smart street lighting deployment, the following questions should be addressed:
- Objective definition: What specific operational outcomes is the sensing architecture expected to deliver, adaptive dimming, predictive maintenance, environmental monitoring, traffic analytics, public safety support?
- Environment characterisation: What are the physical and operational characteristics of the deployment environment, traffic speed and density, pedestrian patterns, weather exposure, proximity to sensitive uses?
- Motion detection technology match: For each zone type in the deployment, which motion detection technology, PIR, radar, vision, is appropriate given the movement patterns, detection range required, and budget?
- Multifunctionality scope: Which additional sensing functions, if any, are operationally justified given the available power budget, communication capacity, and maintenance model?
- Asset health monitoring: Is the operational model of the maintenance organisation compatible with predictive maintenance? If not, what organisational changes are required before asset health sensors add value?
- Communication compatibility: Are all specified sensors interoperable with the target lighting management platform through open, standardised protocols?
- Vendor lock-in risk: Does the proposed sensor architecture create dependency on a single vendor’s proprietary ecosystem? If so, what are the long-term implications for platform flexibility and cost?
- Total cost of ownership: What is the full cost of the specified sensor architecture over a 10-year operational life, including device replacement, calibration, maintenance, and platform licensing?
The bottom line
Choosing sensors for smart street lighting is an exercise in translating operational objectives into technical specifications, and then assessing whether those specifications are viable in the specific context of the deployment.
The sensors themselves are not the difficult part. The difficult part is making the design decisions that determine which sensors are needed, where they should be placed, how they should communicate, and what operational model will keep them functioning reliably over years of continuous outdoor operation.
Those decisions belong in the feasibility and design phase, before any vendor is engaged and before any procurement process begins. A municipality that allows sensor selection to be driven by vendor preference rather than operational design will consistently end up with a system that is more expensive, less effective, and harder to maintain than one where the design logic was established independently first.
