Smart Streetlight Commissioning Checklist: Node Installation, Testing, Asset Mapping & Handover

Smart streetlight commissioning is the controlled process of proving that each installed node is correctly identified, located, enrolled, configured, and accepted before operations takes ownership. At program scale, the work succeeds through a repeatable workflow and clear exception records, not by treating every pole as an isolated installation.

For cities and transportation agencies, that distinction matters. A node that has power may still have the wrong asset record, an unverified communications path, an incorrect control profile, or no evidence that the field result matches the approved design. Commissioning closes the gap between an installed device and an asset that operations can manage with confidence.

Key takeaways

• Define the asset record and acceptance evidence before field crews begin streetlight node installation.
• Keep installation, enrollment, configuration, and acceptance as separate status checks.
• Use one durable identity to connect the pole, luminaire, node, map location, and supporting evidence.
• Treat failures and corrections as managed exceptions with an owner and a retest path.
• Hand operations a reconciled asset register, configuration baseline, and open-exception record rather than a collection of disconnected field notes.

What is smart streetlight commissioning, and what must it prove?

Connected lighting combines distributed intelligence with network interfaces. The U.S. Department of Energy notes that connected-lighting research spans configuration complexity, interoperability, energy reporting, sensors and fault detection, and cybersecurity, among other areas. Those subjects show why deployment planning must go beyond turning a device on. DOE’s connected lighting systems overview describes the research context; it is not a mandatory streetlight commissioning standard.

For a public-infrastructure deployment, commissioning should establish five practical outcomes:

1. The physical asset is recorded. The team can connect the installed node to the intended pole and luminaire, with enough field evidence to resolve questions later.
2. The identity and location are reliable. The agency can distinguish this asset from every other asset and locate it in the system of record.
3. The communications path is verified. The node has been enrolled through the approved process, and the project records the result rather than assuming planned coverage equals working service.
4. The approved configuration is applied. The record identifies the configuration or profile that was used and who controlled a change.
5. Acceptance evidence is complete. The project can show a pass, a failure, a retest, or an open exception for the agreed checks.

This is a project-control framework, not a substitute for electrical design, traffic control, cybersecurity review, or requirements from the agency and authority having jurisdiction. Those requirements depend on the site, equipment, contract, and jurisdiction.

Set the commissioning data model before field work begins

Record problems discovered after crews have moved to the next area are harder to reconcile. Set the minimum asset record before installation begins, then ensure every party uses the same identifiers and definitions.

Establish one agency-owned identity

Give each streetlight asset an agency-owned identifier that does not depend only on a vendor dashboard, a temporary work-order number, or a label that may later be replaced. That identifier can be the anchor for the relationships that matter to operations: pole, luminaire, control node, cabinet or circuit reference when applicable, and map location.

The relationship should be explicit. A controller serial number by itself is not an operations record. Likewise, a pole number without the installed node identity cannot prove which endpoint the management platform is reporting. If a field condition requires a substitution, relocation, or correction, record both the approved change and the final installed relationship.

Define required fields and evidence

The exact data model belongs to the agency and its project documents. An illustrative commissioning record might include:

Avoid making the table a universal specification. A project may need additional fields for its maintenance system, contract administration, security architecture, or utility coordination. The useful principle is simpler: decide what proves acceptance before the field process produces thousands of records.

Prepare installation and communications in deployment waves

Large deployments benefit from repeatable waves: a bounded area, a known work package, a named configuration baseline, and a clear reconciliation point. A wave can be a corridor, neighborhood, district, or other project-defined grouping. It should be large enough to test the operating process and small enough to correct patterns before they spread.

Confirm the approved work package

Before crews begin a wave, confirm the current approved design inputs, the asset list, the expected locations, and the planned configuration. Give field teams a way to flag a difference between the design record and the installed condition. A change discovered in the field should not silently become the new baseline simply because it appears in a dashboard.

Assign authority for accepting changes. That may include an agency representative, engineer of record, contractor lead, or another role defined by the project. The article cannot determine who that person should be, but the workflow should make the decision visible.

Plan enrollment and exception routes

Enrollment is not merely an administrative step. It connects the field asset to the management environment that will receive its status and apply approved controls. Test the actual project path and record the result. If a node does not enroll, do not rely on a planned network diagram as proof that the issue is resolved.

LEOTEK describes functions including remote switching, dimming, schedules, fault notifications, energy tracking, reporting, maps, alarms, and asset management for its connected streetlight management solution. Their availability and behavior remain product-, configuration-, and project-specific, so use the current documentation and approved test plan rather than assuming a function applies everywhere.

An exception route should answer four questions: What failed? Who owns the correction? What evidence is needed for retest? Who may close the exception? A clear route prevents a failed enrollment from becoming an undocumented handover risk.

Commission each node with a repeatable field workflow

The field workflow should be short enough to use consistently and specific enough to produce useful evidence. The following sequence is an operational recommendation that agencies can adapt to their own requirements.

1. Confirm the installed asset and capture the final record

Match the physical pole, luminaire, and node to the work package. Capture the identifiers and the project-approved location evidence. If the final condition differs from the approved record, flag it as a change or exception instead of editing away the discrepancy.

This step is where streetlight asset mapping becomes practical. A correct node associated with the wrong pole on a map can create avoidable ambiguity in maintenance, reporting, and future field work. The goal is not perfect-looking data at any cost; it is a record that preserves what was verified and what still needs correction.

2. Enroll the node and verify the intended asset relationship

Use the approved enrollment process, then confirm that the management environment recognizes the intended asset relationship. Record the enrollment result and any identifier that links the field record to the system record. If enrollment succeeds but the asset appears at the wrong location or under the wrong identity, treat that as a failed commissioning condition until reconciled.

