From All-Night Full Brightness to On-Demand, Per-Lamp Control

Across a city, lighting demand changes hour by hour. A busy junction, a quiet residential road and a pedestrian route do not need the same operating policy all night. Moving toward on-demand, per-lamp control means defining the light each location needs, then giving operators the tools to deliver it and verify the result.

Why all-night full brightness is getting harder to defend

Running every lamp at full output until sunrise is simple to schedule, but it cannot reflect changing traffic, local activity or maintenance priorities. For municipal teams, the question is how to manage energy use while maintaining the lighting levels required for each road and public space.

Replacing older fixtures with LED can reduce the connected load. Control adds another layer: approved schedules, remote status checks and fault handling. These benefits should be assessed separately, so savings from a fixture upgrade are not attributed entirely to dimming or networking.

Can we dim by scene, can we see status remotely, and can faults close out faster?

On-demand lighting: from one rule for all to time- and scene-based control

Start with an operating policy. Set lighting levels by road class, time window and local requirements; identify locations that need higher output during events or busy periods. Where verified sensor inputs are available, they can inform a policy without replacing the minimum lighting requirements agreed for the site.

Concept illustration: Wi-SUN nodes relay data through a mesh and gateway; cellular nodes use an operator network. Gateway backhaul can still incur data charges. Both approaches require a site survey; foliage and other obstructions can affect either radio system.

Connectivity should follow the project conditions. A Wi-SUN mesh can provide alternative routes when suitable neighboring nodes remain reachable. Cellular connectivity can suit distributed sites where operator coverage is adequate. Compare node density, radio planning, gateway backhaul, network operations and lifecycle costs rather than selecting a network on SIM fees alone.

Define behavior for communication loss before commissioning. Agreed local schedules and fallback levels help keep lighting predictable when the cloud or backhaul is unavailable. Validate any sensor-triggered transitions in the pilot, including how quickly the system returns to the scheduled level.

Per-lamp control: from whole circuits to one lamp, one policy

Circuit switching controls groups of fixtures together. A compatible per-lamp controller adds an addressable control point at each luminaire, allowing operators to apply individual or group schedules and collect the telemetry supported by that controller and driver. Useful information can include operating state, electrical measurements and fault indicators, depending on the selected hardware.

Concept illustration only, not an installation wiring diagram. Some labels are ambiguous. ANSI C136.41 defines a dimming receptacle interface; confirm the actual controller pinout, driver interface, conductor identification and manufacturer wiring documents before installation.

The controller, driver and receptacle must be specified as a compatible assembly. A matching connector does not by itself establish dimming compatibility or the available telemetry. During acceptance, verify the commanded light level, reported state and physical lamp output together, then test the behavior after loss of communications or power restoration.

For a Wi-SUN-based implementation, explore the NJ-iot306W Wi-SUN single-lamp controller. For the wider system design, see our Wi-SUN smart street lighting architecture guide, which connects the controller, gateway and central management platform.

A municipal rollout: tying lighting to day-to-day management

For a city such as Xiamen, a practical planning question is how to connect lighting policies with maintenance responsibilities across districts. The platform needs a usable asset map, consistent pole identifiers and clear ownership of each alarm. This is a planning example, not a report of a particular municipal deployment or its measured results.

Start by documenting the baseline: fixture types and wattages, operating hours, metering boundaries and current fault-handling steps. A corridor pilot can then compare energy consumption under matched conditions and check whether alarms lead to traceable work orders. Record changes in fixture technology separately from changes in operating policy.

What to measure in the pilot

• Energy: compare metered consumption using a documented baseline and operating hours.
• Lighting performance: verify the required levels and uniformity for each approved scene.
• Connectivity: measure online rate and recovery under real site conditions.
• Fault handling: record alert, acknowledgment, dispatch and closure times.
• Fallback behavior: check local operation during backhaul or platform outages.
• Scale-up readiness: confirm asset records, access permissions and maintenance ownership.

Three things to settle before a municipal rollout

1. Policy before hardware

Decide which corridors can dim after peak hours, which need event boosts and how environmental conditions affect approved thresholds. Then select controllers, gateways and platform functions that can execute those policies while meeting the site's lighting requirements.

2. Per-lamp control + visible platform = one system

Controllers execute commands and collect supported measurements; gateways or cellular links carry the data; the platform supports map views, policy management, fault workflows and energy reporting. Verify the complete path from a platform command to a physical lamp and back to a recorded result.

3. Put the O&M loop into acceptance

Beyond dimming and lighting availability, check that alerts arrive, asset locations are correct and maintenance actions are traceable. Agree response and arrival targets with the operating team, and test how work orders close after a repair.

A practical path: pilot a few corridors for policy, lighting performance and online rate, then expand by district.

Nengjia's view

Nengjia / NetJoin brings lighting controllers, gateways and cloud management into the same project conversation. Share your fixture interfaces, site layout, preferred communications and operating policies so the proposed system can be checked against the conditions it must serve.

Contact Us

Visit Our Site

Moving from all-night full brightness to on-demand, per-lamp control is urban management shifting from habit to data. The lamp is still a lamp; what changes is when it lights, how bright it runs, and who hears first when it fails.