Where a project is evaluating a specific connected-lighting device, the LEOLink NB01-Plus connected-lighting node is an available product-navigation path. Do not use a general product page alone to establish compatibility, networking, security, listings, environmental ratings, or installation requirements. Verify the current technical documentation for the exact equipment and deployment.

3. Apply and record the approved configuration

Apply the configuration that the project has approved for that asset or group. Record a version, profile identifier, or other controlled reference, along with any authorized deviation. This creates a boundary between the commissioning result and later operational changes.

Configuration should be deliberate. A field team should not need to infer a schedule, group, dimming behavior, or reporting convention at the pole. If a setting is provisional, record that fact and its owner instead of presenting it as final acceptance.

4. Perform safe, approved functional checks

Use only the checks authorized by the project plan and performed by qualified personnel. For connected streetlight acceptance testing, the approved test may confirm status reporting, an authorized switching or dimming command, an alarm or fault-notification path, or a map and asset-record match.

Document what the check showed, not what the team expected it to show. A pass should identify the completed check and date; a failure should identify the condition and trigger the exception route. Electrical work, traffic control, and any operational testing must follow the applicable project requirements and authority approvals.

5. Record pass, fail, retest, or open exception

Avoid a single ambiguous “complete” status. A small set of explicit states makes program reporting more useful:

• Installed: Physical work is recorded, but other commissioning steps may remain.
• Enrolled: The system recognizes the asset relationship, subject to project-defined verification.
• Accepted: Required evidence and approved checks are complete.
• Exception open: A defined issue remains, with an owner and correction path.
• Retest required or passed: The project can distinguish a new result from the original failure.

The labels can differ by agency. What matters is that the status has a definition, evidence, and a responsible owner.

Use staged acceptance to manage program scale

In a connected lighting deployment with thousands of records, small record errors can become harder to detect. Staged acceptance gives the project a way to detect patterns while correction is still manageable.

Reconcile installed, enrolled, and accepted counts

Track at least three counts for each wave: assets recorded as installed, assets successfully enrolled, and assets accepted. These counts are not an industry-mandated formula. They are a practical way to expose a gap that a single installation total can hide.

For example, a wave can have a complete installation count but a lower accepted count because some records lack location confirmation or an approved functional check. The right response is not to force the totals to match. It is to identify the exceptions, determine whether they share a cause, and decide whether the wave meets the project’s release criteria.

For a large connected-lighting deployment, an agency can also define a project-specific sample review of accepted records in each wave to check whether identity, location, configuration, and evidence remain consistent. The project documents should define the sample method, acceptance threshold, evidence requirements, and escalation path. A sample result does not replace the asset-level records and checks the agency requires for acceptance.

Manage exceptions as deployment data

Common exception categories may include duplicate identity, incorrect location, missing communications, wrong group or configuration, incomplete evidence, and a failed functional check. Each exception should carry an asset reference, owner, due date or project milestone, correction record, and retest outcome.

This approach also improves handover quality. Operations teams can see which assets are accepted and which remain under an active correction process. They do not have to reconstruct the story from email threads, informal spreadsheets, or a dashboard that no longer shows the original condition.

Hand over records that operations can use

Handover is a transfer of usable information, not a final meeting. Before operations accepts a wave, provide a reconciled asset register, the approved configuration baseline, field evidence references, a change history, and the open-exception list. Identify the source of record for each item so that the team does not create competing versions after launch.

For technical validation, direct readers to current product specifications and resources. Confirm the exact model, document revision, contract terms, and project applicability before using documentation for procurement acceptance, installation decisions, or compliance conclusions.

A practical handover review can ask:

• Can operations locate the accepted asset and understand its relationship to the pole, luminaire, and node?
• Can the team identify the approved configuration baseline and authorized changes?
• Can an open issue be found, assigned, corrected, and retested without relying on personal memory?
• Can the agency distinguish a field-installed asset from an accepted operational asset?

If the answer to any of these questions is no, the work may be installed, but the information needed to operate it is incomplete.

Frequently asked questions

Is installation complete when a connected streetlight node powers on?

Not necessarily. Power confirms only part of the field condition. Commissioning should also establish the intended asset identity and location, enrollment result, approved configuration, required functional evidence, and acceptance status defined by the project.

What data should be captured for each streetlight node?

Start with an agency asset ID; the associated pole, luminaire, and node identifiers; a location reference; installation evidence; enrollment and configuration status; test results; and any exception or acceptance record. The agency’s project documents determine the final data requirements.

How can teams prevent duplicate or incorrect asset records?

Use one agency-owned identity, require the field record to connect the physical asset to the system record, and reconcile duplicates or location mismatches as exceptions. Avoid overwriting a discrepancy without preserving the correction history.

What should happen when a node enrolls but fails a field test?

Record the enrollment separately from acceptance, open an exception with an owner, correct the documented condition, and retain the retest result. Do not treat successful enrollment as proof that all project-defined checks have passed.

Smart streetlight commissioning begins before the first node is installed and ends only when the agency has the evidence to operate accepted assets. For a defined roadway-lighting deployment or technical-evaluation question, readers may contact LEOTEK after reviewing the applicable documentation.

References

• U.S. Department of Energy, Connected Lighting Systems; accessed July 26, 2026.
• LEOTEK, LEOLink Solutions; accessed July 26, 2026.
• LEOTEK, LEOLINK NB01+ Controller; accessed July 26, 2026.
• LEOTEK, Resources and Documents; accessed July 26, 2026.